A License Change Costs You a Migration. Taking the License Back Does Not Refund It.

Why a license change is not a legal topic

In most companies, license review sits at the end of the chain. A scanner runs in the build, produces a component list, someone checks whether anything with copyleft obligations slipped into the shipped product, and the topic is considered closed. That review answers exactly one question: am I allowed to ship this today.

It does not answer the question that gets expensive. That one reads: who can unilaterally change the terms of this component, and what does that change cost me when it comes.

On 10 August 2023, HashiCorp answered that second question for an entire class of tooling. The company announced that all future releases of its core products would move from MPL 2.0 to the Business Source License 1.1: Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer and Vagrant. APIs, SDKs and nearly all remaining libraries stayed under MPL 2.0.

What matters is what did not happen. The change was not retroactive. The license file in the Terraform repository names Terraform from version 1.6.0 onward as the licensed work. Everything up to and including 1.5.x remains MPL 2.0. Anyone who did nothing in August 2023 had no acute problem. They had a date after which every update was one.

And that same file says something else today: the licensor is International Business Machines Corporation, with a 2024 copyright notice for IBM Corp. IBM completed the acquisition of HashiCorp on 27 February 2025 at an enterprise value of $6.4 billion and $35 per share in cash. So the party deciding the terms of use for your infrastructure tooling changed owner once more after the relicensing.

The Ownership Chain

Two events affecting the same component sit between the announcement and today: the relicensing on 10 August 2023 and the change of ownership on 27 February 2025. Whoever assessed in 2023 who they were trusting ended up in 2025 with a different counterparty, without a single thing changing in their build. License risk is therefore not a one-time checkpoint. It is an ongoing watch.

What BSL, SSPL and the Elastic License actually govern

The three licenses displacing MIT and Apache in the infrastructure layer work differently, and the differences matter for risk assessment.

BSL 1.1 is explicitly not an open source license. But it carries a built-in expiry mechanism: every version converts to an open license on the stated change date, or at the latest on the fourth anniversary of that version’s first public distribution, whichever comes first. The license text mandates GPL 2.0 or a GPL-compatible license as the change license. The frequently quoted four years are therefore not vendor goodwill but the contractual ceiling. For Terraform, the change date is the four-year term from publication, and the change license is MPL 2.0.

The SSPL has no such mechanism. The Open Source Initiative stated on 19 January 2021 that the SSPL is not an open source license. It was withdrawn from the approval process by the licensor once it became clear it would not be approved. The OSI describes such licenses as “fauxpen source”.

Elastic License 2.0 is the third variant here, and for users the widest-reaching one: the Elasticsearch distributions available by default for download still ship under it.

Where the risk threshold for users actually runs

The most important passage in practice is not in the license text but in the accompanying FAQ. Redis defines the triggering condition as a commercial competing offering: a product sold to third parties, derived from the code base, that substantially overlaps with a commercial product of the vendor. Providing the software as a service internally within your own organization, including subsidiaries, remains explicitly permitted.

That is the real risk threshold, and it cuts straight through most companies. For internal operation, such a license changes little. For every product you sell to customers that embeds the component, it changes everything. And in many architectures that boundary is invisible, because the same component runs on both sides of it.

Why freezing the old version has an expiry date

The obvious answer to a relicensing is to stay on the last openly licensed version. That works, but only for a while. Redis committed to security backports on the BSD-licensed legacy versions explicitly only until the release of Redis Community Edition 9.0. Patches after that ship under the new dual license.

That names the mechanism which erodes every freeze strategy: it is not the license that forces the move, it is the first vulnerability with no patch left under the old license.

Three relicensings, four forks

Project	Before	After	Date	Fork	Foundation home	Later reopening
Elasticsearch	Apache 2.0	SSPL + Elastic License	14 Jan 2021	OpenSearch	OpenSearch Software Foundation (LF) since 16 Sep 2024	AGPL as third option, 29 Aug 2024
Terraform	MPL 2.0	BSL 1.1	10 Aug 2023	OpenTofu	Linux Foundation since 20 Sep 2023, CNCF Sandbox since 23 Apr 2025	none
Vault	MPL 2.0	BSL 1.1	10 Aug 2023	OpenBao	OpenSSF Sandbox since 17 Jun 2025	none
Redis	BSD 3-Clause	RSALv2 + SSPLv1	20 Mar 2024	Valkey	Linux Foundation since 28 Mar 2024	AGPLv3 as option, 1 May 2025

The pattern is identical in all four rows: the relicensing is followed within weeks by a fork of the last openly licensed version, and that fork immediately looks for a foundation home. Valkey was announced on 28 March 2024, eight days after the Redis announcement, under BSD 3-Clause, built on Redis 7.2.4, with AWS, Google Cloud, Oracle, Ericsson and Snap Inc. as supporters.

Why the later reopening does not bring the migration back

Two of the three vendors later partially corrected their decision. That is the most interesting part of the story, because it shows how asymmetric these costs are.

Elastic added the AGPL as a third license option alongside ELv2 and SSPL on 29 August 2024. The post does not name OpenSearch, referring instead to a fork “with a different name and a different trajectory”. And the reopening is narrower than the headline suggests: according to Elastic’s own licensing FAQ, the AGPL applies to the source code from version 8.16 onward, while the distributions available by default for download remain under Elastic License 2.0. The return concerns the source option, not the shipped default artifact.

The effect on the fork was the opposite of a return migration. In the OpenSearch Software Foundation’s first year, which covers the AGPL announcement, OpenSearch downloads rose 78 percent year over year to more than 1 billion, with over 8,800 contributions from more than 400 active organizations, 16 member organizations and a 15-person technical steering committee. Five years after the fork, the project passed 2 billion downloads in 2026; a Linux Foundation Research study reports 77 percent of respondents seeing OpenSearch as an important core or supporting component for AI applications.

Redis followed the same shape. On 1 May 2025, AGPLv3 was added as an additional option, starting with Redis 8. RSALv2 and SSPLv1 remained in place, so the AGPL is an option, not a replacement. Valkey kept developing independently afterwards: version 9.0 became generally available on 21 October 2025 under Linux Foundation governance, with up to 40 percent higher throughput than 8.1, support for up to 2,000 nodes and more than 1 billion requests per second.

On top of that sits a layer entirely outside any vendor’s control. Fedora replaced Redis with Valkey system-wide from Fedora Linux 41, explicitly because of the SSPL, which the distribution’s licensing policy does not allow. Existing installations were migrated automatically on upgrade through a compatibility package. Once a distribution has flipped the default, your architecture team no longer decides what lands on a freshly provisioned host.

And finally the fork acquired a price. AWS prices ElastiCache for Valkey 33 percent lower in serverless mode and 20 percent lower for node-based clusters than the other supported engines, with a 90 percent lower minimum data volume and entry at around $6 per month. That turns the migration into a cost argument for procurement, not just a licensing one. A return migration would have to argue against both.

This is not a clean negative proof. Nobody can demonstrate that not a single user switched back. What can be demonstrated are the indicators, and they all point the same way: independent fork releases after the reopening, unchanged distribution defaults, growing download numbers, a structural price advantage. For a risk assessment that is enough. The point is not that a return is impossible. The point is that it costs a second migration budget that nobody signs off.

Why foundation governance is a hard selection criterion

Put the four rows of the table side by side and the real difference is not the license but the structure that decides it. A corporation holding full rights can relicense whenever it wants. A foundation with a membership structure practically cannot, because the same decision there requires consensus among competing companies.

That is exactly why the forks went to foundations rather than to community repositories. OpenTofu was accepted as a Linux Foundation project on 20 September 2023 under MPL 2.0, with support pledges from more than 140 organizations and over 600 individuals, plus at least 18 full-time engineers for at least five years. On 23 April 2025 it was additionally accepted as a CNCF project at sandbox level. The OpenSearch Software Foundation was established under the Linux Foundation on 16 September 2024 when AWS transferred the project; the announcement cited more than 700 million downloads and over 200 project maintainers, with AWS, SAP, Uber, Aiven, Atlassian, Canonical, DigitalOcean and NetApp Instaclustr among the founding members. OpenBao, the fork of Vault, was originally developed under LF Edge and has been a sandbox project of the OpenSSF since 17 June 2025, used among other things as the secret store of EdgeX Foundry.

That this structure is more than a gesture became clear in the conflict that followed. HashiCorp served OpenTofu with a cease and desist on 3 April 2024 over an alleged appropriation of BSL-licensed code. OpenTofu rejected the claims publicly and in full on 11 April 2024, a sequence also documented in the trade press. A fork without institutional backing would have had to answer that letter with the resources of a side project.

Since the end of 2024, this criterion also has a regulatory anchor. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024; notification of conformity assessment bodies applies from 11 June 2026, the reporting obligations under Article 14 from 11 September 2026 and the main obligations from 11 December 2027. Article 24 creates the new category of the open-source software steward: legal entities that provide sustained and systematic support for the development of free and open source software intended for commercial purposes. Stewards must maintain a cybersecurity policy, handle vulnerabilities and report actively exploited ones, but are not subject to fines. That makes foundation homes a nameable role in your supply chain, not only a governance preference.

How to assess this in the critical path

The assessment does not belong in a compliance document. It belongs in the same list as your vendor risks. In practice that means a short set of components that build, deploy or run production, and for each of them a statement about who can change the terms.

# dependency-policy.yml
# What matters is not today's license but who can change it tomorrow.

critical_path:
  # Anything that builds, deploys or runs production
  - terraform
  - vault
  - redis
  - elasticsearch

license_class:
  open:             [MPL-2.0, Apache-2.0, BSD-3-Clause, MIT, AGPL-3.0]
  source_available: [BUSL-1.1, SSPL-1.0, Elastic-2.0, RSAL-2.0, FSL-1.1-Apache-2.0]

governance:
  single_owner: review_required   # One owner, one decision
  foundation:   allow             # Linux Foundation, CNCF, OpenSSF

require_for_critical_path:
  exit_path_documented:    true   # Compatible replacement named and tested
  license_file_watched:    true   # Diff on the upstream LICENSE
  upstream_owner_recorded: true   # Legal entity, not brand name
  resale_exposure_flagged: true   # Does the component ship in a product you sell

The third line in the lower block is the one that most rarely exists. The legal entity changes in an acquisition, the brand name does not. If your component inventory says HashiCorp, it documents the state of 2024.

The only reliable early indicator is the license file itself. It changes in the repository before any press release appears, and it can be watched continuously:

# Runs nightly, not in the release build
for repo in hashicorp/terraform redis/redis elastic/elasticsearch; do
  curl -sSf "https://raw.githubusercontent.com/$repo/main/LICENSE" \
    | shasum -a 256 | awk -v r="$repo" '{print r, $1}'
done > licenses.now

diff licenses.baseline licenses.now \
  || notify "upstream LICENSE changed, trigger review"

The checklist then answers five questions, and it answers them before an announcement lands:

Question	Green flag	Red flag
Who holds the rights?	Foundation with membership structure and governance document	A single company with rights assignment across all contributions
What happens on acquisition?	Governance outlives the owner	Licensing follows the owner, as with Terraform
Is there a compatible fork?	Active fork under a foundation, with funding pledges	No fork, or a fork without institutional backing
How long does the old version hold?	Security backports committed and dated	Backports end with the next major, as with Redis CE 9.0
Where does the usage sit?	Internal only, no distribution to third parties	Embedded in a product you sell

Filling those five columns for your ten most important dependencies produces more signal than a complete license scan across 4,000 transitive packages. The assessment belongs in the same place as the question of which vendors you let into the critical path at all.

What an exit path looks like before you need it

An exit path is not a document, it is a tested state. It has three stages, and the third is usually the missing one.

First: name it. For every component in the critical path, a replacement candidate with a name. In all four cases discussed here one exists, and it is interface-compatible with the last openly licensed version, because that is precisely what it was forked from.

Second: test it. The replacement runs in continuous integration, not in a fire drill. A configuration language that runs on two implementations is a different risk from one where nobody has ever tried the second. In practice this is an integration task, not a migration: a second pipeline variant that deploys nothing and only proves that it could.

Third: define the trigger. Not “we will look at it when the time comes” but a named condition. Two work well: the end of security backports for the last openly licensed version, and the moment the component moves into a product you sell to third parties. Both are observable, both arrive with lead time, and both can hang off the same decision point where you already weigh building your own components instead of renting them.

The effort is small as long as there is no occasion for it. Which is exactly why it does not get done.

What comes after the BSL

The BSL is not the end of this development. Sentry published the Functional Source License on 17 November 2023 as a BSL successor model: a two-year conversion period instead of four, automatic transition to Apache 2.0 or MIT, and no additional use grant, whose ambiguity had been the main criticism of the BSL. Sentry and Codecov were relicensed under it.

For assessment purposes that means two things. The terms get shorter and the conversion gets more reliable. But the structural point stays the same: even a well-built source-available license is a unilateral decision by a single legal entity. What improves is the predictability of the terms, not the distribution of decision-making power.

What you have to decide this week

The question is not whether you use open source. The question is how many components in your critical path have a single legal entity that can change their terms unilaterally, and whether you have a path for those components that has actually been walked once.

Three decisions are enough to start. First: a list of the components that build, deploy or run production, recorded by legal entity rather than brand name. Second: automated watching of those components’ license files, so the trigger comes from the repository and not from a blog post someone happens to read. Third: for every single-owner component, a named replacement that runs in continuous integration.

The rest is bookkeeping. If you want to see what this assessment looks like for an existing architecture, talk to us.

Sources

Note on sourcing: The Cyber Resilience Act figures come from the European Commission's official summary; the EUR-Lex full text of Regulation (EU) 2024/2847 could not be retrieved in a usable form. For legally binding statements, only the version published in the Official Journal applies, in particular Articles 3, 14, 24 and 71. The claim that the later license reopening did not trigger a return migration rests on the indicators named above and cannot be established as a negative proof. Circulating adoption figures for OpenTofu and named user references could not be verified against primary sources and are deliberately not used here. This article is not legal advice; for an assessment of your specific licensing situation, consult qualified counsel.

Key Takeaways