Why Open Source Projects Switch Licenses Mid-Stream: The Cost of Relicensing in MongoDB, Elasticsearch, Redis, and Terraform ​

We · October 2026

This is the second article in the "Open Source & Commercial Use" series. 《Why Commercial Companies Open Source》 covers the clause design on the model-weights side; this article covers the older problem on the software and database side: a project changes its license halfway through. Case dates and clauses in this article come from public announcements and industry summaries, queried in October 2026. We don't review, rank, or give legal advice. Specific clauses follow each project's LICENSE file at the time.

1. Get one thing straight first: relicensing is a contract action ​

When a project switches licenses, the reader's first reaction is usually "they broke their promise." This framing isn't accurate, and it blocks you from seeing what you should actually be looking at.

The accurate framing is this: a license is a grant contract, and the author has the right to impose new conditions on versions released going forward. The copy you got under the old terms doesn't become invalid just because they changed the README today. But the version they release tomorrow, you have to negotiate under the new terms.

So "open source project relicensing" isn't a moral incident—it's a repricing. The price changed; you get to decide again which version to use and which path to take.

This is worth a dedicated article because it has happened densely over the past decade. MongoDB, Elasticsearch, Redis, CockroachDB, and Terraform all switched, and the direction was consistent: from permissive licenses to non-standard clauses with commercial restrictions. We want to emphasize: this wave wasn't several companies acting on impulse. It was the result of the same commercial structure squeezing them all.

2. Four relicensing cases: different triggers, strikingly similar costs ​

MongoDB (2018): SSPL was invented to block the "network service" path ​

MongoDB was originally Apache 2.0. The change came after cloud providers turned the database into a managed service: users paid the cloud, and the cloud paid the original authors nothing.

SSPL's logic is: if you offer this database as a service externally, you must open-source the entire corresponding service stack, including the monitoring, orchestration, backup, and logging layers. Its deterrent power sits in the cost. For cloud providers, "open-sourcing an entire infrastructure stack" is essentially equivalent to exiting the business.

The cost was immediately visible. The Open Source Initiative (OSI) explicitly stated in early 2019 that SSPL does not meet the open source definition, and mainstream Linux distributions subsequently removed it from their software repositories. According to industry summaries, both Red Hat and Debian made this move. A codebase that was still technically publicly readable had its "open source" identity stripped. This is practical for users: the distribution you depend on may simply stop providing it.

Elasticsearch (2021 → 2024): switched out and switched back, but the fork had already gone independent ​

This case is the most complete sample in the whole wave, because it has a return trip.

• In January 2021, Elastic announced that new versions of Elasticsearch and Kibana would no longer use Apache 2.0, switching to a dual license of SSPL and Elastic License v2. ELv2's core restriction is you cannot offer it as a managed service externally.
• The direct competitor was AWS's managed Elasticsearch service. AWS's response was to fork from the last Apache 2.0 version (7.10.2) into OpenSearch, releasing 1.0 within 2021. In September 2024, AWS handed OpenSearch's governance entirely to the Linux Foundation.
• In the second half of 2024, Elastic added AGPLv3 back as an optional license, forming a triple-choice of AGPL / ELv2 / SSPL. The company described this as "open source, again."

One thing worth pausing on here: switching back doesn't get the fork back. OpenSearch already has its own foundation, its own distribution, its own plugin ecosystem. All that remains between it and Elasticsearch is "the same historical codebase."

So in the end, the cost of relicensing isn't written in the announcement—it's written in the fork you can't walk away from two years later.

Redis (2024): from BSD to dual license, the Valkey fork ​

In March 2024, Redis abandoned the BSD license it had used for years, switching to a dual license of RSALv2 and SSPLv1. Note the direction: it didn't go from closed source to open source—it went from "the most permissive tier" to "the tier where you have to read the original text." In the BSD era, you didn't even have to think about commercial clauses. After relicensing, the path of "offering it as a service externally" was explicitly narrowed.

The community's move was almost identical to the Elasticsearch case: a group of vendors and community members pushed a fork called Valkey, handed to the Linux Foundation for governance.

One more interesting difference we noticed this time. This time, "whether to trust a single vendor" itself became one of the fork's drivers. Relicensing changes not just the legal boundary, but also contributors' expectations. And expectations determine where R&D resources go.

Terraform (2023): BSL's "delayed open source" structure, and the eve of acquisition ​

HashiCorp switched Terraform, Vault, Consul, and a batch of other products from MPL 2.0 to BSL 1.1 (Business Source License) in August 2023. BSL's mechanism is the most easily misread, and worth explaining separately:

• It's a three-in-one structure: source visible, production use requires authorization, automatic conversion to open source at expiry. BSL was created by MariaDB in 2013; each version carries a Change Date. After that date, that version automatically converts to the specified open source license—HashiCorp specified MPL 2.0.
• So Terraform's restrictions have an expiration date, which is a completely different strategy from "permanently closed source." Concluding "it's not open source anymore, I can't touch it" when you see BSL, and treating it like Apache when you see it, are both wrong. The mistake is not reading the date.

The chain reaction within a month of the relicensing went like this: in August 2023, a group of peer companies co-signed the OpenTF Manifesto; in September of the same year, the fork was named OpenTofu, then entered the Linux Foundation as an independent project, and is now one of Terraform's direct replacements. In February 2025, IBM completed its acquisition of HashiCorp, with public reports putting the enterprise value at approximately $6.4 billion. Relicensing often happens around capital moves; this timing relationship is more straightforward than any explanation.

One side note: CockroachDB switched from Apache 2.0 to BSL as early as October 2019, an earlier case in this wave.

3. The most commonly misunderstood point: do new clauses have retroactive effect on old versions? ​

This is the most practical section of the article. Suppose you cloned a project in 2021 when it was Apache 2.0, and in 2023 it switched to BSL. Does the copy you're using still count?

The conventional understanding is: relicensing governs versions released after the change; versions already released continue to be used under the terms they were released with. Once a grant is given, it generally cannot be unilaterally withdrawn. This is also the most substantive value of permissive licenses like Apache 2.0 and MIT: they have no take-back clause. So "pinning the version" isn't just an ops habit—it really is legally effective.

But we want to be complete. "Whether unilaterally changed clauses have retroactive effect on old versions" is still a debated question in Chinese legal circles. Intellectual property law firm teams have specifically compiled these kinds of disputes (including GPL-related Chinese judicial cases). The statement above is the conventional handling in engineering practice, not a legal conclusion. If you're making real commercial decisions, go by the project's current LICENSE file and consult professional legal counsel.

In operational terms, it comes down to one sentence: remember which version you're using, and record the license name of that version along with it. This is exactly the same habit discussed in 《Where Model Files Actually Come From》—only this time, what you need to record isn't just the filename, but also which contract it came with at the time.

4. Four paths when facing a relicensed project ​

There's one more not in the table, but more important: look at who holds the project. When the trademark and contributor license agreement (CLA) are held by a single company, relicensing only takes one announcement. When governance is handed to a neutral foundation, relicensing has to go through a community process. This difference isn't visible in the thirty seconds of selection, but it will definitely be visible by year three.

How to read the software-side licenses themselves—permissive vs. copyleft camps, the boundary between dynamic and static linking, the difference between AGPL and SSPL in service scenarios—《Open Source Software Licenses Explained》 on this site has already gone through clause by clause. We don't repeat it here. To understand why vendors are willing to give permissive terms in the first place, see 《Why Commercial Companies Open Source》. Both layers together give the complete judgment: motives explain why clauses are written that way; relicensing history tells you clauses get rewritten.

5. Relicensing on the model side is even more frequent ​

If you care about AI, the cases above are just background. License changes for model weights are more common than in the database industry, and harder to predict.

The Qwen family went from research license to Apache 2.0, then to a custom Qwen License for some versions; Qwen-Image's previous generation was Apache 2.0, the new version switched back to research license. Mistral's flagship once used a research license, then in early 2025 announced multiple model weights switching back to Apache 2.0. Llama's community license has adjusted thresholds and attribution obligations generation by generation. The direction isn't consistently tightening or consistently loosening—it swings back and forth with the company's commercial stage.

What these clauses look like specifically is covered clause by clause in 《Why Commercial Companies Open Source》; the license classification of each downloadable model on this site is in 《audio.cpp Model Licenses and Commercial Use》.

One difference we want to point out. Database relicensing affects "whether you continue using this version." Model relicensing affects "whether your last batch of outputs can still be used commercially." The latter is harder to remedy, because the stuff has already been delivered. How to account for the output side layer by layer—derivative weights, sub-components, training data, outputs—is covered in depth in this series' 《After Quantization, LoRA, and Fine-Tuning, Is the Model Still Govern by the Original License?》.

6. Our take ​

First, manage licenses as things with expiry dates. What license a project has right now only tells you its current price. The stable way to record it is to store three things together: version number, license name, acquisition date. The cost is a table. The benefit is that on the day relicensing happens, you can still say clearly which contract your copy came under.

Second, the cost of relicensing is ultimately borne by users and contributors, so it will keep happening. As long as the "managed service captures revenue" structure remains, there will be a next SSPL, a next BSL. Conversely, as long as the cost of forking is low enough to do in three months, vendors won't dare make restrictions too tight. This mutual check is real, and it's more reliable than any promise.

Third, a neutral foundation doesn't make the project stronger, but it makes the rules slower. Almost all the forks that survived this wave are under the Linux Foundation. For users, "whether there's a foundation-governed alternative" isn't a sentiment indicator—it's a very hard bargaining position. It determines whether you have a second path on the day relicensing happens.

If there's one sentence from this series that should be remembered, we think it's this: clauses aren't carved in stone—they're written in contracts. Contracts have versions, and they have expiry dates. So when selecting and installing, besides VRAM and speed, the line worth an extra look is the license name next to the version number. For people doing local deployment, this can be taken one step further: when you install, record "version number + license name" together. Rather than waiting until the day you need to deliver or charge externally, then going back to dig through a repository that has already changed its license.

Disclaimer: This article is our summary of public information and does not constitute legal advice. Relicensing dates, clause content, and distribution handling in the text are public information queried in October 2026 and may change with upstream updates. For any decision involving real commercial interests, consult professional legal counsel and always go by the project's current LICENSE file.