Modernization
Two years after the license turn
HashiCorp relicensed in August 2023, Redis followed, and the forks are now old enough to evaluate. An essay on licenses as architectural dependencies.
Code, Noted4 min readModernization
Two Augusts ago, HashiCorp moved Terraform and its siblings from open source to the Business Source License, and an industry that had treated licensing as legal wallpaper spent a week discovering it was load-bearing. Redis followed in March 2024, Elastic had walked the road earlier, and each departure produced the same sequence: outrage, a foundation-hosted fork, and a migration question landing on architecture teams who had never listed "license" as a dependency at all.

Two years is enough distance to write about the pattern calmly, and the pattern deserves calm, because it is not a morality play. It is a structural feature of how the industry now builds, and it will recur.
Begin with the definition the incidents forced. A software license is a dependency in the strict sense: a thing your system requires, controlled by someone else, that can change on their schedule rather than yours. The industry learned to pin library versions a decade ago; version pins do not pin licenses, because a license change applies to every version you have not yet adopted. The upgrade path itself is what gets relicensed. An estate can keep running the old artifacts indefinitely and quietly loses, from that day, its security patches, its compatibility future and its hiring story. This is precisely the shape of a deprecated platform, arriving by press release.
The forks changed the calculus in a way the first hot takes missed. OpenTofu and Valkey both went to neutral foundations within weeks of their parents' turns, and both did something the pessimists said forks could not: they retained enough maintainers and enough corporate sponsorship to ship. By 2025 the interesting fact is not that the forks exist but that they are, for many estates, the conservative choice: the option whose governance cannot perform the same maneuver again, because foundation charters are specifically built to prevent it. Conservative used to mean "the vendor's official line". The word has quietly changed sides, which is the kind of sentence one gets to write about this industry perhaps once a decade.

History offers a rhyme, as it usually does. The 1990s Unix wars taught a generation that platform rights matter more than platform features; the enterprises that bet on vendor-proprietary Unixes spent the 2000s migrating off them, while Linux, the governance-boring option, absorbed the industry. The relicensing wave is the same lesson at the component scale. Features attract; governance endures.
What should an architecture practice do with this, concretely?
License review joins the dependency review, with one question at its center: who can change this, and what must be true for them to want to? A single-vendor open-source project whose parent company has investors is one signature away from a license event, and this is not cynicism but arithmetic; the pressure that moved HashiCorp and Redis was structural, cloud providers monetizing the projects harder than the projects' owners could. Where that structure exists, the event is priced in. Foundation-held projects (the Linux, Postgres, Apache tier) carry a categorically different risk, which is drift, not revocation.
Exit costs get written down while they are cheap. The estates that handled 2023 and 2024 well were, without exception, the ones whose use of the affected tools ran through interfaces that admitted substitutes: standard protocols in front of Redis, plan-file discipline around Terraform. The estates that suffered had let a tool's proprietary edges grow into their own systems. The lesson generalizes far beyond licensing: the cost of a dependency is the cost of leaving it, measured before you must.
And the procurement reflex deserves updating. "Is it open source" was always a proxy question. The real questions were: can we run it if the vendor changes course, patch it if they stop, and hire for it in ten years? Source-available licenses answer some of those acceptably for some estates; some OSI-approved licenses attached to single-vendor governance answer them worse than their badge implies. The badge was doing too much work. Two years of forks have given the industry the vocabulary to ask the underlying questions directly.
The counterargument is commercial and honest: maintainers must eat, cloud margins were being made on their work, and BSL-style licenses are an attempt to keep the lights on without going fully proprietary. All true, and none of it changes the architect's duty, which is not to adjudicate the ethics but to model the dependency. A fair license change is still a change you did not schedule.
Licenses, it turns out, have blast radii. The estates that drew them early spent 2024 doing paperwork. The rest did migrations.