OpenTofu vs Terraform: the fork, the license, and the real differences

TL;DR

OpenTofu and Terraform are closely related: OpenTofu is a 2023 fork of Terraform 1.5.5, so they share HCL, the provider model, and the init / plan / apply / destroy workflow. The divergence is now real, but it is mostly about who controls the project and a handful of features rather than a different way of working.

• Choose OpenTofu if you want a genuinely open-source license (MPL 2.0), neutral foundation governance, native state encryption, and no vendor lock-in.
• Choose Terraform if you depend on HashiCorp's commercial platform (HCP Terraform / Terraform Enterprise), need first-party enterprise support, or your toolchain and vendors standardize on the HashiCorp ecosystem.

OpenTofu vs Terraform at a glance

Dimension	OpenTofu	Terraform
License	MPL 2.0 (open source, OSI-approved)	Business Source License 1.1 (source-available)
Governance	Linux Foundation, community steering	HashiCorp (an IBM company)
Origin	Fork of Terraform 1.5.5 (2023)	Original project, since 2014
Language / workflow	HCL, init/plan/apply/destroy	HCL, init/plan/apply/destroy
State compatibility	Compatible with Terraform 1.5.x state	Compatible with OpenTofu state (pre-encryption)
Native state encryption	Yes, client-side AES-GCM	No (relies on backend encryption)
Provider/module registry	OpenTofu Registry + public mirrors	Terraform Registry
Commercial platform	Third-party (Spacelift, Scalr, Env0, etc.)	HCP Terraform / Terraform Enterprise (first-party)
Cost	Free	Free CLI; paid HCP/Enterprise tiers

Architecture and compatibility

Because OpenTofu started as a line-for-line fork, the two tools share the same architecture: a CLI that parses HCL, builds a dependency graph, talks to providers over the plugin protocol, and reconciles a state file against real infrastructure. If you already know Terraform, you already know OpenTofu. The commands match, the directory layout matches, and the same provider binaries (AWS, Google, Azure, Kubernetes, and thousands of others) work in both.

State files are the key practical point. OpenTofu state uses the same format as Terraform 1.5.x and works in both directions, which is what makes migration so low-friction. There is one important asymmetry: once you turn on OpenTofu's native state encryption, those state files are no longer readable by Terraform. This is by design, so treat enabling encryption as the point where you commit to OpenTofu for that workspace (unless you decrypt the state again).

The other source of friction is version drift. The fork point was 1.5.5, and both projects have released many versions since. Each has added language features the other does not have. Code written against newer Terraform-only syntax may need small adjustments to run on OpenTofu, and vice versa. For the vast majority of modules this is a non-issue, but it is why "drop-in replacement" is true for most projects, not guaranteed for all.

License and governance

This is the reason the fork exists. In August 2023 HashiCorp relicensed Terraform from MPL 2.0 to the Business Source License. BSL is source-available: you can read the code and use it for almost anything internally, including production, but you cannot offer Terraform as a competing managed service. That restriction mostly targets vendors, yet it was enough to push a large part of the community to create OpenTofu, which kept the MPL 2.0 license and moved governance to the Linux Foundation.

For an individual engineer or a typical company, both tools are free to use day to day. The governance difference is more strategic than tactical. OpenTofu's roadmap is decided in the open by a steering committee and the community; Terraform's is set by HashiCorp, now part of IBM, and is tightly aligned with its commercial products. If foundation-neutral stewardship and protection against future relicensing matter to your procurement or open-source policy, that weighs toward OpenTofu. If a single accountable commercial vendor with paid support is what your organization prefers, that weighs toward Terraform.

Features and ecosystem

The feature sets have started to diverge in ways that can actually decide a project. OpenTofu added client-side state and plan encryption (AES-GCM, key supplied via environment variable or a key management service, so it works well with CI/CD and secret managers), provider iteration with for_each, early variable evaluation that lets you configure backends dynamically, and an -exclude flag to apply everything except a chosen resource. Native state encryption in particular is a meaningful security win, because Terraform state holds secrets in plaintext and the usual answer is "encrypt the backend" rather than the data itself.

Terraform's advantages are concentrated in its ecosystem and commercial surface. The Terraform Registry is the most established place to publish and discover modules and providers, HashiCorp ships first-party HCP Terraform and Terraform Enterprise for remote state, policy as code (Sentinel), and run management, and many third-party tools and certifications still center on Terraform by default. OpenTofu's ecosystem is healthy and growing, with strong support from platforms like Spacelift, Scalr, and Env0, but Terraform's longer history still gives it an advantage when you need a vendor relationship or ready-made integrations.

Which should you choose?

For new projects with no commercial-platform requirement, OpenTofu is the safe default: it is truly open source, foundation-governed, fully compatible with the providers you already use, and ahead on a few genuinely useful features like state encryption. The licensing and lock-in risk is lower, and migrating later costs little.

Choose OpenTofu if you value an OSI-approved open-source license and neutral governance, you want native client-side state encryption, you rely on third-party automation platforms, or you simply want to avoid depending on a single vendor's roadmap for your IaC layer.

Choose Terraform if you are already invested in HCP Terraform or Terraform Enterprise, you need first-party enterprise support and SLAs, your vendors and integrations assume Terraform, or organizational policy favors a commercial owner over a foundation. In that case the BSL terms almost certainly do not affect your internal use, and staying with Terraform avoids unnecessary migration work.

Either way, the cost of a wrong choice is low. The two tools remain close enough that switching is a binary swap and a state check for most teams, so pick the one that matches your governance and platform needs today, and re-evaluate as the projects continue to diverge.