The infrastructure-as-code world is experiencing its biggest upheaval in years. Two weeks ago, HashiCorp announced they were moving Terraform (along with all their other products) from the Mozilla Public License 2.0 to the Business Source License (BSL) 1.1. The community response was swift and decisive: a coalition of companies and contributors launched the OpenTofu manifesto, pledging to maintain a truly open-source fork of Terraform. As someone who’s been deploying infrastructure with Terraform since its early days, I have thoughts.
What the BSL Change Actually Means#
Let’s cut through the noise and understand what the BSL license actually restricts. Under the new terms, you can still use Terraform freely for internal purposes. You can view, modify, and even redistribute the code. What you can’t do is offer a competing commercial product that embeds or is built on top of Terraform. The BSL converts to a fully open-source Apache 2.0 license after four years.
On paper, this sounds reasonable — HashiCorp is protecting their business from cloud providers who were building managed Terraform services without contributing back. And they have a point: the “open source commoditization” playbook that AWS and others have run against Redis, Elasticsearch, and MongoDB is well-documented.
But the devil is in the details. The BSL’s competitive use restriction is intentionally vague. What counts as a “competing” product? If I build an internal platform that manages Terraform runs for my organization, am I competing with Terraform Cloud? If a consultancy builds tooling around Terraform for their clients, is that competitive? HashiCorp says they’ll clarify through an FAQ, but legal ambiguity is itself a problem when you’re choosing foundational infrastructure.
Why OpenTofu Matters#
The OpenTofu initiative — initially called OpenTF — isn’t just a angry reaction. It’s backed by serious players: Gruntwork, Spacelift, env0, Scalr, and numerous other companies that have built their businesses around the Terraform ecosystem. The Linux Foundation is involved in governance discussions. As of this week, the manifesto has gathered hundreds of signatures from companies and over a thousand individual contributors.
The fork will be based on Terraform 1.5.x, the last version released under the MPL. The stated goal is to keep the project community-driven, vendor-neutral, and under a genuinely open-source license.
What gives me cautious optimism is that the core technical work of Terraform isn’t magic — it’s excellent engineering, but it’s engineering that a motivated community can maintain and extend. The provider ecosystem, which is arguably Terraform’s greatest strength, is largely community-maintained already. Most providers are developed by the cloud vendors themselves or by community contributors, not by HashiCorp employees.
Lessons from History#
I’ve seen this pattern before. When Oracle acquired Sun and the MySQL community got nervous, MariaDB was forked and has thrived as an independent project. When Elasticsearch moved to a non-open-source license, the OpenSearch fork emerged and has gained substantial adoption. CentOS Stream’s shift away from being a stable RHEL rebuild gave us Rocky Linux and AlmaLinux.
The pattern is clear: when a widely-adopted open-source project changes its social contract with the community, viable forks emerge. But not all forks succeed. The ones that thrive have strong governance, serious backing, and enough engineering talent to keep up with the pace of development.
OpenTofu seems to be checking those boxes. The corporate backing provides resources, the Linux Foundation involvement suggests mature governance, and the contributor pool is deep enough. But execution will determine everything. Maintaining compatibility, keeping the provider ecosystem working, and building the kind of boring reliability that infrastructure tools require — that’s the hard part.
What This Means for Your Terraform Deployments#
If you’re running Terraform in production today — and based on the surveys I’ve seen, about 60% of organizations doing infrastructure-as-code are — you don’t need to panic. The BSL doesn’t affect your ability to use Terraform internally. Your existing workflows, state files, and modules will continue to work.
But if you’re making longer-term strategic decisions about your infrastructure-as-code tooling, this is worth paying attention to. A few questions I’d be asking:
Are you dependent on the open-source ecosystem? If your Terraform setup relies heavily on community modules and third-party tooling, those ecosystem participants may gradually shift their focus to OpenTofu. This isn’t a tomorrow problem, but it could become a next-year problem.
Are you building tools on top of Terraform? If your platform team has built internal tooling that wraps or extends Terraform, the BSL’s competitive use clause creates legal ambiguity you should probably discuss with your counsel.
How do you feel about vendor lock-in? The BSL means HashiCorp can, at any point, steer Terraform’s development to favor their commercial products. That’s their right, but it’s a strategic consideration for organizations that prefer truly neutral tools.
For my own projects, I’m watching OpenTofu closely. I won’t switch tomorrow — stability matters more than ideology when you’re managing production infrastructure. But I’m mentally preparing for the possibility and keeping my configurations as portable as possible.
My Take#
I understand HashiCorp’s frustration. Building and maintaining open-source infrastructure is expensive, and watching cloud providers monetize your work without contributing back is genuinely unfair. But I think the BSL was the wrong solution. It breaks trust with the community that helped build Terraform into the standard it is today.
The right approach, in my view, would have been stronger copyleft licensing or working with the cloud providers on contribution agreements. The nuclear option of changing the license on a project with this much community investment was always going to trigger exactly this response.
What I hope comes out of this is a healthy OpenTofu project that maintains the spirit of what made Terraform great, and a HashiCorp that competes on the strength of their commercial offerings rather than on license restrictions. The infrastructure-as-code space benefits from competition, and having both Terraform and OpenTofu pushing each other forward is better than a monopoly under either license model.
The next few months will be telling. If OpenTofu can ship a credible 1.6 release and maintain provider compatibility, we might be looking at the most significant fork in the DevOps ecosystem since Jenkins split from Hudson. Stay tuned.