Beyond the source code: your infrastructure vendor changed its licence, and your legal team probably does not know
Between 2018 and 2024, a series of infrastructure software vendors abandoned open-source licensing for restrictive alternatives. Some are now reversing course. The commercial risks for companies that build on these products have not reversed with them.
Most companies assume their infrastructure software licences are stable. They treat the licence under which a product was adopted as a fixed attribute, like the product’s programming language or its documentation format: something that was true when the product was selected and will remain true for the foreseeable future.
That assumption held for decades. It no longer does.
Between 2018 and 2024, some of the most widely adopted database, caching, search, and infrastructure management tools in the world changed their licensing terms. MongoDB moved first, then Elastic followed. HashiCorp, the company behind Terraform, did the same. Redis, arguably the most ubiquitous caching layer in modern web infrastructure, completed the pattern. CockroachDB, TimescaleDB, and Confluent joined them.
Each of these products had been released under licences approved by the Open Source Initiative: the internationally recognised standard for what qualifies as open-source software. Each of them switched to licences the OSI does not recognise as open source, licences the industry calls “source-available”: the source code remains visible and accessible, but specific commercial uses are now restricted. The distinction matters far beyond nomenclature. It determines whether the software can ship in major Linux distributions, whether enterprise procurement can approve it without a special legal review, and whether a company building on top of it can freely offer its own product as a service.
Some vendors have since partially reversed course. Elastic added an open-source licence option in late 2024. Redis did the same in May 2025, its CEO publicly admitting that the restrictive licensing had damaged the company’s relationship with its community. But the reversals are partial, the compliance landscape is more complex than before, and the structural pressure that drove the original changes remains unresolved.
This article examines what happened, why it happened, and what it means for companies that build commercial products on infrastructure software they do not control.
I. The business model that broke, and the licensing shift it triggered
Open-source infrastructure software was never free to build. It was only free to use. That distinction held for over a decade. Then the cloud providers arrived, and the economics collapsed.
Companies like MongoDB, Redis, Elastic, and HashiCorp invested hundreds of millions in building infrastructure software and released it under open-source licences. To understand why the licensing change matters, one must first understand what “open source” means in operational terms: any licence on the OSI’s approved list grants users the freedom to use, study, modify, and redistribute the software for any purpose, including commercial use, without requiring permission from or payment to the original developer. But OSI approval is not merely philosophical. Major Linux distributions: Debian, Fedora, Red Hat Enterprise Linux, Ubuntu: include only OSI-approved software in their official repositories. Most enterprise procurement teams maintain lists of approved licences that map closely to the OSI list. A product with an OSI-approved licence enters an organisation through the front door. A product without one triggers an individual legal review every time someone wants to use it. That friction shapes adoption at scale.
The business model these companies built on top of their open-source software was elegant in its simplicity: give the software away, then sell services around it. Enterprise support, managed hosting, security features and consulting. The model worked beautifully, as long as one assumption held: that the vendor would remain the primary provider of those paid services.
Nobody anticipated what happened next. Amazon Web Services launched “Amazon DocumentDB” (a MongoDB-compatible managed database), “Amazon ElastiCache for Redis” (managed caching), and “Amazon Elasticsearch Service” (managed search). Google Cloud and Microsoft Azure followed with their own managed offerings. The cloud providers took the freely available open-source software, wrapped it in a managed service, and sold it to customers at enormous scale: capturing precisely the managed-service revenue that the original vendors had built their businesses around. The open-source licences permitted this entirely. They had been written for a world where software shipped as packages that users installed on their own machines. The cloud changed the delivery model. The licences had not adapted. The vendors watched big companies monetise their work while contributing little or nothing back, and the licences they had chosen gave them no legal recourse.
The response was predictable: change the licences. Each vendor chose a slightly different mechanism, but the commercial logic was identical: restrict the one use case that was destroying them. What each licence restricts:
· MongoDB: Server Side Public License (SSPL, 2018). A company that offers MongoDB’s functionality to third parties as a service must release the source code of the entire service stack under the SSPL: not just the database, but all management software, user interfaces, APIs, automation, monitoring, backup, storage, and hosting software. The requirement is so sweeping that compliance is practically impossible for any company running proprietary infrastructure. The real choice is binary: stop offering the service, or pay MongoDB for a commercial licence.
· Elastic: Elastic License 2.0 and SSPL (2021). The Elastic License prohibits providing the software to third parties as a managed service and prohibits circumventing licence key functionality. AWS did not comply. It forked Elasticsearch into OpenSearch under the Linux Foundation and walked away.
HashiCorp: Business Source License (BUSL 1.1, 2023). The BUSL prohibits using the software to create a “competitive offering” to HashiCorp’s own commercial products. Internal use remains unrestricted. Each release automatically converts to the permissive MPL 2.0 four years after publication, but HashiCorp continues publishing new releases under BUSL, so the latest version is always restricted. IBM acquired HashiCorp for $6.4 billion in August 2024. The BUSL remains firmly in place.
· Redis: Redis Source Available License v2 (RSALv2) and SSPL (2024). RSALv2 prohibits commercialising the software or providing it to third parties as a managed service. The community’s response was immediate: the Linux Foundation announced the Valkey fork within weeks, backed by AWS, Google, Oracle, Snap, and Ericsson.
· CockroachDB, TimescaleDB, Confluent made similar moves, each crafting terms that restrict the offering of their software as a competing managed service.
None of these new licences is recognised as open source by the OSI. The OSI has explicitly stated that the SSPL does not meet the Open Source Definition because it discriminates against specific fields of use, which the Definition prohibits. The practical fallout was swift: Debian and Fedora dropped MongoDB from their repositories after the SSPL change. The same happened with Redis. For products whose growth depended on frictionless distribution, this was not an inconvenience, it was a measurable wound to market reach.
II. Elastic and Redis reversed course. The compliance picture got worse, not better.
In late 2024, Elastic added the GNU Affero General Public License v3 (AGPLv3) as a third licence option alongside its Elastic License and SSPL. In May 2025, Redis did the same, adding AGPLv3 alongside RSALv2 and SSPL for Redis 8.
Translation: the OSI did not blink. The community did not comply. The vendors blinked first.
The reversals happened because the source-available licences caused commercial damage that exceeded the protection they offered. Distribution through major Linux repositories were lost. Enterprise adoption at organisations requiring OSI-approved licence were blocked. And most painfully, well-funded competitor forks emerged that attracted the very communities the vendors had alienated. Valkey for Redis, backed by AWS and Google. OpenSearch for Elastic. OpenTofu for Terraform, under the Linux Foundation. A 2024 survey found that 83% of large companies using Redis had already adopted or were testing Valkey within a year of the licence change (InfoQ, May 2025). The community did not respond to the relicensing with compliance. It responded by leaving.
Here is what most commentary about these reversals misses. The reversals are additive, not substitutive. Elastic and Redis did not remove the source-available licences. They offered AGPLv3 on as a third option. A company integrating Redis 8 is not selecting a product. It is selecting a licence regime. Three options, three sets of obligations, three different sets of consequences for getting it wrong. The compliance landscape has not simplified. It has tripled.
MongoDB has not reversed at all. It remains under SSPL with no OSI-approved alternative, and appears to regard the strategy as a success: cloud providers either pay for a commercial licence or build their own compatible alternatives (AWS DocumentDB, FerretDB), but they do not offer MongoDB itself as a competing managed service. The community cost was a price MongoDB decided it could afford.
III. Where the licensing shift becomes a business problem
The relicensing wave created categories of commercial risk that persist regardless of whether individual vendors reverse course. Most of these risks share a characteristic: they are invisible until they surface in exactly the context where discovering them is most expensive.
A. Upgrade and accept, or stay behind and lose support
When a vendor relicenses, every user faces a forced choice with no comfortable option. Upgrade to the new version under the new licence, accepting whatever restrictions it imposes. Or remain on the last version under the old licence and forgo security updates, bug fixes, and new features indefinitely. Redis users who stayed on version 7.2 to preserve their BSD licence lost all subsequent security patches. Terraform users who remained on version 1.5.7, the final MPL 2.0 release, lost access to every improvement developed since August 2023. In both cases, the company is running an increasingly outdated and potentially vulnerable version of a critical infrastructure component: not because the software failed, but because the licence changed.
The alternative is migrating to a community fork, and here the recent history offers both encouragement and caution. Terraform’s relicensing produced OpenTofu, accepted by the Linux Foundation within weeks, with a stable release by January 2024. Redis’s relicensing produced Valkey, backed by some of the largest technology companies in the world. These forks are real, viable, and actively maintained. But “the fork exists” is not the same as having completed a full migration. Migrating requires testing against the company’s existing infrastructure, validating compatibility with every dependent tool, retraining engineering teams, updating deployment pipelines, and communicating the change to customers whose contracts may reference the original product by name. A company whose SLA commitments are built around “Redis” cannot silently substitute Valkey without verifying that its contractual language permits it. The fork solves the licensing problem. It does not solve the migration problem. And every month the company spends deliberating is a month running on an unsupported version.
B. When upstream licence changes break downstream warranties
Software licence agreements routinely include representations from the licensor: that it owns or has the right to licence the intellectual property being conveyed, and that the software does not infringe third-party IP rights. They are the legal foundation on which the customer builds its own product, makes its own representations to its own customers, and assumes its own contractual obligations downstream.
When an upstream dependency quietly changes its licence, this entire chain of representations can become inaccurate without a single person noticing. Consider the scenario concretely: a company warranted to its customer that its product contains only software under OSI-approved licences. The engineering team, as part of routine dependency maintenance, upgrades MongoDB to a version now governed by SSPL. Nobody checks the licence because nobody has ever had to: MongoDB was always open source. The legal team is not informed. The customer discovers the discrepancy six months later during a due diligence exercise. The company is in breach of its own warranty: not through malice, not through negligence in the traditional sense, but through the absence of a process that most organisations have never built.
The scale of this exposure is now empirically documented. The 2026 Black Duck Open Source Security and Risk Analysis report analysed 947 commercial codebases and found that two-thirds had licence conflicts: the highest percentage ever recorded, a 12% increase from the prior year. One audited codebase contained 2,675 distinct licensing conflicts. In M&A transactions, where the acquiring entity relies on IP due diligence to value the target’s software assets, undiscovered upstream licence changes can materially affect the valuation, delay closing, or trigger indemnification claims. The licence conflict is not the kind of problem that announces itself. It surfaces at precisely the moment when the cost of discovering it is highest.
C. When the enforcer has a sales team
This is the dimension that connects most directly to the analysis in the first article in this series, which examined the compounding risks of GPL non-compliance. The enforcement dynamics for source-available licences differ from traditional copyleft in a way that sharpens the risk rather than softening it.
When the enforcer of a GPL licence is an individual developer or a community organisation such as the Software Freedom Conservancy, enforcement is constrained by resources, by appetite for litigation, and by the reputational cost of being seen as aggressive. When the enforcer is MongoDB Inc., Elastic (a public company answerable to shareholders), or HashiCorp (now a subsidiary of IBM), the calculus is entirely different. These are well-funded commercial entities with dedicated legal departments and a direct, quantifiable financial incentive to enforce: every company that uses the software under the source-available licence instead of purchasing a commercial licence is lost revenue. Not theoretical lost revenue. Revenue that a sales team is specifically tasked with recovering.
The dual-licence model makes this explicit. The source-available licence governs free use but imposes conditions so onerous that most commercial users cannot comply. The commercial licence offers normal terms for a fee. The model is designed so that the source-available licence is not a genuine compliance path. It is a pressure mechanism. Enforcement is not a community governance exercise. It is a revenue protection strategy.
D. Licences that procurement has never seen before
Companies with mature procurement processes have spent years building approved licence lists and approval workflows calibrated to OSI-approved licences. SSPL, BUSL, Elastic License, RSALv2: none of these existed before 2018, and none has been incorporated into most organisations’ procurement policies. Every adoption of a product under one of these licences forces an ad hoc legal review that the procurement process was not designed to accommodate: what does the licence restrict, does the company’s intended use fall within the permitted scope, and what happens if that use case evolves. For products that previously required no legal review at all, this is a material change in the cost of adoption: not dramatic enough to make headlines, but persistent enough to slow down engineering teams, delay deployments, and create a category of licensing risk that nobody in the organisation is specifically trained to evaluate.
IV. Is the shift over?
The first-generation relicensing wave is largely complete. The most prominent infrastructure vendors that faced the cloud-provider monetisation problem have already moved. The ones that were going to switch have switched.
But “largely complete” is not the same as “resolved.” The structural conditions that produced the wave remain in place. Cloud providers continue to monetise open-source infrastructure as managed services. The tension between open-source development and commercial sustainability has not found a stable equilibrium. And two developments suggest that companies treating the relicensing wave as a closed chapter are making a mistake.
The first is that the reversals themselves prove the instability. Elastic’s and Redis’s partial return to open source did not settle their licensing: it added a third option on top of two existing ones. The licensing trajectory for these products is not converging on a stable state. It is oscillating. A company building on Redis today is building on a product that has changed its licence twice in two years and may change it again when commercial pressures shift. Licence stability, for this category of product, is no longer a reasonable assumption.
The second is that AI-assisted software development is about to amplify the structural tension that caused the wave in the first place. The tools now emerging: Claude Code, OpenAI’s coding agents, platforms like Lovable, Bolt, and Replit: enable people who have never configured a database or examined a licence to build and ship commercial applications. These new developers will not deploy their own infrastructure. They will consume it through managed cloud services: clicking a button that provisions a database, a cache, a search engine, without knowing or caring what software sits beneath the interface. This means more applications being built, which means more demand for managed infrastructure, which means more revenue flowing to the cloud providers who offer those managed services. The structural tension between open-source vendors and cloud providers does not diminish as AI lowers the barrier to software development. It intensifies. The next wave of relicensing pressure may not come from the same vendors: it may come from the next generation of open-source infrastructure projects that discover, as their predecessors did, that their licences do not protect them from the cloud.
The question for companies, then, is not whether the relicensing wave is over. It is whether they would know what to do if a critical dependency changed its licence tomorrow. Companies that cannot answer that question quickly and concretely are carrying a risk they have not priced.
V. The discipline that exists for security but not for licensing
The relicensing wave exposed a specific organisational failure: the gap between how companies manage security risk in their software dependencies and how they manage licensing risk in those same dependencies.
Most mature organisations already track security vulnerabilities in their dependency stack. They monitor CVE databases (standardised catalogues of known software vulnerabilities, maintained by institutions like MITRE and NIST), run automated scans, and patch or mitigate when a vulnerability is disclosed. The discipline exists because the consequences of ignoring it are immediate, visible, and painful: a breach, an exploit, a regulatory penalty. Nobody debates whether security monitoring is necessary.
No equivalent discipline exists for licence changes. When an upstream vendor relicenses, the change is rarely detected by automated tools and is almost never flagged to the legal team. Engineering teams upgrade dependencies as part of routine maintenance without checking whether the licence has changed, because it has never occurred to them that a licence could change. The exposure accumulates silently, invisibly, until it surfaces during a due diligence exercise, a customer audit, or an enforcement action: precisely the moments where the cost of discovering a licensing problem is highest and the time available to resolve it is shortest.
What the relicensing wave demonstrated is that licence stability cannot be assumed for infrastructure products maintained by commercial vendors. Not because these vendors are acting in bad faith, but because their business models are under structural pressure that their original licences were not designed to absorb. The consequences of this insight are operational:
· Track upstream licence changes in critical dependencies with the same rigour applied to security vulnerabilities. The cost of discovering a licence conflict during a transaction or an audit is orders of magnitude higher than the cost of catching it early.
· Assess architectural coupling to any single vendor’s product. The cost of migrating away from a relicensed dependency is directly proportional to how deeply it is integrated. A company that can swap its caching layer in a week is in a fundamentally different position from one that needs six months.
· Review customer-facing agreements to ensure that representations about IP ownership and licensing compliance account for the possibility that upstream terms may change. A warranty drafted on the assumption that licence terms are permanent is a warranty waiting to be breached.
· Ensure that procurement and legal teams understand the distinction between open-source and source-available, and that internal approval processes reflect that distinction before the next adoption decision lands on someone’s desk. The time to build the process is not when the product has already been deployed.
The companies that emerge from this period with the least disruption will not be the ones that predicted which vendor would relicense next. They will be the ones that built their dependency management and their contractual architecture to absorb the change: not because they saw it coming, but because they understood that in this market, change is the only constant that can be relied upon.
