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

For nearly a decade, "infrastructure as code" and "Terraform" were close to synonyms. That's no longer true. In August 2023 HashiCorp relicensed Terraform from the permissive MPL 2.0 to the Business Source License (BSL 1.1), the community forked the last MPL version into OpenTofu, and the two have been drifting apart ever since. If you're picking an IaC tool in 2026 — greenfield or a migration — you now have a real decision to make. Here's the short version:

• Terraform is HashiCorp's (now IBM's) product, source-available under the BSL, tightly integrated with HCP Terraform, Sentinel, and the newer Stacks feature.
• OpenTofu is a Linux Foundation project under the truly-open MPL 2.0, governed by a steering committee, with its own registry and a growing set of features Terraform doesn't have.
• They started as near-identical twins. They are no longer identical, and the gap widens with every release.

This post walks the backstory, the concrete feature divergence, what a migration actually costs, and an opinionated, segmented verdict.

The Backstory: Why There Are Two

Terraform shipped under the Mozilla Public License 2.0 from 2014 onward — a permissive, genuinely open-source license. In August 2023, HashiCorp relicensed the code (and most of its other products) under the Business Source License 1.1. BSL is "source-available," not open source: you can read, modify, and use the code, but you may not use it to build a competing commercial offering. HashiCorp's stated target was the vendors selling hosted Terraform automation on top of HashiCorp's own work.

The reaction from the ecosystem was immediate. A group of vendors and community members forked the last MPL-licensed commit as OpenTofu, donated it to the Linux Foundation, and set up open governance. The fork is not a company product — it's a foundation project with a public roadmap and a steering committee, which is exactly the point for teams that got spooked by a unilateral license change on infrastructure they'd bet their whole stack on.

Then in early 2025, IBM's acquisition of HashiCorp closed. That doesn't change Terraform's license, and it's business context rather than a technical fact, so hold it loosely — but it's a legitimate input to a governance question. If your reason for considering OpenTofu was "I don't want a single vendor to unilaterally control my IaC tool's direction," a change of corporate ownership is worth factoring in, in both directions: IBM brings deep enterprise-support muscle, and it also concentrates control further.

Compatibility: Close, But Diverging

OpenTofu forked from Terraform 1.5.x, so the foundations are shared: the same HCL configuration language, the same core resource-graph model, the same terraform-style workflow. The CLI is tofu instead of terraform, and for most existing configurations tofu plan / tofu apply behave the way you'd expect.

Crucially, OpenTofu is state-compatible for migration: it reads existing Terraform state, so you can point tofu at a state file and keep going. That's what makes a switch feasible at all.

But do not assume perpetual identical behavior. Two forks maintained by different teams with different roadmaps drift, and these two have. OpenTofu runs its own provider and module registry (registry.opentofu.org), not HashiCorp's, and its later releases add features and behaviors that simply don't exist in Terraform (and vice versa). Treat OpenTofu as a near drop-in for migration, not as an eternally interchangeable clone.

Where They've Diverged: Features

This is the part most "they're basically the same" takes get wrong in 2026. Each side has shipped meaningful, non-overlapping capabilities.

OpenTofu-only (or OpenTofu-first):

• Client-side state encryption. OpenTofu can encrypt state and plan files at rest with your own keys before they ever hit a backend. For teams that can't fully trust their remote backend, or want defense in depth around the secrets that inevitably leak into state, this is a genuine differentiator.
• Early / -var variable evaluation. Variables and locals can be resolved early enough to parameterize things like backend and module-source configuration — a long-standing Terraform pain point.
• .tofu file overrides — you can drop a foo.tofu beside a foo.tf to override behavior specifically under OpenTofu without touching the shared .tf. (Provider-defined functions exist in both tools — Terraform shipped them first in 1.8 — so they're not an OpenTofu differentiator, though OpenTofu's variant can be used dynamically.)
• No telemetry. OpenTofu doesn't phone home.

Terraform-only:

• Stacks — HashiCorp's model for managing many related configurations and their deployments together, integrated with HCP Terraform.
• Native HCP Terraform / Terraform Cloud integration, remote execution, and the private registry that goes with it.
• Sentinel, HashiCorp's policy-as-code engine, which is tied to the Terraform/HCP ecosystem.

Features that have converged. Don't over-index on the lists above — some gaps have closed. Ephemeral resources/values and write-only arguments for keeping short-lived secrets out of state shipped in Terraform first (1.10 and 1.11) but landed in OpenTofu 1.11 (December 2025), so they're no longer a Terraform exclusive.

That last point matters more than it looks. Sentinel does not run on OpenTofu. If your policy-as-code strategy is built on Sentinel, that's a hard dependency on Terraform. If you're choosing OpenTofu — or want a policy engine that's portable across both — you'll reach for OPA/Conftest or Checkov instead; see policy as code with OPA, Sentinel, and Checkov for how those compare.

Licensing in Plain English

Most engineers don't read licenses until one bites them, so here's the practical version.

MPL 2.0 (OpenTofu) is a standard weak-copyleft open-source license. You can use it commercially, embed it, build hosted services on it, and redistribute it. No asterisks that affect normal use.

BSL 1.1 (Terraform) is source-available. In practice it restricts one thing: you can't take Terraform's source and use it to offer a competing commercial product or hosted service. For the overwhelming majority of end users — teams running terraform apply in their own CI to manage their own infrastructure — BSL changes nothing day to day. You can still use Terraform at work, for free, in production.

So why did the BSL spook the ecosystem so badly? Two reasons. First, it was a unilateral, retroactive-feeling change to a tool people had standardized on precisely because it was open. Second, the vagueness of "competing offering" creates ambiguity for the tooling ecosystem — CI platforms, wrappers, and vendors — and nobody likes building on a foundation whose license terms can shift again. The fear wasn't "I'll get sued for running terraform apply." It was "the guarantees I assumed about this tool no longer hold."

If licensing and vendor lock-in are on your mind more broadly, the same tensions show up in Terraform vs Pulumi and Terraform vs CloudFormation.

What Migration Actually Costs

Because OpenTofu is state-compatible and speaks HCL, a migration is usually far smaller than teams fear — but it isn't zero.

The mechanical switch:

1# Install the tofu CLI (Homebrew shown; packages exist for apt/yum/etc.)
2brew install opentofu
3
4# In an existing Terraform project, initialize with OpenTofu
5tofu init
6
7# Review the plan against your existing state — expect no changes
8tofu plan

What you actually need to touch:

• The CLI everywhere. Every terraform invocation in scripts, Makefiles, and docs becomes tofu.
• CI/CD. Swap the setup step (e.g. setup-terraform for the OpenTofu equivalent), and re-point any pinned binaries and caches.
• Registry references. Providers and modules resolve against registry.opentofu.org. The common ones mirror fine, but verify anything niche or private.
• HCP/Terraform Cloud features you'd lose. If you rely on HCP Terraform's remote execution, private registry, Sentinel policy sets, or Stacks, those don't come with you. You'd move to a third-party platform (Spacelift, Scalr, env0) or self-managed runners plus OPA/Checkov.

1# .tofu overrides let you fork behavior for OpenTofu only, without
2# disturbing the shared .tf that Terraform still reads.
3# backend.tofu  (ignored by terraform, applied by tofu)
4terraform {
5  encryption {
6    key_provider "pbkdf2" "state" {
7      passphrase = var.state_passphrase
8    }
9    method "aes_gcm" "encrypted" {
10      keys = key_provider.pbkdf2.state
11    }
12    state {
13      method   = method.aes_gcm.encrypted
14      enforced = true
15    }
16  }
17}

The realistic cost for a mid-size setup is measured in hours to a couple of days, dominated by CI plumbing and validating that every provider resolves — not by rewriting configuration. The bigger cost is organizational: if you're deeply wired into HCP Terraform, you're not just changing a CLI, you're changing platforms.

Which Should You Use?

There's no universal winner here, and anyone telling you there is has picked a side. Segment by situation.

Choose OpenTofu if:

1. You're greenfield and self-managed. Starting fresh in 2026 with your own CI and state backends? OpenTofu is open-governed, feature-competitive, and free of the licensing overhang. Reach for it by default.
2. You're wary of the BSL or single-vendor direction. If a unilateral license change or concentrated corporate control is a real risk in your threat model, a Linux Foundation project with a steering committee is the answer to that specific concern.
3. You need client-side state encryption or want to avoid paid tiers and telemetry. These are concrete OpenTofu advantages with no Terraform equivalent.

Choose Terraform if:

1. You're already invested in HCP Terraform / Terraform Cloud. Remote execution, private registry, run tasks, and the surrounding workflow are real value you'd have to rebuild elsewhere.
2. You want Stacks, enterprise support with an SLA, or the deepest provider-ecosystem coverage on day one of a new provider release.
3. Your policy-as-code is built on Sentinel. It doesn't run on OpenTofu, full stop.

My opinionated default: for a greenfield, self-managed IaC setup in 2026, OpenTofu is the safe pick. Open governance, an MPL license you don't have to think about again, and a feature set that's caught up to — and in places passed — Terraform. But this is not zealotry: if you're deep in the HashiCorp/HCP ecosystem, the pragmatic, lower-risk move is to stay on Terraform. The cost of leaving a platform you're wired into usually outweighs the philosophical win of an open license. Pick based on where you actually are, not where a Hacker News thread thinks you should be.

If you want the surrounding decisions — module design, state, and provider patterns that apply to both — see Terraform for EKS infrastructure as code and importing existing infrastructure into Terraform. Nearly all of it carries over verbatim to OpenTofu.

Frequently Asked Questions

Is OpenTofu a drop-in replacement for Terraform?

For migration purposes, effectively yes: OpenTofu uses the same HCL, reads existing Terraform state, and the tofu CLI mirrors the terraform workflow, so tofu init && tofu plan on an existing project typically shows no changes. But the two forks have diverged in features and behavior, and OpenTofu uses its own registry. Treat it as a near drop-in for switching, not as a permanently interchangeable clone — later releases of each tool have capabilities the other lacks.

Does the Terraform BSL license mean I have to stop using Terraform for free?

No. The Business Source License restricts using Terraform's source code to build a competing commercial or hosted offering. Running terraform apply in your own CI to manage your own infrastructure — the way virtually every team uses it — is unaffected and still free. What the BSL changed was the guarantee of openness, which is why it rattled the ecosystem even though it didn't restrict normal end-user usage.

Can I switch from Terraform to OpenTofu without rebuilding my infrastructure?

Yes. OpenTofu reads your existing Terraform state, so there's no re-provisioning — you point tofu at the same state and continue. The real work is plumbing: renaming terraform to tofu across scripts and CI, updating the CI setup step, and verifying every provider and module resolves against OpenTofu's registry. Budget hours to a couple of days for a mid-size setup, not a rewrite.

Does Sentinel work with OpenTofu?

No. Sentinel is HashiCorp's policy-as-code engine and is tied to the Terraform/HCP ecosystem; it does not run against OpenTofu. If you're on OpenTofu, or you want a policy engine that's portable across both tools, use OPA/Conftest or Checkov instead. See policy as code with OPA, Sentinel, and Checkov for the trade-offs.

Should I choose OpenTofu or Terraform for a new project in 2026?

For a greenfield, self-managed setup, OpenTofu is the safer default in 2026: open Linux Foundation governance, an MPL 2.0 license you don't need to reason about, no telemetry, and features like client-side state encryption. Stay on — or choose — Terraform if you're invested in HCP Terraform, need Stacks or enterprise support with an SLA, or depend on Sentinel. The deciding factor is your existing platform commitment, not the license alone.

Want the fast version? The Terraform vs OpenTofu side-by-side comparison distills this into a feature table you can scan in a minute. For the broader IaC picture, see Terraform vs Pulumi, Terraform vs CloudFormation, and the Kubernetes provider trap in Terraform — all of which apply equally whichever fork you land on.

OpenTofu's early variable evaluation also weakens one of the main reasons teams adopted wrapper tooling — see Terragrunt vs Terraform for what that changes.

Weighing an OpenTofu migration or standardizing your IaC toolchain? Talk to us at Coding Protocols — we help platform teams make the license, migration, and tooling call without betting the farm on a Hacker News thread.

Official References

• Terraform documentation — configuration language, state and provider behaviour
• Terraform state — remote backends, locking and drift