License Changes Are Vendor Risk

Why a license change is not a legal topic

In most companies, license review comes at the very end. A tool checks the list of components while the software is being built. Someone looks whether anything with copyleft obligations slipped into the shipped product. Copyleft means: whoever passes the code on has to publish their own code under the same license. After that the topic counts as closed. This review answers exactly one question: am I allowed to ship this today.

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

On 10 August 2023, HashiCorp answered that second question for an entire class of tooling. The company announced that all future versions of its core products would move from MPL 2.0 to the Business Source License 1.1. Affected were Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer and Vagrant. Interfaces and 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 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.

That same file says something else today. The licensor on record is International Business Machines Corporation. IBM completed the acquisition of HashiCorp on 27 February 2025. So the party deciding the terms of use for your infrastructure tooling changed owner once more after the license change.

The point in one sentence

License risk is not a one-time check but an ongoing watch: whoever assessed in 2023 who they were trusting had a different counterparty in 2025, without a single thing changing in their software.

What BSL, SSPL and the Elastic License govern

Three licenses are displacing MIT and Apache in the infrastructure layer. They work differently and the differences matter for your risk assessment.

BSL 1.1 is explicitly not an open source license. But it has a built-in expiry date. Every version converts to an open license on a stated date, at the latest four years after its first publication. The frequently quoted four years are therefore not vendor goodwill but the contractual ceiling. For Terraform the four-year term applies and the target 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. The licensor had withdrawn it from the approval process once it became clear it would not be approved.

Elastic License 2.0 is the third variant. For users it is the one that matters most in practice, because the Elasticsearch packages available by default for download still ship under it.

Where the risk threshold for users runs

The most important passage is not in the license text but in the accompanying questions and answers. Redis defines the trigger as a commercial competing offering: a product sold to third parties, derived from the code, that substantially overlaps with a Redis product. Internal use within your own company, 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. 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 license change is to stay on the last openly licensed version. That works, but only for a while. Redis committed to security updates for the BSD-licensed legacy versions explicitly only until the release of Redis Community Edition 9.0. All 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 license changes, four forks

Each of these license changes was followed by a fork. A fork is a copy of the source code that continues to be developed independently under the old license.

Project	License change	Fork
Elasticsearch	Apache 2.0 to SSPL and Elastic License, 14 Jan 2021	OpenSearch, under the OpenSearch Software Foundation of the Linux Foundation since 16 Sep 2024
Terraform	MPL 2.0 to BSL 1.1, 10 Aug 2023	OpenTofu, at the Linux Foundation since 20 Sep 2023, CNCF sandbox since 23 Apr 2025
Vault	MPL 2.0 to BSL 1.1, 10 Aug 2023	OpenBao, OpenSSF sandbox project since 17 Jun 2025
Redis	BSD 3-Clause to RSALv2 and SSPLv1, 20 Mar 2024	Valkey, at the Linux Foundation since 28 Mar 2024

The pattern is the same in all four rows. The license change 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 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, because it shows how unevenly these costs are distributed.

Elastic added the AGPL on 29 August 2024 as a third license option. The reopening is narrower than the headline suggests. According to Elastic’s own licensing answers, the AGPL applies to the source code from version 8.16 onward. The packages available by default for download remain under Elastic License 2.0. The return concerns the source option, not the shipped default package.

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 to more than one billion. According to the foundation, contributions came from more than 400 organizations.

Redis followed a similar path. On 1 May 2025, AGPLv3 was added as an additional option, starting with Redis 8. RSALv2 and SSPLv1 remained in place. Valkey kept developing independently afterwards: version 9.0 was released on 21 October 2025 under the Linux Foundation.

On top of that sits a layer entirely outside the vendor’s control. Fedora replaced Redis with Valkey system-wide from Fedora Linux 41, explicitly because of the SSPL, which the distribution’s licensing rules do not allow. Existing installations were switched automatically on upgrade. Once a distribution has changed the default, your team no longer decides what lands on a freshly provisioned server.

And the fork acquired a price. AWS prices its Valkey service lower than the other engines. 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 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 defaults in the distributions, growing download numbers, a price advantage. For a risk assessment that is enough. A return is not impossible, but it costs a second migration budget that nobody signs off.

Why a foundation home is a hard selection criterion

The real difference is not the license but the structure that decides it. A company holding all the rights can change the license whenever it wants. A foundation with members practically cannot, because the same decision there requires agreement among competing companies.

That is exactly why the forks went to foundations. OpenTofu was accepted as a Linux Foundation project on 20 September 2023 under MPL 2.0, with pledges from more than 140 organizations. On 23 April 2025 it was additionally accepted into the CNCF at sandbox level. The OpenSearch Software Foundation was established under the Linux Foundation on 16 September 2024 when AWS transferred the project. OpenBao, the fork of Vault, has been a sandbox project of the OpenSSF since 17 June 2025.

That this structure is more than a gesture became clear in the conflict that followed. HashiCorp sent OpenTofu a cease and desist letter on 3 April 2024 over allegedly copied BSL code. OpenTofu rejected the claims publicly on 11 April 2024 and documented where the code came from. A fork without 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, has been in force since 10 December 2024. The reporting obligations under Article 14 apply from 11 September 2026, the main obligations from 11 December 2027. Article 24 creates the role of the open-source software steward: legal entities that provide sustained support for the development of open source software intended for commercial purposes. Stewards must maintain a security policy, handle vulnerabilities and report actively exploited ones. They face no fines. That makes a foundation home not just a governance preference but a nameable role in your supply chain.

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 list of the components that build, deploy or run your production. For each of them, a statement about who can change the terms.

critical_path: [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
  foundation: allow

require_for_critical_path:
  exit_path_documented: true
  license_file_watched: true
  upstream_owner_recorded: true
  resale_exposure_flagged: true

The four requirements in the last block mean: a compatible replacement is named and tested. The project’s license file is watched. The legal entity is recorded, not the brand name. And it is flagged whether the component ships in a product you sell.

The third requirement 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. The file changes in the repository before any press release appears and it can be watched continuously. A small script that runs nightly is enough:

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"

Your checklist then answers five questions before an announcement lands:

Question	Green	Red
Who holds the rights?	Foundation with members and a governance document	A single company that receives the rights to all contributions
What happens on acquisition?	Governance outlives the owner	Licensing follows the owner, as with Terraform
Is there a compatible fork?	Active, under a foundation, with funding pledges	No fork or one without institutional backing
How long does the old version hold?	Security updates committed and dated	Updates end with the next major version, as with Redis
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 thousands of 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 the four cases above one exists in each case and it is compatible with the last openly licensed version, because that is exactly what it was forked from.

Second: test it. The replacement runs in your automated tests, not in a fire drill. A configuration that runs on two tools 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 variant of the pipeline 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 updates for the last openly licensed version and the moment the component moves into a product you sell to third parties. Both are observable and both arrive with lead time.

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 point. Sentry published the Functional Source License in November 2023 as a successor model: a two-year term 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.

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 restricted license is the unilateral decision of a single legal entity. What improves is the predictability of the terms, not the distribution of decision-making power.

What you can check now

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 steps 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 your tests.

How much of this you need depends on your starting point. If you only operate internally and resell nothing, a list and a watch get you far. If you want to see what the assessment looks like for your architecture, get in touch.

Note

This article is not legal advice. The Cyber Resilience Act details come from the European Commission's summary, only the text in the Official Journal is binding. The claim that the later reopening did not trigger a return migration rests on indicators and cannot be proven.

A license change costs you a migration and taking it back does not refund it

Key Takeaways