{"id":55893,"date":"2024-10-23T14:45:46","date_gmt":"2024-10-23T18:45:46","guid":{"rendered":"https:\/\/sdtimes.com\/?p=55893"},"modified":"2024-10-24T10:02:55","modified_gmt":"2024-10-24T14:02:55","slug":"navigating-unexpected-license-changes-in-open-source-software","status":"publish","type":"post","link":"https:\/\/sdtimes.com\/os\/navigating-unexpected-license-changes-in-open-source-software\/","title":{"rendered":"Navigating unexpected license changes in open source software"},"content":{"rendered":"

Open source software is prevalent in <\/span>almost any<\/span><\/a> codebase today, and it’s assuredly only going to grow larger.<\/span><\/p>\n

According to a 2024 <\/span>analysis by the Harvard Business School<\/span><\/a>, the supply side value of open source software is $4.15 billion, while the demand-side value is $8.8 trillion. With numbers like those, it\u2019s easier to see how the financial benefits of using open source are just too good for most companies to turn their nose at.\u00a0<\/span><\/p>\n

But in recent years, there have been several instances where an open source project has suddenly changed their license to a more restrictive one, causing headaches for any developer who had incorporated that project in their code.<\/span><\/p>\n

For context, there are a variety of types of open source licenses, typically falling into two categories: permissive and copyleft, according to a <\/span>blog post<\/span><\/a> by OpenLogic by Perforce.\u00a0\u00a0<\/span><\/p>\n

Permissive licenses, such as the MIT License and the Apache 2.0 License, \u201cgrant users freedom in using, modifying, and distributing the software.\u201d\u00a0<\/span><\/p>\n

Copyleft licenses, on the other hand, \u201crequire any derivative works to be distributed under the same license as the original software, which includes making the source code available under that license.\u201d The GNU General Public License (GPL) family of licenses and the Mozilla Public License are examples of copyleft licenses<\/span><\/p>\n

But in recent years, you may have also heard of the <\/span>Business Source License (BUSL)<\/span><\/a>, because some big-name projects switched to that license, like Terraform (run by HashiCorp), CockroachDB, and MariaDB. However, the BUSL isn\u2019t technically considered to be an open source license, so it doesn\u2019t fall into the above two categories.<\/span><\/p>\n

It was <\/span>originally created<\/span><\/a> by MariaDB and specifies that a project\u2019s source code be available, but using the code in production may require approval from the licensor.\u00a0<\/span><\/p>\n

MariaDB isn\u2019t unique in creating a new license to suit its business needs. For example, Redis also created its own license called the <\/span>Redis Source Available License<\/span><\/a>, Elastic created the <\/span>Elastic License<\/span><\/a>, and MongoDB created the <\/span>Server Side Public License<\/span><\/a>.\u00a0<\/span><\/p>\n

According to Stefano Maffulli, executive director of the Open Source Initiative (OSI), the main motivation behind a change like this is to \u201clock up the value of the project and discourage competition.\u201d For instance, Elastic has initially created the Elastic License in response to AWS offering Amazon Elasticsearch Service.\u00a0<\/span><\/p>\n

Shay Banon, the founder and CTO of Elastic, wrote in a <\/span>blog post<\/span><\/a> at the time: \u201cOur license change is aimed at preventing companies from taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us. Our license change comes after years of what we believe to be Amazon\/AWS misleading and confusing the community \u2013 enough is enough.\u201d<\/span><\/p>\n

Maffulli went on to explain that companies switching to a more restrictive license is often the result of having gained a mass of adoption and wanting to monetize their investment in that project, while also preventing others from profiting off of their work.\u00a0<\/span><\/p>\n

It\u2019s important that open source projects build trust\u00a0<\/b><\/h5>\n

\u201cThere\u2019s nothing inherently wrong with proprietary and source-available licenses,\u201d said Maffulli. \u201cWhere the problems start is when these organizations switch licenses midstream or try to play games with branding, making their restrictive licenses sound like Open Source-approved licenses, creating confusion in the market.\u201d<\/span><\/p>\n

In most of the situations when this has happened, there has been <\/span>backlash<\/span><\/a> from the open source community using those projects. Not surprising, given that they had implemented the project into their technology stack agreeing to the original license, and now they\u2019ve got different rules to comply with. They might even need to think about an alternative if their use case doesn\u2019t fit in with the new terms.<\/span><\/p>\n

\u201cWhen a company switches from an open source license to a restrictive license like the BUSL, it is the equivalent of pulling the rug from beneath the user community\u2019s feet,\u201d said Maffulli. \u201cIt is an unexpected, unfair and deceptive \u2018switcheroo\u2019 that breaks the trust of the open source community, especially the trust of contributors and users of the project.\u201d<\/span><\/p>\n

AB Periasamy, co-CEO of <\/span>MinIO<\/span><\/a>, an open source object store, advises open source projects to think about these decisions in terms of their overall brand. \u201cBrand is about the trust and relationship you establish with your users.\u201d\u00a0<\/span><\/p>\n

Trying to monetize an open source project is ‘short term thinking’<\/b><\/h5>\n

In light of Cockroach Labs recently switching up its licensing again, the open source database YugabyteDB doubled down on being open source.\u00a0<\/span><\/p>\n

\u201cAs a founder of a distributed SQL database company (and a competitor), I can guess (and empathize with) the revenue pressure that led Cockroach to abandon their open source offering. But, I believe this is an example of short term thinking that can stifle long term growth,\u201d Karthik Ranganathan, founder and co-CEO of Yugabyte, the company behind the project, wrote in a <\/span>blog post<\/span><\/a>.\u00a0<\/span><\/p>\n

For some historical context, Cockroach Labs in 2019 changed its license from Apache 2.0 to the BUSL, and then in August, <\/span>announced<\/span><\/a> it was retiring the free Core offering and moving all features to the Enterprise version, which would be free to use for companies under $10 million in annual revenue.<\/span><\/p>\n

Ranganathan reasoned that developers and small organizations will likely be hesitant to adopt CockroachDB now because they know that if they grow and hit that revenue amount, there will be implications in how they use the database.\u00a0<\/span><\/p>\n

This informs YugabyteDB\u2019s long-term strategy of remaining open source so that it is the easiest database choice. In an interview with SD Times, Ranganathan said, \u201cWhy would a developer pick something that’s not open or less open? It just won’t work.\u201d<\/span><\/p>\n

Specifically in the database world, he explained that the \u201cdollars are not in the database tech,\u201d they\u2019re in the applications built on top of that database.\u00a0<\/span><\/p>\n

\u201cIt’s better to let it proliferate a lot and do the things needed for multiple people to contribute, and then, capture the value on top,\u201d he said. Capturing the value on top often means creating an enterprise offering with support or extra features.<\/span><\/p>\n

Capture the value on top<\/b><\/h5>\n

The approach MinIO takes is to keep its project open source but to offer an enterprise version on top of that to sustain the company financially. \u201cThe business helps sustain the open source project because we get paid by customers who can afford to pay, and we deliver enormous value,\u201d he said.\u00a0<\/span><\/p>\n

In MinIO\u2019s case, paying customers to the open source project get extra features, rather than features being taken away from the underlying project.<\/span><\/p>\n

Many other companies follow this model to fund the development of their projects, such as <\/span>Grafana Labs<\/span><\/a>, the company behind the open source observability platform Grafana, which offers two paid versions of the platform: Cloud and Enterprise. Cloud offers a fully managed, hosted version of Grafana, and Enterprise version allows plugins to be used and has built-in collaboration features not in the free open source version.\u00a0<\/span><\/p>\n

Red Hat also follows a similar model, offering open source projects backed by enterprise support, hosting, consulting, and other services.\u00a0<\/span><\/p>\n

\u201cSoftware takes a lot of money to build and maintain, and it’s not one person and part time, it’s a whole team of engineers building this. You need to find a way to commercially sustain it,\u201d said MinIO’s Periasamy.<\/span><\/p>\n

Terraform\u2019s switch to the BUSL leads to creation of OpenTofu<\/b><\/h5>\n

Sometimes when license changes happen, it also leads to someone creating an open version of the project, such as <\/span>what happened<\/span><\/a> with Terraform and OpenTofu. When HashiCorp switched over to the BUSL, the community came together to form an open fork of the project called OpenTF (now called OpenTofu) and published the OpenTF Manifesto, claiming \u201cthis [license] change threatens the entire community and ecosystem that\u2019s built up around Terraform over the last 9 years.\u201d<\/span><\/p>\n

Roni Frantchi, director of engineering at <\/span>env0<\/span><\/a> and founding member of OpenTofu, said that the response was a bit empathetic at first. We said, \u201cOkay, that makes sense that a commercial company looks at the cost of maintaining such an open source project and says \u2018it’s not right that I’m the only one who kind of bears the effort in trying to maintain this project.\u2019\u201d<\/span><\/p>\n

At the time, the people behind OpenTofu approached HashiCorp and asked them to instead contribute the project to a foundation where they would not have to be the sole maintainer, much like Google has done with donating Kubernetes to the CNCF, Frantchi explained.\u00a0<\/span><\/p>\n

However, that appeal went unanswered, Frantchi said, and that\u2019s what led to the community publishing the manifesto, which garnered a lot of support rather quickly.\u00a0<\/span><\/p>\n

\u201cWe saw the manifesto surge to over 36,000 stars in a few days, maybe a couple of weeks. So that’s a huge head start for a project like this, and we understood that we do have some backing of the community, and the community is very much interested in keeping this project open source,\u201d said Fratchi. \u201cAnd with that and the fact that we were not answered by HashiCorp, we respectfully forked the code and decided that we’ll take it from there. At no point did we think that any commercial company should stand behind this project. Instead, we knew right from the start that we’re going to the Linux Foundation and the CNCF. They were very much interested and met us with open arms and were very glad to back this project.\u201d<\/span><\/p>\n

In addition to creating the open fork of Terraform, another big item on OpenTofu\u2019s to-do list was tackling the backlog of community requested features that had gone unanswered, possibly because they didn\u2019t align with the direction HashiCorp wanted to take the project.\u00a0<\/span><\/p>\n

\u201cNow the roadmap is very transparent, and it’s out there publicly in terms of how we choose what’s in there and how highly rated the items are,\u201d he said.<\/span><\/p>\n

Sometimes companies change their mind\u00a0<\/b><\/h5>\n

While it hasn\u2019t yet happened with Terraform, sometimes companies who have switched to a more restrictive license change their mind and switch back.\u00a0<\/span><\/p>\n

Most recently, Elastic <\/span>announced<\/span><\/a> in August that it was adding the GNU Affero GPL license as a way to license the code for Elasticsearch and Kibana, which meant that the projects were officially considered open source again.\u00a0<\/span><\/p>\n

\u201cIn 2021, we made the hard decision to move the Open Source portions of Elasticsearch and Kibana source code to non-OSI approved software licenses — SSPL and Elastic License v2, as a way to reduce the risk of market confusion. Over the last 3 years, the change has been successful in mitigating the risks, our innovations since that date have been extensive and material for differentiation, performance, and feature enhancement, and we now feel comfortable adding AGPL as an option alongside SSPL,\u201d Elastic wrote in an <\/span>FAQ<\/span><\/a>.\u00a0<\/span><\/p>\n

OSI\u2019s Maffulli commented on the change at the time, saying, \u201cTheir licensing decisions announced this week are confirmation that shipping software with licenses that comply with the Open Source Definition is valuable\u2014to the maker, to the customer, and to the user. Their choice of a strong copyleft license signals the continuing importance of that license model and its dual effect: one, it\u2019s designed to preserve the user’s freedoms downstream, and two, it also grants strong control over the project by the single-vendor developers.\u201d<\/span><\/p>\n

How consumers of OSS can prepare for unexpected license changes<\/b><\/h5>\n

All of these past license changes should serve as a reminder to the open source community that they need to have a plan in place for what they will do if a project they are using makes a change like this. Often, there is not much time between the initial announcement and the first release under the new license, which may result in development teams needing to scramble if they have not prepared for this potential.<\/span><\/p>\n

According to Tzvika Shahaf, VP of product management of Puppet by Perforce (the company that owns the open source support solution <\/span>OpenLogic<\/span><\/a>), having a software bill of materials (SBOM) is an important document when building using open source components, not just for software supply chain security, but for dealing with situations like this.\u00a0<\/span><\/p>\n

\u201cFor use at enterprise scale, it’s a must to keep things in control and have that visibility across the organization,\u201d he said.\u00a0\u00a0<\/span><\/p>\n

He also said that he\u2019s seeing more companies building teams or roles whose responsibility it is to manage the open source components the organization is using, which can help with other challenges related to open source as well. Beyond managing license compliance, there are a number of other pain points companies face when working with open source software, as laid out in OpenLogic by Perforce\u2019s <\/span>2024 State of Open Source Report<\/span><\/a>:<\/span><\/p>\n