How open source foundations protect the licensing integrity of open source projects

What would you do if you awoke today to see news that future versions of the Linux kernel will be licensed under the Business Source License (BUSL)? The BUSL prevents production use of the software unless the user falls within an additional use exception. Suddenly, you would have to evaluate every place someone in your organization deployed Linux, along with whatever restrictions each licensor might impose -- such as whether it competes with any service or offering from the BUSL licensor, and whether or not your use is in a production environment. Compounding this difficulty, each company’s BUSL license is different from other companies’ BUSL licenses because of the additional use exceptions. 

After reading all the requisite FAQs for a BUSL license, you would probably feel like the Linux kernel community fooled you with a “bait and switch” shakedown. The open source and free software Linux kernel project you knew and trusted would effectively be over - it would now be a pure proprietary product play. Maybe the kernel community would add an additional use exception for some users (academics, perhaps), or, maybe not.

It’s important to note that many or all of these BUSL relicensed projects have OSI-approved license projects in their dependency trees. Many of the relicensed projects rely on thousands of packages and modules under OSI-approved open source licenses. The companies relicensing often cite the motivation as the need to prevent tech companies from taking all their business. However, there doesn’t seem to be a problem building their BUSL products on Linux and thousands of open source projects they depend on in their codebase. What would many of these companies do if projects like OpenSSL and curl decide to relicense as proprietary tomorrow?

License changes are comparable to a single point of failure risk in any project. A company will provide the open source project with no warranties, and no support, and if someone wants those guarantees, they can pay for them as a value add in addition to the codebase. If that company were to go bankrupt, or were acquired and relicensed, users would be in the same situation. 

If a license change happens, the community can continue the open source project under the true open source license, as we recently saw with the community involved in OpenTofu.

Part of the greatest value that open source foundations bring is the creation of a neutral collaboration hub for everyone participating in, and taking a dependency on, a project. The Linux Foundation (and others like it) offer their communities:

• Distributed ownership
• Level playing field
• De-risking open source
• Open community governance

Distributed ownership

The Linux kernel relies upon a distributed copyright ownership structure. One great strength of the Linux kernel licensing model is that no single person or entity owns all the copyrights for the Linux kernel. To get all the copyright owners of the Linux kernel to relicense to the Business Source License would be impracticable (and perhaps, laughable) at best. The BUSL is a “source available” license where the code is visible, but there are restrictions on whether, or how, it can be used - which is the antithesis of what the Linux kernel community has been working towards for decades.

License switches are not new. There’s a trend where a small number of venture-backed companies invest in building interesting open source software and create large user communities around them, but when the business matures, they switch the license to drive a new revenue bump. In 2018, MongoDB re-licensed its code under the SSPL (server side public license), and afterward Elastic did so in 2021. More recently, Hashicorp changed its license for much of its software (e.g., Terraform, Vault, Vagrant, etc.) from an open source license to the Business Source License. One helpful move Hashicorp made was to retain certain libraries and components under MPL-2.0 even though the headline message was that everything going forward would be BUSL-licensed. A list of other well-known licensing changes from open source to source available is referenced in the table below. 

To be clear, we recognize that copyright owners have the legal right to license their copyright-protected code however they want. But are their actions fair for the open source community? How about for projects that have received significant code contributions from others in the community? Community involvement through contributions, documentation, and reference architectures helped build these impressive ecosystems, none of which would have happened if the projects were originally BUSL licensed. Community contributors, users, and developers became advocates for these codebases because they were open source and available to anyone without restriction. Changing the license under users’ feet only after users took a reliance on the software is a poor way to thank them. An old saying comes to mind: “fool me once, shame on you; fool me twice, shame on me.”

Level playing field 

While there is certainly a valid debate around whether an open source license is appropriate for a particular project, this is not the heart of the problem. The problem is not one of merely licensing but rather one of a level playing field. For over a decade, the Linux Foundation (and other similar foundations) have required trademarks for their projects to be owned by the foundation for use by the project community. This requirement was always about ensuring that one company in the ecosystem couldn’t exert undue control over the project by owning the trademark. As we wrote in 2020:

Neutral control of trademarks is a key prerequisite for open source projects that operate under open governance. When trademarks of an open source project are owned by a single company within a community, there is an imbalance of control. The use of any trademark must be actively controlled by its owner or the owner will lose the right to control its use. The reservation of this exclusive right to exercise such control necessarily undermines the level playing field that is the basis for open governance. This is especially the case where the trademark is used in association with commercial products or solutions.

De-risking open source

When large portions of a community rely on widely used software because of the open source license, and the license changes without input from the community, this makes it harder to rely upon, and trust, single company-owned open source in the future. After the license change, leadership in companies reliant on the project - but who are often not closely involved - see their teams ask for emergency funding to pay for a commercial license they never needed before. Those leaders often take away the notion that “open source is risky - they can change the license,” without understanding any of the nuance. To them, risk equates to cost, and risk must therefore be managed.

Unfortunately, many people unaware of the nuance may assume that license change is a risk for all open source. It is not. What the recent Terraform license change brings to the surface is the need for developers and organizations to carefully scrutinize which open source they decide to depend upon. Open source software’s risks (or in most cases, non-risks) are well known, and we have tools to manage license compliance, software supply chain, and other risks. OpenChain, SPDX, OpenSSF, Sigstore, and SLSA are a few examples of community solutions for risk management that have proven that risk can be effectively managed. 

No open source project in a community-focused foundation has ever relicensed to source available for a number of reasons. First, the developer community would reject it. Second, nonprofit foundations cannot inure to the benefit of any one company. Third, the users would reject it. Fourth, it would not help the diffusion of the project. Finally, the project boards would certainly reject it. The list goes on and on.

Open community governance

For larger, widely-used, or depended-upon projects, nonprofit open source foundations can help. The most prominent open source foundations all use community-based decision models for licensing. Foundations provide an opportunity for multiple stakeholders to participate in governance, where the contributors doing the work make the decisions, which is the essence of a “do-ocracy”. This way, a single company or organization cannot make unilateral license changes. Under a foundation, project decisions are made as a community. 

Foundations are often registered as nonprofit organizations. Source available licenses like the BUSL inure benefits to one company — something a nonprofit is generally legally barred from supporting. In the Linux Foundation’s case, the foundation encompasses a collection of tax-exempt nonprofit entities in the United States and around the world for hosting projects that use open source licenses. Source available licenses are not open source licenses and would likely conflict with a foundation’s declared purpose for tax exemption, and therefore would not be available as an option for the foundation to use for its projects.

The Linux Foundation’s projects accept contributions under two pathways. The first and most common model is that contributors retain their copyright ownership but provide a license (under the open source license chosen by the project) to their contributions, typically reflected within the contributions themselves via the Developer Certificate of Origin (DCO) sign-off process. The second, less common model is that contributors sign a Contributor License Agreement (CLA) with the foundation granting the set of rights specified in that project’s CLA, and then the foundation makes the code available under the project's license. In either case, the community of contributors would have to collectively all agree to change the license of the project; and the foundation’s tax-exempt purpose and bylaws would themselves impose limitations on which licenses could be permitted. Therefore, the foundation approach to licensing creates a significant barrier to a license change for a project community to use a source-available license.

Many other (though not all) critical open source projects are governed not by individual companies but by open source foundations, such as the Apache Software Foundation, Eclipse Foundation, Open Infrastructure Foundation, Python Software Foundation, Rust Foundation, and more. The presence of foundations provides stability and consistency for those who rely on open source projects that make up our digital infrastructure.

Of course, a foundation is not right for all projects, and foundations need an appropriate open governance structure to be successful. A project should only be transferred to a foundation if there is the intention to allow a diverse community of stakeholders and resources to make such governance work. But the major benefit of a foundation is that it allows participatory governance and prevents a single open source project that is essentially a de-facto standard from being monopolized by a single company. There’s a reason why the most widely used open source projects are hosted under foundations. Foundation models ensure that open source dependencies are reliable, secure, supported by a community, and will stay community-run and available under open source licenses into the future. 

And for all these reasons (and probably more that we didn’t think of yet), you will never see the Linux kernel relicensed as BUSL.

A special thank you to Ashwin Ramaswami and Steve Winslow for contributing expertise and context to this article.

About the author: Mike Dolan is Senior Vice President of Projects, The Linux Foundation

Appendix: Examples of Source Available Relicensing Decisions