Terraform vs OpenTofu

The BUSL incumbent vs the Linux Foundation fork. License, governance, state encryption, and migration trade-offs.

Feature Matrix	Terraform HashiCorp's industry-standard IaC tool, source-available under BUSL since 2023.	OpenTofu The community fork under the Linux Foundation — MPL-licensed and drop-in compatible.
License The license change in 2023 is the entire reason OpenTofu exists.	BUSL 1.1 (source-available, production restrictions for competitors)	MPL 2.0 (true open source, OSI-approved)
Governance OpenTofu features are proposed and voted on in public.	HashiCorp (IBM) — closed roadmap	Linux Foundation — open RFC process, community steering
Compatibility Same HCL, same providers, same state format — migration is usually a binary swap.	Reference implementation	Drop-in replacement up to the 1.5.x fork; diverging since
State Encryption OpenTofu encrypts state at rest before it ever reaches the backend.	Not built in (relies on backend encryption like S3 SSE)	Native client-side state and plan encryption
Exclusive Features Both projects now ship features the other doesn't have.	Stacks, HCP Terraform integration, Sentinel policies	State encryption, provider iteration (for_each), early variable evaluation
Provider & Module Ecosystem Providers are MPL-licensed, so both tools share the ecosystem.	Terraform Registry (usage restricted by HashiCorp ToS)	OpenTofu Registry mirrors the same providers and modules
Enterprise Platform Most third-party TACOS platforms support both; HCP is Terraform-only.	HCP Terraform / Terraform Enterprise	Works with Spacelift, env0, Scalr, Atlantis, Terragrunt
When to Choose For greenfield self-managed IaC, the license alone often decides it.	Already on HCP Terraform, need Stacks or Sentinel, vendor backing required	Open-source mandate, state encryption, avoiding BUSL legal review

OpenTofu vs Terraform (2026): The Fork, the License, and Which to Pick

The deep-dive companion to this table — the license backstory, concrete feature divergence, migration cost, and an opinionated segmented verdict.

Read the Blog Post

Terraform vs OpenTofu: how to choose

OpenTofu is a fork of Terraform created after HashiCorp relicensed Terraform from MPL to the Business Source License in 2023. It is now a Linux Foundation project. For most existing configurations the two remain close enough that migration is measured in hours, and the decision is about licensing, governance and roadmap rather than day-to-day authoring.

The BUSL matters far less than the discussion around it implies for the vast majority of users. It restricts offering Terraform as a competing commercial product; running it to manage your own infrastructure is unaffected. If you are not building a Terraform-based product, the licence is unlikely to change what you can do.

The real divergence is direction. HashiCorp, now part of IBM, invests where its commercial platform does. OpenTofu is governed openly and has shipped features the community wanted, notably state encryption and provider-level exclusions. The gap grows slowly but it grows, so the assumption that they are interchangeable will weaken over time.

Decision matrix: which one fits your situation

Your situation	Use	Why
Existing Terraform, no licensing concern	Terraform	Migration has a cost and no benefit if the licence does not affect you.
Building a product that wraps or offers IaC	OpenTofu	This is precisely what the BUSL restricts. Get legal advice, but the fork exists for this case.
Committed to Terraform Cloud or Enterprise	Terraform	The commercial platform is where HashiCorp's integration work lands.
Want open governance and vendor neutrality	OpenTofu	Linux Foundation project with a public roadmap and no single commercial owner.
Need client-side state encryption	OpenTofu	Shipped in OpenTofu; not an equivalent native feature in the open Terraform CLI.
Public module author	Either — test both	Your consumers use both. Compatibility is your responsibility either way.

What migration actually involves

For ordinary configurations it is close to a binary swap: OpenTofu reads the same HCL and the same state format, and the CLI is command-compatible. Teams typically change the binary in CI, run a plan against a non-production workspace, confirm it is empty, and proceed.

The parts that need attention are the registry your providers and modules resolve from, any use of Terraform Cloud or Enterprise as a backend or run environment, and version pinning across every pipeline that runs the binary. Do it on a branch with a real plan diff as the acceptance test, and keep a state backup — the risk is not the language, it is the state.

Frequently asked questions

Does the BUSL actually affect my company?

Almost certainly not, if you use Terraform to manage your own infrastructure — that is explicitly permitted. It restricts offering a competitive product built on Terraform. Consultancies delivering Terraform work for clients are generally fine; vendors building a Terraform-based platform are the intended target. This is a question for your legal team, not a blog post, but the practical answer for most users is that nothing changes.

Are they still compatible?

Highly, for now, and decreasingly over time. OpenTofu forked from Terraform 1.5.x and both have shipped features since; each has capabilities the other lacks. Configurations using common resources and syntax work on both today. Treat compatibility as a current fact rather than a permanent guarantee, and test rather than assume if you are relying on it.

Can I move back if I change my mind?

Generally yes, provided you have not adopted OpenTofu-specific features. State encryption is the obvious one-way door — encrypted state is not readable by Terraform. Keep the migration reversible by avoiding fork-specific features until you have decided, and keep an unencrypted state backup taken before the switch.

Which do providers support?

Both, in practice. Providers are separate binaries with their own release cadence, and the major ones work with either. The difference is the default registry each CLI resolves from, which matters mainly for private or mirrored registries and for anything with unusual distribution.