In recent years several widely used projects have changed license, moving from open source licenses to licenses that allow you to read the code but restrict its use. These licenses are often called source-available: the source is available, but not all the conditions of the Open Source Definition are met. For anyone choosing software, telling the two categories apart is essential, because the practical consequences are very different.
What is missing compared with open source
The Open Source Definition, maintained by the Open Source Initiative, requires among other things that a license must not discriminate against persons, groups or fields of endeavour. This is precisely where source-available licenses diverge: they forbid specific uses, typically offering the software as a managed service in competition with the author.
So a piece of software can have public code in a repository, accept contributions and have a community, and still not be open source.
The most common licenses
Business Source License (BSL or BUSL)
The BSL was created by MariaDB. The way it works is distinctive:
- the code can be read and modified;
- production use is forbidden or limited, except for what is allowed in a field called the "Additional Use Grant", which each project defines in its own way;
- after a period stated in the license, at a Change Date, the code of that version automatically switches to an open source license chosen by the author.
It is a time-limited model: each version stays restricted for a while, then becomes free. In 2023 HashiCorp adopted the BSL for several products, including Terraform.
Server Side Public License (SSPL)
Introduced by MongoDB in 2018, the SSPL resembles the AGPL but with a much broader requirement: anyone offering the software as a service must also publish under the SSPL all the software used to provide that service, such as management, monitoring, backup tools and interfaces. The SSPL was submitted to the Open Source Initiative and then withdrawn, without approval; it is generally considered not open source.
The Elastic License and similar
Other licenses, such as the Elastic License 2.0, are shorter and more direct: they allow use and modification but forbid offering the software as a managed service and circumventing features protected by a license key.
Why companies adopt them
The stated motivations are usually economic: a company invests in developing a project, and large cloud providers offer it as a paid service without contributing proportionally. By changing the license, the company tries to reserve the managed service market for itself.
What happens to the community
License changes have often triggered forks, meaning copies of the project maintained from the last open source version. Some well-known examples:
| Original project | License change | Open source fork |
|---|---|---|
| Terraform | to BSL in 2023 | OpenTofu |
| Redis | to source-available licenses in 2024 | Valkey |
| Elasticsearch | to SSPL and Elastic License in 2021 | OpenSearch |
Forking is possible because versions already published under an open source license remain so: a license cannot be revoked retroactively on copies already distributed.
What it means for users
The questions to ask are concrete:
- How do I use it? For internal use, many source-available licenses pose no problem. For those offering managed services to customers, they can be a serious obstacle.
- What does the Additional Use Grant say? In the BSL this field decides almost everything, and it varies from project to project.
- Who accepts contributions? Contributions often require signing an agreement that lets the company relicense them.
- Is there an active fork? If so, it is worth assessing its health and compatibility.
- Do past versions remain usable? Yes, under the terms they were released with, but without security updates from the original project.
How to recognise them
- The license does not appear among those approved by the Open Source Initiative.
- The text contains restrictions on managed services, competition or production use.
- There is a future date that changes the license.
- The standard identifier differs from the common ones: for example
BUSL-1.1,SSPL-1.0orElastic-2.0.
In my work, when I assess a component for a client, I always point out the difference explicitly: "code on GitHub" does not automatically mean an open source license.
In short
- Source-available licenses make the code visible but forbid some uses, so they are not open source.
- The BSL limits production use and converts each version to open source after a set date.
- The SSPL extends obligations to the whole stack used to offer the service.
- License changes have produced forks such as OpenTofu, Valkey and OpenSearch.
- Before adopting a component, read the usage restrictions rather than just checking that the code is public.
