OpenTofu After the Licence Change
What actually happened to Terraform, and whether the fork is safe to run
Contents
On 10 August 2023, HashiCorp announced that Terraform — along with Vault, Consul, Nomad and the rest of the product line — was moving from the Mozilla Public Licence 2.0 to the Business Source Licence 1.1. The blog post was careful and reasonable in tone, and it landed like a brick through a window.
Six months on, the dust has settled enough to say something useful about it. OpenTofu exists, it reached 1.6.0 on 10 January, it lives at the Linux Foundation, and I have migrated everything I run to it. That last part took an afternoon and I have not thought about it since. What follows is what happened, what the licence actually says, and whether any of this should change what you do on a Sunday with a Proxmox box and too much free time.
What the BSL actually says
The Business Source Licence is a source-available licence with a time bomb attached. The source is public. You can read it, modify it, and use it — provided your use is not competitive with the licensor’s commercial offering. After four years, each release converts to the MPL, so Terraform 1.6 becomes properly open source some time in 2027.
The word doing the work is “competitive”, and HashiCorp’s FAQ went through several revisions trying to pin it down. The version that stuck says roughly: you may not host or embed Terraform in a product you sell that competes with HashiCorp’s offerings. For the person running Terraform to build VMs at home, this changes nothing at all. For a consultancy running it on behalf of clients, probably nothing. For Spacelift, env0, Scalr and the other companies whose entire business was a nicer front end on Terraform, it was an existential question mark drawn on their roadmap.
That ambiguity is the actual problem. A licence you have to ask a lawyer about is a licence with a cost, and the cost falls on everyone who is not HashiCorp. Nobody is coming for your homelab. But “probably fine” is a worse foundation for a build pipeline than “definitely fine”, and it compounds: the CI tool you use, the module registry you pull from, and the vendor whose product wraps Terraform all now have their own version of the same question.
The other thing worth saying plainly: HashiCorp were within their rights. They own the copyright, they took the CLA contributions on terms that allowed it, and they had watched large clouds monetise their work for years without contributing much back. The reasoning was legitimate. The reaction was also legitimate. Both things are true, and the interesting part is what happened next.
The fork, and why this one stuck
Most licence-change forks die quietly. Somebody publishes a manifesto, three hundred people star the repo, and eighteen months later it has one maintainer and a security backlog.
This one went differently, fast. The OpenTF manifesto appeared within two weeks, signed by companies with actual engineering payrolls attached — Gruntwork, Spacelift, env0, Harness — rather than only individuals. By 20 September the project had joined the Linux Foundation and taken the name OpenTofu, which is either a good joke or a naming committee that gave up; either way it neatly solved the trademark problem.
The fork point is Terraform 1.5.x, the last MPL release. Everything after that in OpenTofu is written by the OpenTofu contributors under the MPL. This matters legally: every line OpenTofu ships is MPL code, either inherited from the 1.5 lineage or written fresh by its own contributors, with a clean line marking where it diverges from HashiCorp’s BSL releases.
Three structural details make me think it survives. The Linux Foundation governance means no single company can pull the same lever again — the thing that made the original change possible was HashiCorp’s sole ownership, and that ownership no longer exists here. The backing companies have commercial reasons to keep it healthy, which is more durable than goodwill. And the registry at registry.opentofu.org shipped early, mirroring providers and modules, which removed the single biggest dependency on HashiCorp infrastructure.
The corresponding risk is a slow drift into two incompatible tools. Right now they are close enough that this article barely needs to distinguish them. Three years from now, with OpenTofu shipping features HashiCorp did not and Terraform shipping features OpenTofu chose differently, the module ecosystem has to pick a side or write compatibility shims. That is the real thing to watch, and nobody can tell you yet how it goes.
The forks that came before
This has happened enough times to be a genre, and the previous episodes are the best available evidence for how this one ends.
MongoDB went to the SSPL in October 2018 and nothing forked. There was grumbling, the Linux distributions dropped it from their repositories, and everyone carried on using MongoDB. The reason is that MongoDB is a database with data in it, forks are expensive to trust with your data, and the licence genuinely did not affect the people using it. Nobody had a strong enough reason.
Elastic went to the SSPL in January 2021 and AWS forked it within days as OpenSearch. Three years on, both are alive, both ship, and the ecosystem has quietly split — some tools support one, some support both, and a few log-shipping configurations now have an awkward paragraph in their documentation. That is the realistic bad outcome for Terraform: nobody dies, everybody maintains two code paths forever, and the compatibility burden lands on the module authors who are volunteers.
CockroachDB and Sentry both went BSL and nothing forked, for the same reason as MongoDB: the people who would have to maintain a fork had no commercial motivation to.
Terraform’s situation matches the Elastic pattern more than the MongoDB one, and the reason is specific. Terraform’s value lives in the provider and module ecosystem rather than in the binary, which means the fork inherits nearly all of it for free — the providers are separate MPL repositories that HashiCorp does not control. Meanwhile, an entire tier of companies had built their businesses on top of the binary and were suddenly told that their business might be a licence violation. A fork was, for them, cheaper than a lawyer. Motivation plus low cost is how forks succeed, and both were present here in a way they were not for MongoDB.
The counter-evidence is honest too. OpenSearch had AWS behind it, which is a different order of resource from a consortium of mid-sized DevOps vendors. OpenTofu is going to need those companies to keep paying engineers for years, through funding rounds and acquisitions and strategy changes. The Linux Foundation home helps with governance; it does not write code.
Who actually got hurt
It is worth being precise, because the internet was not. Homelabbers: nobody. Enterprises using Terraform to manage their own infrastructure: nobody, though several legal departments spent a fortnight confirming it. Consultancies running Terraform for clients: almost certainly nobody, though the FAQ took three attempts to say so clearly, and that fortnight of ambiguity was itself the damage.
The people who took the hit were the vendors, and the contributors. A vendor whose product is a web UI over Terraform woke up on 11 August to find their roadmap contingent on a definition of “competitive” that they did not control. And every person who had contributed a bug fix under a CLA discovered what the CLA had actually been for. That second group is why the reaction was so sharp: the licence change was legal precisely because of an agreement people had signed without expecting it to be used this way.
Migrating: genuinely an afternoon
The state file format is identical. The HCL is identical. The terraform block is still called terraform. Your .tf files need no changes whatsoever.
| |
That plan should come back with no changes. If it does, you are done. The whole migration is deleting a lock file and running a different binary.
The lock file is the only real gotcha. .terraform.lock.hcl pins provider hashes against registry.terraform.io, and OpenTofu pulls from registry.opentofu.org. The artefacts are the same providers, but the recorded hashes and the namespace differ, so init refuses to proceed against a lock file written by Terraform. Delete it, let tofu init write a fresh one, commit that.
If your state is remote, nothing changes — the backends are the same code. If you are on Terraform Cloud, the cloud block is HashiCorp’s service and OpenTofu cannot talk to it, so that migration is a genuinely different project involving moving state somewhere else first.
For belt and braces on a real project, run both against the same state in a scratch copy and diff the plans:
| |
The diff will show version strings and nothing else. I did this on three projects, found nothing, and stopped doing it.
Troubleshooting the migration
init fails with “provider registry registry.terraform.io does not have a provider named …” — you left the old lock file in place, or a required_providers block has an explicit source = "registry.terraform.io/hashicorp/aws". Shorten it to hashicorp/aws and let the tool resolve the registry.
A provider is missing from the OpenTofu registry. The registry mirrors the public providers automatically, so this mostly hits private or freshly published ones. You can point at any registry explicitly in required_providers, including HashiCorp’s — the providers themselves are still MPL, and pulling one does not put you under the BSL.
CI breaks because terraform is not found. Predictable and boring. Swap the setup action, or symlink tofu to terraform if you have scripts you cannot easily change. I would rather fix the scripts; a symlink that lies about which binary is running will confuse someone in six months, probably me.
State lock errors after switching. Same behaviour as before — a previous run died holding the lock. tofu force-unlock <ID> after you have confirmed nothing is actually running.
What OpenTofu does that Terraform does not
At 1.6 the answer is: almost nothing, deliberately. The first release was about proving the fork could ship a compatible, credible tool with a working registry, and it did that.
The roadmap is where the divergence starts. Client-side state encryption is the headline item — encrypting the state file at rest and in transit to the backend, which is something people have asked HashiCorp for since roughly forever and have worked around with SOPS and age or by trusting the backend. Provider-defined functions and a for_each in import blocks are also queued up.
Whether those land, and how well, is the thing that decides this. A fork that only tracks upstream is a hedge against a licence. A fork that ships things people wanted for years is a project. I am cautiously optimistic and entirely prepared to be wrong.
The verdict
For a homelab, the BSL is not a problem you have. Nobody is auditing your Proxmox host, and your use is unambiguously non-competitive. Anyone telling you that you must migrate is selling something.
I migrated anyway, and I would suggest you do too, for reasons that have little to do with compliance. The migration is an afternoon and reversible. Running the MPL tool means the licence question never becomes a question — not when your side project grows, not when you take on contract work, not when a client asks. Removing an entire category of “I should check that” from your life for the cost of one afternoon is a good trade.
The one group who should think harder is anyone with deep Terraform Cloud integration or an enterprise support contract. Then this is a procurement decision with a migration attached, and the calculus is different.
Everyone else: install tofu, delete the lock file, run plan, get on with your life. If you are building Proxmox VMs from HCL, the entire flow works identically — the Proxmox provider setup I use is written for tofu and would work unchanged on Terraform. The same goes for the Kubernetes side of the lab; nothing in running k3s across multiple nodes or in how Helm charts actually work cares which binary drew the machines.
The best outcome of this whole episode is that the choice stopped being frightening. Six months ago the question was whether the tool that describes everyone’s infrastructure had a future outside one company’s roadmap. It does. That was worth a fork.
Related Content
