Terraform vs OpenTofu: which to use after the license change

TL;DR. In August 2023 HashiCorp relicensed Terraform from the open-source MPL 2.0 to the source-available BUSL 1.1 — usable free for most teams, but no longer open source, and off-limits for anyone building a competing product. The community forked the last MPL version into OpenTofu, now governed by the Linux Foundation. OpenTofu is a drop-in replacement: same HCL, same workflow, a tofu command, and state-file compatibility. For anyone whose whole point is owning their stack with no vendor lock-in — exactly the cloud-exit case — OpenTofu is the right default. Stay on Terraform only if you’re deep into HashiCorp’s paid platform (HCP Terraform, Stacks, Sentinel) and the switching cost outweighs the license risk.

What actually changed, and why it matters

For a decade Terraform was MPL 2.0 — genuinely open source. The 2023 change to the Business Source License (BUSL) 1.1 means:

• It’s source-available, not open source. You can read, run, and modify it for free for most uses.
• The non-compete clause forbids using it to build a product that competes with HashiCorp. That’s what triggered the fork — vendors and the community couldn’t build on it freely anymore.
• Each version converts to MPL after four years. Cold comfort if you want today’s code under an open license.

The practical risk to a normal business isn’t “you’ll get sued tomorrow” — it’s governance and direction. A tool that defines your entire infrastructure now sits under a single vendor that has shown it will change the terms when its business needs it. For a cloud-exit strategy built on removing single-vendor dependence, that’s the wrong foundation.

OpenTofu in one paragraph

OpenTofu is the fork of Terraform’s last MPL release, donated to and run by the Linux Foundation (backed by companies including Spacelift, Gruntwork, Harness, and others). It went GA as 1.6 in January 2024 and has shipped regularly since. It keeps the MPL 2.0 open-source license, the HCL language, the provider/module ecosystem (via its own registry), and a CLI you invoke as tofu. If you know Terraform, you already know OpenTofu.

Side by side

Mid-2026 — verify current versions before relying on specifics.

What OpenTofu does that Terraform doesn’t

The fork isn’t just “Terraform minus the license” — it has shipped features the community had asked for and not gotten:

• Client-side state encryption — encrypt your state file (which often holds secrets) at rest and in transit, natively. A real security win, especially when you self-host state.
• Provider and module for_each — dynamically expand providers/modules, long a top community request.
• Early variable / -exclude evaluation — more flexible planning, including excluding specific resources from a plan/apply.

For most teams these are nice-to-haves; state encryption is the one that genuinely matters if you store state yourself rather than in a managed backend.

How to migrate — usually an afternoon

OpenTofu is designed as a drop-in, and for the common case the switch is mechanical:

1. Install the tofu CLI alongside terraform (don’t delete Terraform yet).
2. Commit clean state. Run terraform plan first and make sure there’s no pending drift.
3. Swap the binary. tofu init reads your existing .tf files and state; for many projects that’s the whole migration. OpenTofu’s docs include a version-by-version migration guide for edge cases.
4. Update CI/CD and pre-commit hooks — replace terraform invocations with tofu.
5. Pin the provider registry if you relied on specific HashiCorp Registry behavior; OpenTofu’s registry mirrors the same providers.

Caveats worth checking before you commit: if you use HCP Terraform / Terraform Cloud, Sentinel policies, or features added to Terraform after the fork, those don’t map 1:1 — test in a branch. State written by a newer Terraform than the fork point can need care. For a standard HCL + providers + self-hosted-state setup, none of this applies and the switch is quick.

When to stay on Terraform (be honest)

OpenTofu isn’t automatically right for everyone:

• You’re invested in HCP Terraform / Terraform Cloud — Stacks, run management, and Sentinel policy-as-code are HashiCorp-platform features OpenTofu doesn’t replicate. If your org runs on them, the migration is real work.
• You need commercial vendor support / an enterprise contract with one throat to choke.
• You depend on a brand-new Terraform feature that hasn’t landed (or won’t) in OpenTofu.

If none of those bind you — and for most small and scale-up teams they don’t — the open license and open governance make OpenTofu the lower-risk default.

The bottom line for a cloud-exit stack

The entire point of leaving the hyperscalers (AWS, Azure, Google) is to stop being at the mercy of one vendor’s pricing and terms. Picking OpenTofu for your infrastructure-as-code is the same decision applied one layer up: an open-source, foundation-governed tool that can’t be relicensed out from under you, that still speaks HCL and runs your existing code. It’s the boring, portable choice — which is exactly what you want defining your infrastructure.

Choosing the IaC tool is the easy part of a migration — the hard part is the target design and the honest numbers. That’s what a Cloud-Exit Assessment delivers. Or send me your cloud bill for a free 24-hour teardown of where the money actually goes. Read by me, never shared.

Sources

• Terraform BUSL 1.1 relicense (Aug 2023, from MPL 2.0) — HashiCorp’s license-change announcement and the BUSL FAQ (hashicorp.com).
• OpenTofu — license (MPL 2.0), Linux Foundation governance, 1.6 GA (Jan 2024), tofu CLI, state encryption, provider for_each, -exclude, and the migration guide: opentofu.org (docs + blog).
• The OpenTofu Manifesto / fork backers — opentofu.org (formerly OpenTF).
• Related on this site: open-source equivalents for AWS managed services, CloudWatch cost alternatives.