Earlier this month Redis 8 shipped with AGPLv3 restored as a licensing option, fourteen months after the project left open source for dual source-available licences. It is the second walk-back in nine months: Elasticsearch added AGPLv3 back last August, three and a half years after leaving. With both reversals on the record, the whole arc can now be read end to end, and it reads better as a supply-chain story than as the community drama it was covered as.
The wave¶
MongoDB moved to the Server Side Public License in October 2018, naming cloud providers who sold the database as a service without carrying development cost. Elastic followed in January 2021, and AWS responded within weeks by forking Elasticsearch as OpenSearch. HashiCorp adopted the Business Source License in August 2023 for Terraform, Vault, Consul and the rest of its line; the community response became OpenTofu, which reached general availability under the Linux Foundation in January 2024. Redis changed terms in March 2024 and the Linux Foundation announced the Valkey fork eight days later.
Each vendor's stated reason was the same economic complaint, and it is not a frivolous one: the hyperscalers captured the operating margin on software whose development they did not fund. The relicensing wave was the vendors' answer to the funding problem, the one the xz incident showed at the individual-maintainer scale. The forks were the answer from the businesses built on the software: hyperscalers for OpenSearch and Valkey, the toolmakers around Terraform for OpenTofu. Nobody in the chain was behaving irrationally, which is what makes it a structure rather than a scandal.
What made the forks viable¶
The forks that stuck share three properties, and they are checkable in advance. The code at the fork point was under a permissive licence, so there was something lawful to fork. The parties doing the forking had operational revenue riding on the software, so the maintenance burden landed on organisations with an incentive to carry it indefinitely. And in each case a foundation took the trademark-adjacent naming problem away by hosting the fork under a new name, which is why the question "who owns the name" sits in the same governance territory as standards.
The property that decides whether relicensing is possible at all is copyright concentration. A contributor licence agreement or copyright assignment that grants relicensing rights lets one party change the terms unilaterally. The agreements differ, so the answer lives in the text of the one your dependency uses. A project with distributed copyright, the Linux kernel being the canonical case, cannot be relicensed unilaterally by anyone: it takes consent or replacement, contributor by contributor, which the kernel's own documentation treats as practically unachievable. That single fact about a dependency is worth more than its licence text, because it bounds what the licence can become.
The same move without any source code¶
Broadcom closed its acquisition of VMware in November 2023 and within weeks had ended the sale of perpetual licences. VMware's own notice of the end of availability followed in January 2024: no new perpetual entitlements, no renewal of support on existing ones, subscription as the only path forward. The Broadcom knowledge-base article lists the affected products, which is to say most of the virtualisation estate of most enterprises.
A perpetual licence survived the change in a narrow and instructive sense: the right to run the versions you already hold. Patches, updates and support run out with the last contract. For an operator that is the same event as a relicence. The terms of trade on an installed dependency changed and the installed base had no vote. The only engineering question that matters is the one that should have been asked at adoption time: what is our position on the day the terms change?
The open-source cases and the proprietary case usually get discussed in different rooms, one as a licensing controversy and one as a procurement problem. They are the same risk. The BSL conversion clause, the SSPL service condition and the subscription cliff are all answers a supplier gave to the question of how to monetise an installed base, and the installed base found out when the announcement shipped.
What to check before depending¶
The list we now apply, written down so it survives the next wave:
- The licence of record, per version. A relicence binds future releases, never the copies you hold. BSL additionally converts each release to an open licence after its change date, which for BSL 1.1 is at most four years. Pin the version, record its licence, and the worst case is a frozen dependency rather than a surprise obligation.
- Who can change the terms. A CLA or copyright assignment that grants relicensing rights means one party can; distributed copyright means nobody can unilaterally. The agreements differ, so read the one in the repository, not the project's reputation.
- Whether a fork constituency exists. Large operators with revenue on the line, a foundation willing to host, a permissive licence at the fork point. Where those exist, "we would move to the fork" is a plan. Where they do not, it is a slogan.
- For proprietary dependencies, what perpetual means. Usually it means the binary keeps running and everything around it expires. Price the exit on the day you sign, because the vendor has already priced the lock-in.
The walk-backs do not change the list. Elastic and Redis returning to copyleft licences shows the forks imposed a real cost. A dependency whose terms changed twice in two years has demonstrated the property that matters: its terms can change again.