Navigating unexpected license changes in open source software

Open source software is prevalent in almost any codebase today, and that’s probably not changing anytime soon. 

According to a 2024 analysis by the Harvard Business School, 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’s easier to see how the financial benefits of using open source are just too good for most companies to turn their nose at. 

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.

For context, there are a variety of types of open source licenses, typically falling into two categories: permissive and copyleft, according to a blog post by OpenLogic by Perforce.  

Permissive licenses, such as the MIT License and the Apache 2.0 License, “grant users freedom in using, modifying, and distributing the software.” 

Copyleft licenses, on the other hand, “require any derivative works to be distributed under the same license as the original software, which includes making the source code available under that license.” The GNU General Public License (GPL) family of licenses and the Mozilla Public License are examples of copyleft licenses

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

It was originally created by MariaDB and specifies that a project’s source code be available, but using the code in production may require approval from the licensor. 

MariaDB isn’t unique in creating a new license to suit its business needs. For example, Redis also created its own license called the Redis Source Available License, Elastic created the Elastic License, and MongoDB created the Server Side Public License. 

According to Stefano Maffulli, executive director of the Open Source Initiative (OSI), the main motivation behind a change like this is to “lock up the value of the project and discourage competition.” For instance, Elastic has initially created the Elastic License in response to AWS offering Amazon Elasticsearch Service. 

Shay Banon, the founder and CTO of Elastic, wrote in a blog post at the time: “Our 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 – enough is enough.”

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. 

It’s important that open source projects build trust 

“There’s nothing inherently wrong with proprietary and source-available licenses,” said Maffulli. “Where 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.”

In most of the situations when this has happened, there has been backlash 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’ve got different rules to comply with. They might even need to think about an alternative if their use case doesn’t fit in with the new terms.

“When 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’s feet,” said Maffulli. “It is an unexpected, unfair and deceptive ‘switcheroo’ that breaks the trust of the open source community, especially the trust of contributors and users of the project.”

AB Periasamy, co-CEO of MinIO, an open source object store, advises open source projects to think about these decisions in terms of their overall brand. “Brand is about the trust and relationship you establish with your users.” 

Trying to monetize an open source project is ‘short term thinking’

In light of Cockroach Labs recently switching up its licensing again, the open source database YugaByteDB doubled down on being open source. 

“As 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,” Karthik Ranganathan, founder and co-CEO of Yugabyte, wrote in a blog post. 

For some historical context, Cockroach Labs in 2019 changed its license from Apache 2.0 to the BUSL, and then in August, announced 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.

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. 

This informs YugaByte’s long-term strategy of remaining open source so that they are the easiest database choice. In an interview with SD Times, Ranganathan said, “Why would a developer pick something that’s not open or less open? It just won’t work.”

Specifically in the database world, he explained that the “dollars are not in the database tech,” they’re in the applications built on top of that database. 

“It’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,” he said. Capturing the value on top often means creating an enterprise offering with support or extra features.

Capture the value on top

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. “The business helps sustain the open source project because we get paid by customers who can afford to pay, and we deliver enormous value,” he said. 

In MinIO’s case, paying customers to the open source project get extra features, rather than features being taken away from the underlying project.

Many other companies follow this model to fund the development of their projects, such as Grafana Labs, 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. 

Red Hat also follows a similar model, offering open source projects backed by enterprise support, hosting, consulting, and other services. 

“Software 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,” said MinIO’s Periasamy.

Terraform’s switch to the BUSL leads to creation of OpenTofu

Sometimes when license changes happen, it also leads to someone creating an open version of the project, such as what happened 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 “this [license] change threatens the entire community and ecosystem that’s built up around Terraform over the last 9 years.”

Roni Frantchi, director of engineering at env0 and founding member of OpenTofu, said that the response was a bit empathetic at first. We said, “Okay, that makes sense that a commercial company looks at the cost of maintaining such an open source project and says ‘it’s not right that I’m the only one who kind of bears the effort in trying to maintain this project.’”

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. 

However, that appeal went unanswered, Frantchi said, and that’s what led to the community publishing the manifesto, which garnered a lot of support rather quickly. 

“We 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,” said Fratchi. “And 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.”

In addition to creating the open fork of Terraform, another big item on OpenTofu’s to-do list was tackling the backlog of community requested features that had gone unanswered, possibly because they didn’t align with the direction HashiCorp wanted to take the project. 

“Now 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,” he said.

Sometimes companies change their mind 

While it hasn’t yet happened with Terraform, sometimes companies who have switched to a more restrictive license change their mind and switch back. 

Most recently, Elastic announced 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. 

“In 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,” Elastic wrote in an FAQ. 

OSI’s Maffulli commented on the change at the time, saying, “Their licensing decisions announced this week are confirmation that shipping software with licenses that comply with the Open Source Definition is valuable—to 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’s designed to preserve the user’s freedoms downstream, and two, it also grants strong control over the project by the single-vendor developers.”

How consumers of OSS can prepare for unexpected license changes

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.

According to Tzvika Shahaf, VP of product management of Puppet by Perforce (the company that owns the open source support solution OpenLogic), 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. 

“For use at enterprise scale, it’s a must to keep things in control and have that visibility across the organization,” he said.  

He also said that he’s 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’s 2024 State of Open Source Report:

79% struggle with maintaining security policies
42% have difficulty maintaining end-of-life versions
40% lack high-level technical support
38% lack of skills, experience, and proficiency on their team
34% experience issues with installations, upgrades and configurations

In addition to being able to better tackle those challenges, it’s likely that the industry will continue seeing examples of open source projects switching up their licensing in the years to come, so preparing now may save some trouble down the line. 

“Unfortunately, we’ll probably always encounter companies that want to harness the power of Open Source networks to achieve a certain level of adoption, only then to drop the community like a hot potato,” said Maffulli.

The post Navigating unexpected license changes in open source software appeared first on SD Times.

Source: Read More