Your Infrastructure Choice Is a Governance Decision Now

By Oleg

On 11 March 2026, one line changed in the license file that ships with Terraform. The Licensor stopped being HashiCorp, Inc. and became International Business Machines Corporation. No code moved, no API changed, no behaviour differed. A team that had standardised on Terraform in 2021 now had its infrastructure tooling governed by terms held by a company it had never evaluated, under a license it had never agreed to, as the delayed consequence of a decision taken three years earlier and an acquisition it had no part in.

That is the shape of the thing worth understanding. Between 2023 and 2026, four separate disputes — Terraform, Redis, LibreOffice and a 3D printer company — looked like four unrelated arguments about licenses. They were four demonstrations of the same mechanism, and the license text was never the part that mattered.

The lever is ownership, not the license

A license is a grant made by whoever holds the copyright. Relicensing existing code normally requires the agreement of every copyright holder in it, which in a genuinely distributed project means hundreds of people who will never agree on anything at once. That is not a legal technicality. It is the thing that makes a license feel like a guarantee rather than a policy.

What removes it is a contributor license agreement. Most CLAs, on the Apache model, let contributors keep ownership while granting the project broad rights; the rarer assignment CLAs transfer copyright outright. Either way, once a single entity holds enough rights over the whole codebase, relicensing stops being a negotiation and becomes a decision. One party can make it on a Tuesday.

So the useful question about a dependency is not “what license is it under” but “who is in a position to change that, and what would stop them”. In each of the four cases below, the answer turned out to be: one party, and nothing.

Terraform: the fork, the trademark, and the new owner

HashiCorp moved Terraform from MPL 2.0 to the Business Source License on 10 August 2023. BUSL is not an open source license; it restricts competing commercial use for a period before converting. Five days later a group of users published the OpenTF Manifesto asking for a reversal. There was no reversal. On 25 August the fork went public, and on 20 September the Linux Foundation accepted it — at which point it was renamed OpenTofu, because the original name raised trademark concerns.

Then it got sharper. In April 2024 HashiCorp sent a cease-and-desist alleging that OpenTofu had incorporated code from a BUSL-licensed version of Terraform and relabelled it; OpenTofu responded that the code in question came from the MPL-licensed era. IBM’s acquisition of HashiCorp, announced in 2024 and closed in February 2025, then delivered the licensor change of March 2026.

Four years on, OpenTofu is a Linux Foundation project on MPL 2.0, shipping stable releases — 1.12.6 landed on 19 August 2026. Terraform is a BUSL product owned by IBM. Both are viable. The point is that a team choosing between them in 2023 was not choosing between two tools; it was choosing between two ownership structures, and only one of the two had a mechanism that would stop this happening again.

Redis proves the reversal doesn’t restore the status quo

Redis followed the same arc and then did something the others didn’t: it went back.

In March 2024 Redis moved from BSD-3-Clause to a dual SSPL/RSALv2 arrangement, aimed squarely at cloud providers reselling it as a managed service. AWS, Google and Oracle forked the last BSD-licensed release, 7.2, into Valkey under the Linux Foundation. In November 2024 Salvatore Sanfilippo, who wrote Redis in the first place, rejoined the company, and on 1 May 2025 Redis 8.0 shipped with AGPLv3 added as a third option. Redis was open source again by OSI’s definition. It still is — Redis 8.8, from May 2026, ships under the same tri-license.

And Valkey is still there, occupying the slot Redis used to hold in Linux distributions. That is the part worth sitting with. The vendor reversed the decision, faster than anyone expected, with the original author personally driving it — and the fork did not dissolve. Distributions, packagers and platform teams had already done the migration work, and migration work is not refundable. Once a project demonstrates that its license is revisable, the demonstration is the durable fact. The license going back is not.

A foundation is not immunity

It would be convenient if the rule were “avoid single-vendor projects, prefer foundations”. April 2026 killed that rule.

The Document Foundation, the non-profit behind LibreOffice, removed foundation membership from more than thirty people employed by or contracting with Collabora — a company that has been among the largest contributors of LibreOffice code for years. TDF cited its newly adopted Community Bylaws and a conflict of interest: Collabora sells a commercial product built on LibreOffice and, in TDF’s view, had accumulated disproportionate influence inside the foundation. Collabora’s Michael Meeks called the removals unproven and a matter of guilt by association. Collabora has since said it will concentrate on a cut-down, differentiated Collabora Office and reduce its LibreOffice involvement.

Nobody changed a license here. No copyright was assigned to anyone. The governing document was a set of bylaws, the deciding body was a board, and the outcome was still a structural change to who maintains the code — which is what actually determines whether your dependency gets a security fix in three years. Foundation governance moves this risk. It does not remove it.

Enforcement is somebody else’s job, and mostly nobody’s

The fourth case runs the other way: not a vendor tightening terms, but a vendor ignoring them.

Bambu Lab’s slicer software is derived from PrusaSlicer, which is AGPLv3. After Bambu sent a cease-and-desist to an independent developer, Paweł Jarczak, over a fork of OrcaSlicer, the Software Freedom Conservancy ran a compliance investigation and published its findings on 18 May 2026: two AGPLv3 violations. Bambu bundles a proprietary networking library without releasing the corresponding source, and imposes additional restrictions that copyleft does not permit. SFC has since funded a project to replace the proprietary components and maintain open forks for affected users.

What is instructive is who did the work. Not a regulator, not a court, not the license itself — a small non-profit with a legal budget, acting years after the fact, because it chose to. A copyleft license is only as strong as the willingness of someone with standing and money to enforce it. For most dependencies, no such party exists.

What to check before something becomes load-bearing

None of this argues for avoiding commercially backed open source. Terraform, Redis and LibreOffice are good software, and the commercial backing is a large part of why. It argues for a different kind of diligence — the same structured comparison a team runs before standardising on a test automation framework or a reporting system, with governance added as a column that used to be assumed.

Five things are worth knowing before a tool gets deep enough to be expensive to remove:

• Who holds the copyright. One company, a foundation, or thousands of individual contributors. This single fact determines whether a relicense is possible at all.
• Whether there is a CLA, and which kind. An assignment CLA means the project can relicense unilaterally. A licensing CLA broad enough to permit relicensing has the same practical effect.
• Who controls the trademark. The Terraform fork had to change its name before it had changed a line of code. Trademark decides whether a fork can keep the ecosystem’s vocabulary.
• What the governing body actually is — a board, a set of bylaws, a benevolent dictator — and whether its composition can change without users having any say. TDF’s bylaws were adopted, then applied.
• What the exit costs. Not whether a fork exists, but how much of your own work is coupled to this specific project: state formats, provider ecosystems, wire protocols, operational habits. Valkey existed within weeks; the migrations took a year.

The practical test is cheap. If a project relicensed tomorrow, how long would it take you to find out, and what would you do about it? A team with a good answer has already treated the dependency as a governance choice. A team with no answer has made one anyway — it just wasn’t conscious.

This belongs to a broader drift. The same shift showed up when configuration became executable code and quietly inherited all of code’s risks. Dependency selection has been moving from a technical decision to a legal and organisational one for a decade. The disputes of 2023 to 2026 are simply the point at which pretending otherwise stopped working.