In recent years, a growing number of prominent software companies have changed the licenses on their projects, moving away from traditional open source licenses toward new models often described as source-available. These shifts have sparked heated debates about what open source really means, who benefits from it, and whether the traditional definitions still serve the community well. Understanding the nuances of this licensing landscape is essential for any developer or organization that builds on top of community software.
What Makes a License Open Source
The Open Source Initiative (OSI) maintains the Open Source Definition, a set of ten criteria that a license must satisfy to be considered open source. The core requirements include free redistribution, access to source code, the right to create derived works, no discrimination against persons, groups, or fields of endeavor, and no restrictions on how the software is used.
Licenses that meet these criteria include the MIT License, Apache License 2.0, GNU General Public License (GPL), BSD licenses, and the Mozilla Public License (MPL). These licenses have been battle-tested over decades and are well understood by the legal community.
The key principle underlying all OSI-approved licenses is that anyone can use the software for any purpose, including purposes that compete with the original developer. This is both the great strength of open source and the source of the tension that has driven the recent licensing debates.
What Source-Available Means
Source-available licenses allow users to view, and sometimes modify, the source code, but they impose restrictions that disqualify them from the OSI's open source definition. The most common restriction is a prohibition on using the software to offer a competing commercial service.
Several new licenses have emerged in this category:
- Server Side Public License (SSPL), created by MongoDB in 2018, requires anyone who offers the software as a service to release the complete source code of their entire service stack under the SSPL. The OSI rejected this license as non-conformant with the open source definition.
- Business Source License (BSL), originally created by MariaDB, allows free use for most purposes but restricts specific commercial uses. It includes an automatic conversion to an open source license after a specified period, typically three or four years.
- Elastic License 2.0 (ELv2) permits most uses but prohibits offering the software as a managed service and prohibits circumventing license key functionality.
- Functional Source License (FSL) is a newer entrant that restricts competitive use for two years before converting to either MIT or Apache 2.0.
Why Companies Are Making the Switch
The primary driver behind most license changes is the rise of cloud computing. When a company releases software under a permissive open source license, cloud providers can take that software, offer it as a managed service, and capture the majority of the revenue without contributing meaningfully back to the project. This dynamic has been described as the cloud provider free-rider problem.
The Economics of Open Source Companies
Building a company around open source software typically relies on selling enterprise features, support contracts, or managed hosting. When a hyperscale cloud provider offers the same software as a managed service with superior infrastructure and integration into their ecosystem, the original company faces intense competitive pressure despite having created the technology.
Redis, MongoDB, Elasticsearch, HashiCorp, and Sentry are among the high-profile projects that have changed licenses in response to this dynamic. Each cited similar motivations: they needed to protect their ability to invest in the project's development while preventing competitors from capturing the value they created.
The Community Perspective
Critics of these license changes argue that companies benefited enormously from the open source ecosystem during their growth phase, attracting contributors, building community trust, and gaining adoption precisely because the software was truly open. Changing the license after achieving market dominance is seen by many as a bait-and-switch that undermines the social contract of open source.
When Elasticsearch changed its license, AWS responded by forking the project as OpenSearch, demonstrating that the open source community can route around license restrictions when the codebase was previously open. Similar forks have emerged in response to other license changes, including Valkey as a fork of Redis.
The Spectrum of Openness
Rather than a binary distinction between open and closed, software licensing exists on a spectrum:
- Fully open source with permissive licenses (MIT, Apache 2.0) imposes almost no restrictions on use.
- Copyleft open source (GPL, AGPL) requires derivative works to be distributed under the same license, ensuring that modifications remain open.
- Source-available with delayed open source (BSL, FSL) restricts certain uses for a limited period before converting to a standard open source license.
- Source-available with permanent restrictions (SSPL, ELv2) allows viewing the code but permanently restricts certain commercial uses.
- Proprietary with visible source allows code inspection but prohibits modification and redistribution.
The AGPL Alternative
Some argue that the GNU Affero General Public License (AGPL) already addresses the cloud provider problem without abandoning the open source definition. The AGPL extends the GPL's copyleft requirements to network use: if you modify AGPL software and offer it as a service, you must release your modifications under the AGPL.
However, the AGPL has limitations in practice. Many companies, particularly large enterprises, have policies that prohibit using AGPL software due to concerns about the scope of its copyleft requirements. This can limit adoption, which is precisely what companies switching licenses are trying to avoid. Additionally, the AGPL does not prevent unmodified use as a competing service, only requiring disclosure of modifications.
Impact on Developers and Organizations
For individual developers, the practical impact of source-available licenses is often minimal. Most developers use these tools internally or for personal projects, uses that remain permitted under virtually all source-available licenses. The restrictions primarily affect companies that want to offer managed services based on the software.
For organizations evaluating software dependencies, the license choice matters more significantly. Source-available licenses may limit future options, particularly if the organization might eventually want to offer hosted services. They also introduce legal complexity, as these newer licenses lack the decades of judicial interpretation that traditional open source licenses have accumulated.
Looking Forward
The licensing debate is unlikely to be resolved anytime soon. The fundamental tension between sustaining commercial investment in open source projects and maintaining the freedoms that make open source valuable is real and deeply felt on both sides.
What seems clear is that the binary framing of open versus closed is no longer sufficient. The software industry needs more nuanced vocabulary and frameworks for evaluating the tradeoffs between different licensing models. Developers, companies, and communities all benefit when these discussions are grounded in a clear understanding of what each license actually permits and restricts, rather than in ideological absolutes.
For anyone choosing a license for a new project or evaluating dependencies, the most important step is reading the actual license text and understanding its implications for your specific use case. Labels like open source and source-available are useful shorthand, but they are no substitute for understanding the specific terms you are agreeing to.
