Open source software has become a cornerstone of modern development, and its influence continues to expand. A recent analysis by Harvard Business School in 2024 highlights this trend, revealing a supply-side valuation of open source software at $4.15 billion, while its demand-side value soars to $8.8 trillion. Such figures illustrate why many businesses find the advantages of utilizing open source software hard to resist.

However, the landscape has seen troubling instances where popular open source projects have unexpectedly transitioned to more restrictive licenses, creating challenges for developers who have integrated these projects into their applications.

To provide some context, open source licenses generally fall into two main categories: permissive and copyleft, as explained in a blog post by OpenLogic, a division of Perforce.

Permissive licenses, like the MIT License and Apache 2.0 License, allow users significant freedom in using, modifying, and sharing the software. In contrast, copyleft licenses mandate that any derivative works must be distributed under the same license as the original, ensuring that the source code remains available under those terms. Examples include licenses from the GNU General Public License (GPL) family and the Mozilla Public License.

Recently, there has been notable discussion surrounding the Business Source License (BUSL), as some prominent projects, such as Terraform by HashiCorp, CockroachDB, and MariaDB, have adopted this license. However, it’s important to note that BUSL is not classified as an open source license, and thus does not fit into the aforementioned categories.

Originally created by MariaDB, the BUSL stipulates that while the source code must be accessible, approval from the licensor may be required for production use. This trend of developing new licenses to suit business goals isn’t isolated to MariaDB; Redis, Elastic, and MongoDB have also introduced their own licenses.

Stefano Maffulli, executive director of the Open Source Initiative (OSI), notes that such changes are often motivated by the desire to “secure the value of the project and deter competition.” For example, Elastic created the Elastic License in response to AWS launching its Amazon Elasticsearch Service, which they felt undermined their efforts.

Maffulli emphasized that organizations shifting to more restrictive licenses typically do so after gaining substantial traction and are looking to monetize their projects while preventing others from profiting from their hard work.

Building Trust in Open Source Projects

“There’s nothing inherently wrong with proprietary and source-available licenses,” Maffulli stated. “The issues arise when organizations make mid-course license changes or manipulate branding to make their restrictive licenses seem like Open Source-approved licenses, causing confusion.”

When such changes occur, the open source community often reacts negatively. Developers who have integrated a project based on its original license may find themselves facing new compliance challenges. In some cases, they may even need to seek alternatives if their use cases no longer align with the updated terms.

“When a company transitions from an open source license to a restrictive one like BUSL, it’s akin to pulling the rug out from under the user community,” Maffulli remarked. “This unexpected and unfair shift erodes the trust of contributors and users alike.”

AB Periasamy, co-CEO of MinIO, an open source object storage solution, advises open source projects to carefully consider the implications of such decisions on their brand, as brand trust is crucial for user relationships.

Short-Term Thinking in Monetization Strategies

The recent licensing changes by Cockroach Labs prompted YugabyteDB to reaffirm its commitment to open source. Karthik Ranganathan, co-CEO of Yugabyte, expressed empathy for the revenue pressures that led to Cockroach’s shift but criticized it as “short-term thinking” that could hinder long-term growth.

Historically, Cockroach Labs moved from an Apache 2.0 license to BUSL in 2019 and then announced the retirement of its free Core offering in favor of an Enterprise version, which would only remain free for companies generating less than $10 million annually.

Ranganathan argued that developers and smaller organizations might be reluctant to adopt CockroachDB, knowing that growth could result in new restrictions on their usage of the database. His company’s long-term strategy involves maintaining an open source model to ensure it remains the preferred database choice. He stated, “Why would developers choose a less open option when there are fully open alternatives available?”

He further elaborated that the true financial rewards lie not in the database technology itself, but in the applications built on top of it. “It’s better to allow broad adoption and encourage contributions, capturing value later through enterprise offerings that provide support and additional features,” he added.

Sustainable Open Source Models

MinIO has adopted a sustainable business model by keeping its core project open source while offering an enterprise version that provides additional features. Periasamy explained that the revenue generated from paying customers enhances the value of the open source project rather than detracting from it.

Other companies, like Grafana Labs, also follow this approach, offering both free and paid versions of their observability platform, each with distinct features. Similarly, Red Hat provides open source projects along with enterprise support, hosting, and consulting services.

“Developing and maintaining software is resource-intensive and requires a dedicated team of engineers. Finding a way to sustain it financially is crucial,” said Periasamy.

The Birth of OpenTofu

License changes can sometimes catalyze the creation of open forks of projects. For instance, when HashiCorp transitioned Terraform to BUSL, the community rallied to form an open alternative known as OpenTofu. They issued the OpenTF Manifesto, asserting that the licensing shift jeopardized the community and ecosystem built around Terraform over the past nine years.

Roni Frantchi, director of engineering at env0 and a founding member of OpenTofu, noted the initial understanding within the community regarding HashiCorp’s need to manage project costs. However, after their appeal to HashiCorp to contribute the project to a foundation went unanswered, the community decided to proceed with a fork, gathering significant support along the way.

The manifesto quickly gained traction, amassing over 36,000 stars within days, showcasing the community’s backing for an open source approach. They engaged with the Linux Foundation and CNCF, who were receptive and supportive of the initiative.

Alongside forking Terraform, OpenTofu also prioritized addressing community-suggested features that had previously been neglected, ensuring a transparent roadmap for development.

Reversing License Changes

While it’s not common, some companies do reconsider their licensing decisions. Recently, Elastic announced that it would reintroduce the GNU Affero GPL license for Elasticsearch and Kibana, effectively reinstating their status as open source projects.

“In 2021, we made the tough choice to transition the Open Source portions of Elasticsearch and Kibana to non-OSI approved licenses to mitigate market confusion. After three years, we are confident in adding AGPL alongside our previous licenses,” Elastic explained in an FAQ.

Maffulli commented that this decision reaffirms the value of licensing that complies with the Open Source Definition, benefiting creators, customers, and users alike. The choice of a robust copyleft license emphasizes the importance of preserving user freedoms while allowing developers to maintain strong control over their projects.

Preparing for License Changes in Open Source Software

These license changes serve as a crucial reminder for the open source community to be prepared for similar shifts in the future. Often, the window between the announcement and the implementation of a new license can be quite short, leaving development teams scrambling if they haven’t planned for such eventualities.

Tzvika Shahaf, VP of Product Management at Puppet by Perforce, emphasizes the importance of maintaining a software bill of materials (SBOM) when utilizing open source components. This not only aids in software supply chain security but also assists in navigating potential licensing challenges.

He notes an increasing trend of companies establishing dedicated roles or teams to manage their open source components, addressing not just license compliance but also various other issues related to open source adoption. According to OpenLogic’s 2024 State of Open Source Report, many organizations face challenges such as:

• 79% struggle with maintaining security policies
• 42% encounter difficulties with outdated versions
• 40% lack sufficient technical support
• 38% have a deficit of skilled personnel
• 34% face issues with installations and configurations

Being proactive in addressing these challenges can not only help organizations adapt to future licensing changes but also mitigate various risks associated with open source software.

“Unfortunately, the industry will likely continue to see companies leveraging open source for adoption, only to abandon the community when it no longer serves their interests,” Maffulli concluded.