What "Open" Means After HashiCorp

In August 2023, HashiCorp swapped Terraform's license from the Mozilla Public License to the Business Source License, and thousands of engineering teams discovered simultaneously that a load-bearing piece of their infrastructure had changed its legal nature overnight, without a version bump, without a migration guide, without asking. The code was identical the next morning. The deal was not.

What followed is now a complete story with a beginning, middle, and instructive end: the community forked, the fork survived, and the company got acquired anyway, by IBM, for $6.4 billion, closing February 27, 2025. This post is about what that story settled. My claim: after HashiCorp, license risk belongs in the same planning category as provider outages and vendor acquisitions, because "open source" turned out to describe a current state rather than a commitment, and the difference between those two things is your exposure.

The timeline, compressed

The BSL's mechanics matter more than its reputation. It's not a rug-pull to proprietary: source stays visible, most end users remain unaffected, and each release converts back to open source after four years. What it restricts is use "in a competitive way" with HashiCorp's own offerings, which is to say it was a targeted strike at the vendors building commercial products on Terraform. Precise, defensible, and quietly radical, because it demonstrated that a license everyone had treated as ground truth was actually a policy, revisable by whoever holds the copyright.

The community's answer arrived within weeks: a coalition forked Terraform 1.5, the last MPL release, and OpenTofu went to the Linux Foundation with commercial backers whose businesses depended on the fork existing. Then the ending nobody's talking point predicted: IBM bought the whole company. The BSL didn't block the acquisition or get reversed by it; instead the license question acquired a second layer, because now the copyright that can rewrite the deal sits inside a portfolio strategy nobody outside Armonk controls.

What the fork actually proved

Forks were always open source's constitutional theory: the community's right of exit, the reason single-vendor control was supposedly tolerable. Theory, mostly, because executed forks that thrive are rare; forking is expensive, thankless, and usually starves. OpenTofu is the counterexample that matters precisely because it worked: foundation governance, real releases, real adoption, vendors funding it out of existential need rather than idealism.

But look at the conditions that made it work, because they're the actual checklist. A permissive license existed to fork from. The affected parties were companies with revenue, not volunteers with weekends. The project's surface area was forkable by a small expert group. And a neutral foundation stood ready to hold the keys. Remove any one of those and the constitutional theory reverts to theory, which is exactly the audit you should run on every load-bearing dependency you have: not "is it open today" but "if the deal changed tomorrow, does a credible fork coalition exist, and would we be in it or waiting on it?"

Depending on VC-backed open source without getting burned

The structural fact underneath all of this is unglamorous: a venture-backed company whose product is open source has promised its investors an outcome, and the commons it built is the asset it will eventually monetize harder. That's not cynicism; it's the deal working as designed, and it has a small set of endings, relicense, acquisition, or both. HashiCorp did both. Pretending otherwise is how teams end up surprised by events that were structurally predictable the day the Series C closed.

So read the boring documents before you build on the shiny repo. Who holds the trademark and the copyright, one company or a foundation? Does a contributor license agreement concentrate relicensing power? What does the license convert to, and when? Is governance a committee or a courtesy? None of this appears in the quickstart, all of it determines what happens to you in year four, and the graph-versus-text argument we've made about infrastructure applies to its legal layer too: the dependency structure you can't see is the one that gets you.

The steelman: HashiCorp had a point

The uncomfortable case for the relicense deserves its space. Building commercial products on someone else's open source while contributing little back is legal free-riding, hyperscalers industrialized it, and a company watching others monetize its R&D isn't paranoid to respond. The BSL genuinely spared end users. MongoDB and Elastic walked similar roads and their businesses survived, their ecosystems adapted, and some of their forks even made the original vendors sharper. If open source companies can't capture value, the argument goes, there will eventually be less open source, and everyone loses slower but loses.

Most of that stands. What doesn't survive is the conclusion that nothing changed for the people downstream. The old equilibrium let you treat a license as terrain, fixed, walkable, boring; the new one requires treating it as weather. Both are livable. Only one of them is what a decade of "just use the open source tool" advice assumed, and infrastructure teams got moved from the first world to the second without a memo. The memo is what this post is for.

The operational conclusion fits in a sentence: depend on open source exactly as much as you like, and know your exit the way regulators now make banks know theirs. A fork you could join, a compatible alternative you've tested, an abstraction that makes the tool swappable, any of these converts a relicense from crisis to changelog. Which of your load-bearing dependencies could rewrite its deal tomorrow, and do you know your answer, or just your hope?