OpenTofu vs Terraform — A Comparison

In August 2023, HashiCorp switched Terraform's license from Mozilla Public License 2.0 to the Business Source License — a change aimed at stopping competitors from repackaging Terraform as a paid product, but one that also spooked a large chunk of the open-source infrastructure-as-code community. Within weeks, a group of vendors (Spacelift, Env0, Gruntwork, Harness, and others) forked the last MPL-licensed Terraform commit and donated it to the Linux Foundation as OpenTofu. Two years on, the practical question for most teams isn't ideological — it's whether OpenTofu is a safe drop-in replacement, and whether migrating is worth the churn.

What actually changed with the license

The BSL doesn't restrict most Terraform users at all — you can still use it freely for building and running your own infrastructure, internal tooling, or client work. What it restricts is building a competing product on top of it: a managed Terraform-as-a-service offering, for instance, now needs a commercial agreement with HashiCorp. That's a narrow restriction in practice, but it was enough to make foundations, some enterprises, and any project with strict open-source licensing policies (many can't depend on BSL code at all) want an alternative with no such carve-out. OpenTofu ships under MPL 2.0, the same license Terraform used before the switch, with no BUSL-style commercial restriction attached.

Compatibility in practice

For the overwhelming majority of configurations, OpenTofu is a drop-in replacement — same HCL syntax, same provider plugin protocol, same core commands (plan, apply, destroy). Most teams migrate by installing the tofu binary, pointing their CI at it instead of terraform, and running plan to confirm zero unexpected diff. Where the two have started to diverge is newer language features — OpenTofu has shipped things Terraform doesn't have yet (like native support for iterating over provider configurations, and encrypted state as a first-class feature) while HashiCorp has continued adding its own Terraform-only features on the other side. Neither project is purely a subset of the other anymore; they're two codebases that started identical and are slowly accumulating independent capabilities.

# Most CI migrations are this simple for compatible configs
- terraform init
- terraform plan -out=tfplan
- terraform apply tfplan

# becomes
- tofu init
- tofu plan -out=tfplan
- tofu apply tfplan

# state files, .tfstate format, and the provider plugin protocol
# are unchanged, so existing remote state backends keep working

State files and provider registries

OpenTofu reads and writes the same state file format Terraform uses, so migrating an existing project doesn't require any state migration step — you point the new binary at the same backend (S3, Terraform Cloud-compatible backends, etc.) and it just works. The provider ecosystem is where things get more nuanced: OpenTofu can pull providers from the standard Terraform Registry, but it also runs its own registry mirror to guard against HashiCorp changing registry terms of service in a way that could lock out non-HashiCorp tooling in the future. In practice this is invisible unless a provider maintainer does something registry-specific; almost every provider that works with Terraform works with OpenTofu unchanged.

Why teams are, or aren't, migrating

Teams migrating tend to cite the license risk directly — foundations, government-adjacent work, and companies with policies against BSL dependencies don't have much choice. Teams staying on Terraform tend to cite inertia and risk aversion more than any technical preference: existing CI pipelines work, existing state is fine where it is, and switching the tool underneath a production infrastructure codebase is a change with real (if small) risk for a benefit that, for most non-vendor teams, is mostly philosophical. Neither position requires the other to be wrong — this is one of the few tooling decisions where "wait and see what your peers do" is a defensible strategy, since compatibility has held up well enough that switching later remains cheap.

Wrapping up

OpenTofu exists because of a licensing decision, not a technical failing in Terraform — and for most configurations it remains close enough to a drop-in replacement that migrating is a low-risk, mostly symbolic move. The real decision points are whether your organization's licensing policy cares about BSL, and whether you depend on HashiCorp's commercial platform features that don't have an OpenTofu-ecosystem equivalent yet. Everything else — state format, HCL syntax, the bulk of the provider registry — has stayed compatible enough that this is a decision you can revisit later without much cost either way.