The Terraform BSL bombshell: what it means for IaC teams

On August 10, HashiCorp moved Terraform (along with most of the rest of their open-source portfolio) from the Mozilla Public License to the Business Source License. Four days on, my inbox, my Slack DMs, and every call I’m on this week has some flavor of the same question: do I have to rip Terraform out?

The short answer is no. The longer answer is the one I want to write down, because the panic is louder than the actual license change, and the actual license change is still a structural shift worth paying attention to.

I have spent the last several months on customer engagements that look essentially the same on every cloud: an acme-aws-prod, an acme-azure-prod, and an acme-gcp-prod set of Terraform modules running in parallel, glued together with a GitHub Actions pipeline that posts the plan output back into the PR. That kind of work exists because Terraform was the closest thing the industry had to a multi-cloud lingua franca. It works because the language and the providers and the tooling were all open enough that nobody had to ask permission to build on them.

That sentence is the one the BSL is now putting pressure on.

What the BSL actually says

The BSL is not a brand-new invention. MariaDB published it years ago, and Cockroach Labs and Sentry have shipped variants of it for a while. The structure is consistent: source-available, time-delayed open source, with a carve-out that says you cannot use the software to build a competing commercial product.

For Terraform specifically, the version HashiCorp published works like this:

• The source is still public. You can still read it, fork it on GitHub, send PRs.
• You can use it freely for production use, including commercial production use, with one exception.
• The exception is that you cannot embed it in, or use it as the engine of, a competitive offering to HashiCorp’s commercial products.
• After four years, each released version converts back to a true OSI license (MPL 2.0, in this case).

Read literally, that’s a narrower restriction than the first wave of takes implied. Most teams running Terraform inside their own walls to manage their own infrastructure are not building a competitive offering. They are building their own systems. They are unaffected in the literal sense.

The reason the panic is rational anyway is the second-order effect.

The competitive-product clause is the whole thing

“Competitive offering” is the load-bearing phrase in this license, and it is not a precise phrase. HashiCorp published a FAQ that tried to clarify it. The FAQ helps in some places and makes things worse in others.

What I keep seeing in customer conversations:

• Internal platforms. A platform team builds a self-service portal that wraps Terraform and exposes it to product teams. Is that a competitive offering? The FAQ says no, but the team building it has to make that call, and the call is now a legal one, not just a technical one.
• Consultancies and MSPs. Anyone whose business model is “we run your Terraform for you” now has to look at their own deliverable through this lens. Most of them are fine. The ones who built tooling around Terraform that they license to clients have a harder read.
• The whole adjacent tooling space. Atlantis. Terragrunt. Terratest. Spacelift. env0. The dozens of smaller projects that exist because Terraform was open enough to build on. None of those projects are Terraform itself, but several of them are now staring at a license that could plausibly cover them, depending on how HashiCorp interprets it.

That last category is the one that matters most for the rest of us, because that tooling is where most of the actual day-to-day workflow improvements have come from for the last five years. If the people who build that tooling have to spend the next six months talking to lawyers, they aren’t shipping. And if some of them conclude they can’t legally keep shipping at all, the workflows that depend on them start to break.

What the community did in four days

The thing that’s actually interesting about this week is the speed of the reaction.

By the end of the weekend, an open letter, the OpenTF Manifesto, was circulating, signed by a long list of companies and individuals across the tooling. The ask was simple: HashiCorp reverts to an OSI license, or the community forks. By Monday the signature count was past 100 organizations. By Wednesday it was past 150 and climbing.

The signatures matter less than the structure of the response. Within ninety-six hours, the IaC community had produced:

1. A coordinated public position.
2. A list of co-signing organizations willing to put their names on it.
3. The beginnings of a governance plan for what a forked project would look like.
4. Working assumptions about how an upstream sync would work in the interim.

That is unusually fast. The community is signaling that the cost of letting Terraform sit under the BSL (even if the literal text is narrow) is higher than the cost of forking. That signal is worth paying attention to whether or not you personally care about the licensing details.

What I’m telling teams this week

The actual advice I keep giving, to customers, to friends running platform teams, to anyone running a terraform plan on Monday morning:

Don’t rip anything out. Whatever you have running in production today, keep running. The BSL applies to versions released after August 10. Your existing pinned versions are unaffected. There is no fire.

Audit your usage, honestly. Write down where Terraform sits in your stack. Is it a CLI you call from a CI pipeline? Is it embedded in a self-service portal you expose to internal customers? Is it part of a deliverable you sell to external customers? The answers determine how the BSL touches you, and most teams have not written this down before.

Pin your providers. Provider versions are now load-bearing in a way they weren’t on August 9. If you don’t already pin both the Terraform core version and every provider version in your modules, that’s a worth-doing this week task regardless of the license question. It’s the cheapest insurance you can buy.

Watch the fork. If a fork actually happens, and I think it will, the OpenTofu landing piece is the one I’d point at next, there will be a real choice to make about which engine you target. That choice is months out for most teams. It is not a today decision. But it’s a watch-this-quarter decision.

Don’t take the FAQ as gospel. A vendor FAQ is not a license. Lawyers will read the license, not the FAQ. If your usage is non-trivial, the right person to ask about the BSL is your own counsel, and the second-right person is the counsel of whoever else uses Terraform similarly to you.

The longer thread

The thing I keep coming back to is that we built the multi-cloud Terraform pattern, the one running in those parallel acme-aws-prod / acme-azure-prod / acme-gcp-prod repos all over the industry, on the assumption that the foundation underneath was going to stay open. That assumption was load-bearing in a way most of us never wrote down. The work itself is fine. The patterns are fine. The skills are fine. But the foundation moved.

This is not the first time the ground rules under an entire automation category have shifted. The vRA / vCloud / OpenStack era went through versions of this. The container orchestration wars went through versions of this. The pattern is the same every time: a category goes through an era of being the assumed-open thing, and then somebody (usually the steward of the most successful implementation) decides the economics have changed, and the rest of us spend the next year figuring out what to build on instead.

The good news, this time, is that the community moved faster than the vendor did. Whether the fork sticks is the next question. I’ll write that one when we know.

, Sid