When HashiCorp moved Terraform from the Mozilla Public License to the Business Source License in 2023, the response from a coalition of cloud vendors and IaC users was to fork the last MPL-licensed release into a Linux Foundation project: OpenTofu. Enough time has passed since then that the “is it basically the same tool with a different name” question has a real answer, and the answer is: not entirely, and the gap is growing.

The License Question Is Settled — the Compatibility Question Isn’t

The license motivation is straightforward and hasn’t changed: BSL restricts building a competing commercial product on top of Terraform, which is a real constraint for the vendors (several major cloud and IaC-tooling companies) who backed the OpenTofu fork. OpenTofu remains Mozilla Public License 2.0, genuinely open source with no field-of-use restriction, governed under the Linux Foundation with a technical steering committee rather than a single vendor.

What’s changed since the fork isn’t the license positioning — that was decided on day one — it’s the technical delta that’s accumulated as each project has continued independent development.

Where OpenTofu Has Actually Diverged

State encryption. OpenTofu shipped native state encryption — encrypting the Terraform state file at rest using a configurable key provider, without needing a third-party wrapper or a backend that happens to support server-side encryption. This addresses a long-standing complaint: Terraform state can contain sensitive values (database passwords, API keys pulled from data sources) in plaintext, and encrypting it previously required backend-specific tricks or external tooling. Terraform itself has not shipped an equivalent built-in feature.

Provider and module iteration. OpenTofu added the ability to iterate over provider configurations (for_each on providers), letting a single module deploy the same resources across multiple provider configurations — useful for multi-region or multi-account deployments that previously required awkward module duplication or count-based workarounds. This is a genuine ergonomics improvement that Terraform’s HCL didn’t support at the time of the fork.

Early variable evaluation. OpenTofu relaxed some of Terraform’s restrictions on where variables can be referenced (specifically around backend configuration and provider requirements), reducing the number of places users hit “variables not allowed here” errors that existed for implementation reasons rather than genuine architectural constraints.

Terraform’s own trajectory. HashiCorp has continued shipping Terraform features independently — ephemeral resources and write-only arguments (for handling secrets that shouldn’t persist in state at all, a different approach to the same underlying problem OpenTofu’s state encryption addresses), along with continued HCP Terraform (the rebranded Terraform Cloud) integration deepening. Terraform’s ecosystem lock-in through HCP Terraform’s remote state, run management, and policy-as-code (Sentinel) remains a meaningful differentiator that OpenTofu’s equivalent (currently earlier-stage) hasn’t fully matched.

Provider Compatibility: The Practical Question Most Teams Actually Ask

For the overwhelming majority of provider ecosystem — AWS, Azure, GCP, Kubernetes, and the long tail of community providers — OpenTofu works with the same provider binaries because the provider protocol (gRPC-based, versioned independently of the core tool) hasn’t diverged. A team migrating an existing Terraform codebase to OpenTofu typically changes very little: the provider blocks, resource blocks, and module structure carry over directly in the common case.

Where it gets more complicated: HashiCorp’s own first-party providers occasionally add license terms or registry restrictions that create friction for OpenTofu users specifically (registry access being the most commonly cited friction point, since OpenTofu maintains its own provider registry mirror rather than depending on HashiCorp’s registry indefinitely). Community and third-party providers are unaffected, since they’re licensed independently of HashiCorp.

State file format has also stayed compatible enough that migration in either direction (Terraform to OpenTofu or back) works without a rewrite for most codebases — a deliberate design goal on OpenTofu’s part to keep migration risk low, since forcing a state-format break would have been a major adoption blocker.

Ecosystem and Registry: The Less-Discussed Divergence

Beyond core tool features, the two projects’ registry ecosystems have grown apart in ways that affect day-to-day module and provider discovery. HashiCorp’s Terraform Registry remains the larger index by raw module and provider count, reflecting its multi-year head start and continued status as the default registry referenced in most existing tutorials, blog posts, and Stack Overflow answers. OpenTofu maintains its own registry, seeded from a mirror of MPL-compatible content at fork time and growing independently since, with automated compatibility checks that flag providers requiring registry-specific handling.

For a team’s day-to-day module authoring, this mostly doesn’t matter — public modules referenced by source URL rather than registry shorthand work identically in both tools, and most community modules haven’t needed to change anything to remain compatible with both. Where it does matter is discoverability: a team searching for a niche, less-common provider is more likely to find broader community documentation and examples written against Terraform’s registry and ecosystem, simply due to the larger existing corpus, even when the provider itself works identically under OpenTofu.

Governance Structure: Why It Matters Beyond the License Text

The governance difference is arguably more consequential long-term than the specific technical features that have shipped so far. OpenTofu operates under the Linux Foundation with a technical steering committee drawn from multiple organizations (including several competing cloud and infrastructure vendors), meaning no single company can unilaterally change the license or roadmap direction — a structural guarantee against a repeat of the exact event (a single vendor’s license change) that triggered the fork in the first place.

Terraform’s governance remains HashiCorp’s alone, which is a normal and unremarkable governance model for a commercially backed open-source project, but it does mean the BSL terms (or any future licensing decision) rest on a single company’s business priorities rather than a multi-stakeholder process. For platform teams making a decade-scale infrastructure-tooling bet, this governance distinction is worth weighing independently of this year’s specific feature comparison, since it speaks to how each project’s trajectory could shift in the future.

Which One Should a Platform Team Actually Pick

For a team starting fresh with no existing Terraform investment, the honest comparison comes down to: does the team need HCP Terraform’s specific ecosystem (Sentinel policy-as-code, its particular run-management UI, HashiCorp support contracts) badly enough to accept BSL’s field-of-use restriction, or does the state-encryption and provider-iteration ergonomics plus the unrestricted MPL license outweigh that.

For most platform teams — who aren’t building a commercial product on top of the IaC tool itself, and who care more about the day-to-day authoring experience than about a specific enterprise governance feature — OpenTofu’s technical improvements plus the license clarity make it the more defensible default choice in 2026. Teams already deeply invested in HCP Terraform’s workflow (existing Sentinel policies, established run-management processes) face a real switching cost that isn’t purely technical, and for them staying on Terraform remains reasonable.

The fork stopped being primarily a licensing story once OpenTofu started shipping features Terraform doesn’t have. It’s now a genuine technical choice between two actively-developed tools that happen to share a common ancestor — closer to “Terraform vs Pulumi” territory than “same tool, different sticker.”

Migration Effort in Practice

Teams that have already migrated existing Terraform codebases to OpenTofu report the effort concentrates in a few predictable places rather than being spread evenly across a codebase. The .tf files themselves typically need no changes at all — resource blocks, data sources, and module calls are syntax-compatible since OpenTofu forked at the HCL language level, not a separate language. The work shows up in CI/CD pipeline definitions (swapping the binary being invoked, updating version-pinning syntax if the pipeline checks a specific Terraform version string), in any custom tooling that shells out to terraform by name rather than a configurable binary path, and in verifying that any provider-specific Terraform Cloud/Enterprise integrations (remote state backends configured for HCP Terraform specifically) have an OpenTofu-compatible equivalent, since OpenTofu doesn’t integrate with HCP Terraform’s remote backend the same way Terraform does natively.

For a typical mid-sized codebase (dozens of modules, a handful of environments), teams report this as a low-effort migration completable well within a sprint, with the caveat that any team relying specifically on HCP Terraform’s remote-run execution (not just remote state storage) faces a more involved transition, since that’s the piece of the ecosystem OpenTofu’s alternatives (Spacelift, env0, Scalr, or a self-hosted CI-driven approach) replace rather than directly interoperate with.

Frequently Asked Questions

Can I migrate an existing Terraform codebase to OpenTofu without rewriting it? In the common case, yes. Provider blocks, resource definitions, and module structure carry over directly since the provider protocol hasn’t diverged, and state file format has stayed compatible by deliberate design on OpenTofu’s part.

Does OpenTofu support everything HCP Terraform (Terraform Cloud) does? Not fully. HCP Terraform’s Sentinel policy-as-code and its established run-management workflow remain ahead of OpenTofu’s equivalent tooling, which is earlier-stage. Teams deeply invested in that specific ecosystem face a real switching cost.

What’s the single biggest technical reason to prefer OpenTofu? Native state encryption is the most cited concrete feature gap — OpenTofu encrypts state at rest without needing backend-specific tricks, while Terraform requires either a supporting backend or a different mechanism (ephemeral resources) to avoid the same problem.

Is the BSL license actually a problem for a typical platform team? Only if the team is building a commercial product that competes with Terraform itself. For internal infrastructure use — the overwhelming majority of platform teams — BSL’s field-of-use restriction doesn’t bind in practice, though the philosophical preference for unrestricted open source still drives some teams to OpenTofu regardless.