Relicensing: The Source-Available Wave, and the Forks That Answered

A license change is the moment a project says out loud who it was for. Between 2018 and 2025, MongoDB, Elastic, HashiCorp, Redis and others answered “not for the cloud providers” and moved to licenses that aren’t open source; the community answered with forks, and Elastic and Redis later added an open-source license back. Here’s the timeline, the licenses, and what it changes when you pick a dependency, sign a CLA or choose a license.

Popular, resold as a service, relicensed, forked#

The cases below differ in the details and share a shape:

1. A company owns the project. It employs most maintainers, holds the trademark, and often asks outside contributors to sign a contributor license agreement (CLA).
2. The project becomes infrastructure. A database, a search engine, a provisioning tool: something people run as a service.
3. Cloud providers sell it as a service. The license allows it, and the provider doesn’t have to contribute back or pay.
4. The company changes the license of future releases to one that forbids offering the software as a competing service.
5. The community forks the last open-source release, often with the backing of the cloud providers the change was aimed at, and a foundation takes the fork.

MongoDB’s press release says it plainly: its popularity had led “some organizations to test the boundaries of the AGPL” (MongoDB, October 16, 2018). Elastic’s announcement names Amazon (Elastic, January 14, 2021).

The timeline, 2018–2025#

Every date comes from the company’s or the fork’s own announcement.

Two more dates explain the rest of the story. IBM completed its acquisition of HashiCorp on February 27, 2025: Terraform’s license now names IBM as the licensor. And in May 2025, Synadia asked to take NATS out of the Cloud Native Computing Foundation (CNCF) and move its server to the BSL; the settlement of May 1, 2025 kept NATS under Apache-2.0, with its trademarks at the Linux Foundation. A project whose name and repository belong to a foundation can’t be relicensed by one company.

Five licenses, none of them open source#

Each company wrote its own license, or took one off the shelf. They differ in what they forbid and whether they expire:

The Commons Clause, used by Redis Labs in 2018, isn’t a license but a condition added on top of one: it takes away the right to sell the software, hosting and support included.

• None is open source. The Open Source Definition forbids discriminating against a field of use, and each of these rules one out. The OSI said so of the SSPL in a statement of January 19, 2021. The BSL says it itself: its text reads that it “is not an Open Source license”.
• BSL and FSL expire. Every release of a BSL project turns into an open-source license (the “Change License”) on its Change Date; the FSL does it after two years. Terraform 1.6.0, the first release under the BSL, becomes MPL-2.0 four years after its publication.
• BSL-1.0 is the Boost license. The SPDX identifier of the Business Source License is BUSL-1.1: a manifest that says BSL-1.0 declares a permissive license.

In August 2024, Sentry launched Fair Source, a name for licenses like the FSL: source available, free for most uses, open source after a delay. It’s a label, not an OSI category.

Old versions keep their license, so forks can start from them#

A license change applies to the releases published after it. Everything published before stays under the old license, and anyone can keep developing it. Every fork in the timeline started from the last open-source release:

Two things made these forks last. They had backers: AWS started OpenSearch; Valkey launched with AWS, Google Cloud, Oracle, Ericsson and Snap; OpenTofu with companies that sold services on top of Terraform. And a foundation holds them, so no single company can do to the fork what was done to the original.

A fork diverges from the day it starts. OpenTofu 1.6.0 shipped on January 10, 2024, and Terraform and OpenTofu have added different features since. Switching from one to the other is easy in the first months, and gets harder with every release.

A CLA is what makes relicensing possible#

Choosing a License covers the rule: you can only relicense what you own. The license of the code decides how much the company needs from its contributors.

• Permissive code (MIT, BSD, Apache-2.0) already lets anyone ship it under other terms, as long as the notices stay. Redis, under BSD-3-Clause, could move to RSAL without asking anyone.
• Copyleft code (MPL, GPL, AGPL) can only be relicensed with every contributor’s agreement, or a CLA that grants that right. Terraform, under MPL-2.0, asks for one (its contributing guide).

Elastic’s CLA states the purpose in one sentence: it doesn’t transfer copyright, but gives Elastic “the right to distribute your code without restriction” (Elastic’s contributing guide). That’s what a CLA is for, and it’s why a copyleft project that uses the Developer Certificate of Origin (DCO) instead, like the Linux kernel, can’t be relicensed by anyone.

What it changes for you#

When you deploy it#

• Check the license of each release, not of the project. Pinning an old version keeps the old license; upgrading past the change date accepts the new one.
• Read the Additional Use Grant. Each BSL licensor writes its own. Terraform’s allows production use, except offering it “to third parties on a hosted or embedded basis” to compete with IBM’s paid version, and says internal use doesn’t compete (Terraform’s LICENSE). What counts as competing is the licensor’s call, and it can change with the licensor’s product line.
• Prefer infrastructure a foundation holds when you can choose. It’s no guarantee, but it’s a license change that needs more than one company’s decision.

When you contribute#

• Read the CLA before you sign it. If it grants the company the right to relicense your contributions, your code can end up under a license that isn’t open source. Many contributors sign anyway: it’s a decision to make with the facts.
• A DCO only asks you to certify that you may contribute your code. It grants the project no other right, relicensing included. CLA or DCO compares the two.

When you found a company around your project#

• The reason to relicense is real. A cloud provider selling your software without contributing takes customers you need to pay the people who write it.
• So is the cost. Four of the changes got a fork that lasted, two of them backed by the cloud providers the change was aimed at, and Elastic and Redis came back to an open-source license within four years.
• Decide before the first contributor. A project that starts under the FSL or the BSL tells contributors and users what it is on day one. Changing the license of a popular project breaks a promise people built on.

The other direction: AGPL-3.0#

Some companies facing the same problem chose a license that is open source and still closes the SaaS gap: AGPL-3.0, which asks anyone running a modified version as a service to offer its source (License Compatibility explains the gap).

AGPL-3.0 is a compromise that holds: an open-source license the OSI approved, that competitors are reluctant to use, since running a modified version as a service means publishing the changes. Google forbids it internally; that’s the point.

A license doesn’t keep a project open by itself, though. MinIO, still under AGPL-3.0, put its repository in maintenance mode on December 3, 2025. Since February 12, 2026, its README opens with “THIS REPOSITORY IS NO LONGER MAINTAINED” and lists editions of AIStor, its commercial product, as the alternatives (minio/minio). The license keeps every published version open. Nothing obliges the company to publish the next one.

Do this now#

• List the databases, search engines and infrastructure tools you run, and check the license of the exact version you deploy.
• For each one under the BSL, read its Additional Use Grant, and write down why your use is allowed.
• Before a big contribution to a company-owned project, read its CLA and check whether it lets the company relicense your code.
• If you’re starting a company around your project, pick its license now, the way you’d pick it if the project got popular.

Go further#

• The SSPL is not an open source license, by the OSI: why, in the words of the organization that decides.
• HashiCorp adopts the Business Source License and the OpenTofu announcement: both sides of one change, from the people who made them.
• Introducing the Functional Source License, by Sentry: the case for delayed open source, from a company that uses it.
• License Compatibility: what you can combine, and the tools that read your dependencies’ licenses.