The Relicensing Wave
Open source enterprise adoption has never been higher, yet the commercial ground beneath it keeps shifting. A clear pattern has run from MongoDB in 2018, through Elastic in 2021 and HashiCorp in 2023, to Redis in 2024: a successful single-vendor open source project, facing cloud-provider competition and venture-capital pressure, abandons a permissive licence for a restrictive “source-available” one. The trigger is almost always the same — cloud providers monetising the software without contributing back. In Redis’s case, only about 1% of users became paying Redis Enterprise customers before the company moved from BSD to SSPL and RSALv2 in March 2024.
The motive is rational, but the effect on buyers is a sudden change in the terms under which they can run software they had treated as free and open. That is why licence trajectory now belongs in market intelligence, as we set out in the market intelligence pillar — a relicensing event can reprice an entire piece of your stack overnight.
The common ingredients are worth naming, because they let you predict the next candidate. Each relicensed project shared three traits: a single commercial vendor controlling the roadmap, a large cloud provider reselling the software as a managed service, and venture or public-market pressure to convert adoption into revenue. Any open source dependency in your estate that fits that profile — heavy single-vendor control, an obvious hyperscaler managed-service version, and investors expecting a return — should be treated as a relicensing risk, not a permanent free good. Mapping your dependencies against those three traits is a five-minute exercise that can save a seven-figure surprise.
Forks Reset the Leverage
The decisive development is that the community now responds to relicensing within weeks, and those forks restore buyer leverage. When Redis relicensed, the Linux Foundation launched Valkey within 30 days; it drew nearly 50 contributing companies inside a year and now reports 83% enterprise adoption alongside nearly double Redis’s pull-request rate. Redis reversed course to AGPLv3 in May 2025 — but by then Valkey had already won the installed base.
| Project | Relicensing | Open fork | Buyer outcome |
|---|---|---|---|
| Redis (2024) | BSD → SSPL/RSALv2 | Valkey (Linux Foundation) | 83% enterprise adoption; ~20% cost saving |
| HashiCorp Terraform (2023) | MPL → BSL 1.1 | OpenTofu | ~50% of deployments now on the fork |
| Elasticsearch (2021) | Apache → SSPL | OpenSearch | AGPL reversal; AWS conflict resolved |
| MongoDB (2018) | AGPL → SSPL | (set the pattern) | Established cloud-competition playbook |
The financial impact is measurable. Aiven passed roughly 20% cost savings to customers migrating to Valkey instances, and OpenTofu — the Linux Foundation fork of Terraform — now accounts for around half of deployments, with Fidelity Investments alone migrating 50,000 state files across more than 2,000 applications and 4 million managed resources. Notably, IBM’s $6.4 billion acquisition of HashiCorp in February 2025 did not reverse the BSL, a reminder that IT vendor M&A rarely softens licence terms.
The Commercial Impact for Buyers
For enterprises, the open core battle creates both risk and opportunity. The risk is dependency on a single-vendor project that may relicense without warning, converting a free dependency into a paid one or a compliance exposure. The opportunity is that mature, Linux Foundation-governed forks now offer a genuine, well-supported escape route — and that escape route is itself negotiation leverage against the commercial vendor.
This connects directly to infrastructure strategy. Portable, open foundations are far easier to move than proprietary managed services, which is why open source adoption and the cloud repatriation trend reinforce each other. The same logic applies to AI: as the GenAI market consolidates, open-weight models are emerging as the buyer’s hedge against proprietary lock-in, and the wider enterprise software market trends point the same way.
There is also a governance and compliance dimension that procurement cannot ignore. A source-available licence such as the SSPL or BSL is not an open source licence in the OSI sense, and using it as though it were can create real exposure — restrictions on offering the software as a service, on competitive use, or on modification can all surface in an audit. When a project relicenses, every downstream use needs re-examining against the new terms, because the freedoms you relied on yesterday may no longer exist. Treating a relicensing event as a compliance trigger, not just a pricing one, avoids the trap of an unintended breach.
The pattern is now predictable enough to plan around: a successful single-vendor project relicenses, a Linux Foundation fork appears within weeks, and within a year the fork has captured much of the installed base. Buyers who recognise the cycle early can position for it deliberately rather than scramble when it arrives mid-contract.
Forks are not free either
The migration path is real but not costless. Moving to a fork means validating compatibility, retraining teams, and accepting that the fork’s roadmap may diverge from the original over time. Fidelity’s migration of 50,000 Terraform state files across 2,000 applications was a significant programme, not a flip of a switch. The point for negotiation is that the fork sets a credible ceiling on what the commercial vendor can charge: as long as migration costs less than the enterprise-tier premium over the contract term, the vendor cannot price above that line without losing you.
Negotiating With Open Core
Open core vendors — companies offering a free community edition alongside a paid enterprise tier — depend on the gap between the two being wide enough to justify the upgrade. Your leverage is to keep the community edition and the open fork as live, credible options. Before signing an enterprise agreement, confirm exactly which features sit behind the paywall, whether a Linux Foundation fork covers your requirements, and what a migration would actually cost. A documented fork-migration plan compresses enterprise-tier pricing the same way a competitive bid does.
Procurement should treat licence terms as a living risk, not a one-time check. Build a register of your open source dependencies that records the current licence, the governing entity, and whether a Linux Foundation fork exists — and revisit it at least annually. When a project changes hands or takes investment, move it up the watch list. The cost of maintaining the register is trivial next to the cost of discovering, mid-audit, that a core dependency relicensed two years ago and your usage is now out of compliance.
The same logic strengthens commercial agreements with open core vendors. A vendor confident in its value will grant continuity and price-protection terms; one planning to tighten the screws will resist — and that resistance is itself useful intelligence about where the relationship is heading.
There is a strategic upside buyers often miss. Standardising on a Linux Foundation fork — or contributing engineering effort to it — strengthens the very alternative that disciplines the commercial vendor, at a fraction of the enterprise-licence cost. The roughly 50 companies backing Valkey within a year did not just hedge their own risk; they built a credible, governed substitute that every Redis customer can now point to in a negotiation. Open source leverage compounds when buyers act collectively.
Protect against relicensing explicitly: negotiate licence-continuity and price-protection clauses, and avoid building critical workloads on proprietary extensions that have no open equivalent. For a structured approach to managing open core and multi-vendor risk together, our multi-vendor strategy white paper lays out the framework, or request a confidential briefing on a specific open core renewal.