When Open Source Closes the Door

For decades, open source was a straightforward deal. Companies published their code under permissive licences, the community helped improve it, and businesses could build on it freely. That deal is being renegotiated.

In recent years, some of the most widely used infrastructure tools in the world have quietly changed the terms. The code still looks the same. The licence does not.

The tools that changed the rules

The clearest example is HashiCorp. In August 2023, they announced that Terraform, the dominant infrastructure-as-code tool used by hundreds of thousands of organisations worldwide, would move from the Mozilla Public Licence (MPL 2.0) to the Business Source Licence (BSL 1.1). The change meant that anyone using Terraform to offer a competing managed service would need a commercial agreement with HashiCorp.

HashiCorp framed it as protecting their ability to sustain development. Critics called it a bait-and-switch.

They were not the first. Elastic made a similar move in January 2021, switching Elasticsearch and Kibana from Apache 2.0 to the Server Side Public Licence (SSPL) and their own Elastic Licence. MongoDB introduced the SSPL back in 2018. Redis Labs (now Redis Ltd) followed in 2024, moving Redis core from BSD to a dual licence combining SSPL and the Redis Source Available Licence.

The pattern is consistent: a successful open-source project, growing cloud provider adoption, and a company that concludes the current model is not sustainable for them.

What is actually driving this

The honest answer is the hyperscalers. AWS, Azure, and Google Cloud have spent years offering managed versions of popular open-source tools as first-party services. Managed Elasticsearch. Managed Redis. Managed databases built on MongoDB-compatible APIs. All without contributing meaningfully back to the projects that made those services possible.

From the perspective of the companies that built these tools, that felt like having your work taken and turned into someone else's profit. HashiCorp, Redis Ltd, Elastic, and MongoDB each found themselves in the same position: they wrote the code, they built the community, and cloud providers monetised it at scale while contributing little in return.

The BSL and SSPL were designed to close that specific loophole. Use the software however you like, except to compete with us directly as a managed service provider.

That is a narrower restriction than it might first appear. For most businesses using Terraform to manage their own infrastructure, or running Redis as a cache in their application, the licence change changes nothing practical. The problem is the precedent it sets, and the trust it breaks.

The trust problem

Open source is not just a licensing model. It is a social contract. When a company publishes code under a permissive licence, they are making a commitment to the ecosystem: build on this, and we will not pull the rug.

Relicensing breaks that contract retrospectively. Businesses that chose Terraform precisely because it was open source, built workflows around it, trained teams on it, and integrated it deeply into their infrastructure, find themselves in a different position than they thought they were in.

The code they already have does not change. But the future trajectory of the tool, the community, and the ecosystem is now shaped by a company with different incentives. And that matters more than any single licence clause.

Community forks: the ecosystem fights back

The most interesting response to HashiCorp's move was OpenTofu. Within weeks of the Terraform relicensing announcement, a coalition of companies including Gruntwork, Spacelift, and others launched an open-source fork under the Linux Foundation, preserving the MPL licence. OpenTofu reached general availability as v1.6 in January 2024 and has continued active development since.

Redis saw the same thing. When Redis changed its licence in 2024, the Linux Foundation launched Valkey, a community-maintained fork of Redis. Valkey attracted major contributors quickly, including Google and AWS, both of which had strong reasons to want a genuinely open alternative to a tool they had built services on top of. Redis itself subsequently relicensed Redis 8 under AGPLv3 in May 2025, returning to an OSI-approved open-source licence.

Elastic is a slightly different story. Having moved to a more restrictive licence in 2021 (which prompted AWS to fork Elasticsearch into OpenSearch), Elastic reversed course in September 2024 and added the AGPL as a licence option alongside their own, effectively returning to an open-source model. Whether that reflects genuine change or a response to commercial pressure is a matter of interpretation.

MongoDB remains under SSPL, and no significant fork has emerged to challenge it. The community there appears to have accepted the new terms, or moved to alternatives like PostgreSQL for document-style workloads.

A short history of open-source licensing (optional, click to expand)

Open-source licensing has never been a single thing. The Free Software Foundation introduced the GNU General Public Licence (GPL) in 1989 with a specific philosophy: software freedom means any derivative work must also be free. That "copyleft" requirement was deliberate. The goal was to prevent companies from taking open-source code, improving it, and distributing the improvements under proprietary terms.

The Apache Licence and MIT Licence emerged as more permissive alternatives, dropping the copyleft requirement. This allowed companies to use open-source components in proprietary products without any obligation to publish their own code. A large proportion of the components that power the modern internet are under these licences.

The SSPL, introduced by MongoDB in 2018, sits in unusual territory. It is more aggressive than the GPL in some respects: if you offer the software as a service, you must open-source not just the software itself but the entire infrastructure stack used to run it. The Open Source Initiative declined to certify it as an open-source licence, which is why you will see these tools described as "source available" rather than open source.

The BSL takes a different approach. Code is source-available and free for most uses, but converts to a true open-source licence after a fixed period (typically four years). It allows the originating company to control commercial exploitation in the short term while guaranteeing eventual openness. It was originally designed by MariaDB and has been used by a small number of projects before HashiCorp adopted it for Terraform.

Neither SSPL nor BSL is a bad licence in isolation. The friction comes from applying them to projects that were previously under genuinely open licences, with communities built on the assumption that those terms would not change.

What this means for businesses that depend on these tools

If your organisation runs Terraform, Redis, Elasticsearch, or MongoDB in production, the immediate practical impact is probably small. Existing code does not disappear. Existing functionality does not change. The licence restrictions are targeted at managed service providers, not end users.

The medium-term risk is more subtle. It shows up in three places.

Community fragmentation. When a project forks, effort splits. OpenTofu and Terraform are diverging. Valkey and Redis are diverging. For a few years, the ecosystem will have to maintain familiarity with both, decide which to adopt for new work, and watch carefully which one attracts the most development momentum. That is overhead that did not exist before.

Vendor dependency creep. If your stack relies heavily on tools from a single vendor ecosystem, relicensing events expose how much leverage that vendor actually has. The risk is not legal, usually. It is strategic: your roadmap is now partially determined by someone else's commercial decisions.

Procurement and compliance friction. Legal and procurement teams at larger organisations may need to review whether tools under BSL or SSPL are acceptable under internal policy or client contracts. That is not a blocker, but it is a conversation that did not need to happen when the tool was Apache 2.0.

What it signals about trust and control

The relicensing wave is not a conspiracy. These companies faced a genuine problem: they built something valuable, the ecosystem benefited enormously, and the economic return did not flow back to them in proportion to their contribution. That is a real tension, and the BSL and SSPL are attempts to resolve it.

But the resolution comes at a cost. Every relicensing event teaches the ecosystem a lesson: open-source commitments from commercial companies are contingent. They hold until the business model requires otherwise.

The companies that forked, OpenTofu under the Linux Foundation, Valkey under a neutral governance structure, are making a different bet. Foundation-backed projects are harder to relicence unilaterally. The governance is distributed. No single commercial interest controls the roadmap.

That is increasingly attractive to organisations that need predictability. It is also why you will see more infrastructure projects incubating under the CNCF, Apache Foundation, or Linux Foundation rather than under commercial stewardship from the start.

The lesson is not "avoid commercial open source." It is: understand who controls the tools you depend on, and what their incentives are. That has always been good practice. It is just more visible now.

How AI with Ash can support you

If your team is navigating decisions around tooling, vendor dependency, or how to build internal systems on foundations that will not shift under you, that is worth thinking through carefully. The technical choices and the strategic ones are connected, and they are easier to untangle before you are deep into a migration.

Book a call and let's take a look at where your stack actually stands.