Terraform vs OpenTofu: Differences, Licensing & How to Choose

For nearly a decade, "Infrastructure as Code on AWS" effectively meant Terraform. Then, in 2023, a license change split the road in two. Today you choose between Terraform — now under HashiCorp's Business Source License and part of IBM — and OpenTofu, the community fork stewarded by the Linux Foundation. They're close cousins, not strangers, but the differences matter more every release. This is the honest breakdown.

• Why the fork happened
• The license difference
• Compatibility today
• Where they've diverged
• How to choose
• Switching between them
• FAQ

Why the fork happened

For most of its life, Terraform was licensed under the Mozilla Public License 2.0 (MPL) — fully open source. In August 2023, HashiCorp relicensed Terraform to the Business Source License (BSL), a "source-available" license that restricts using the code to build a competing commercial product.

The change rattled the ecosystem, especially vendors and teams building tooling around Terraform. Within weeks the community published a manifesto, forked the last MPL-licensed code, and launched what became OpenTofu — donated to the Linux Foundation and kept under MPL 2.0. OpenTofu reached general availability in early 2024 and has shipped steadily since.

The split wasn't about technology. It was about licensing — and who controls the future of an open tool that a huge part of the industry depends on.

The license difference

• Terraform (BSL 1.1). Source-available. Free to use for the vast majority of teams — you can run it in production at any scale. The restriction targets building a competing commercial product with the source. Governed by HashiCorp (now part of IBM).
• OpenTofu (MPL 2.0). Fully open source under a neutral foundation (the Linux Foundation). No commercial-use restrictions; community governance.

For an ordinary team running infrastructure, the BSL does not stop you using Terraform. The license matters most if you build products on top of it, want a foundation-governed guarantee against future relicensing, or have a policy requiring OSI-approved open source.

Compatibility today

Because OpenTofu forked from Terraform 1.5, the two remain broadly interchangeable for everyday work:

• Same language. Both use HCL. Your .tf files generally work in either.
• Same providers. Both use the same provider plugin protocol, so the AWS, Azure, and GCP providers work across both.
• Same state format. State files are compatible, which is what makes switching feasible.
• Same core workflow. init, plan, apply, import — the muscle memory carries over (OpenTofu's binary is tofu).

# Terraform
terraform init && terraform plan

# OpenTofu — same workflow, different binary
tofu init && tofu plan

Where they've diverged

They are no longer identical, and the gap widens with each release. Notable OpenTofu-first additions have included client-side state encryption, early/variable evaluation improvements, and provider/module iteration features the community prioritised. Terraform, meanwhile, continues to integrate tightly with HashiCorp's commercial platform (HCP Terraform / Terraform Cloud) and has shipped its own higher-level constructs.

The practical takeaway: core, everyday HCL is portable; the newest, version-specific features are not guaranteed to exist in both. If you adopt a cutting-edge feature from one, you may pin yourself to it. Always check the docs for the specific tool and version you run.

How to choose

• Choose OpenTofu if you want a fully open-source, foundation-governed tool with no relicensing risk, you build tooling on top of it, or your organisation mandates OSI-approved licenses.
• Choose Terraform if you rely on HashiCorp's commercial platform and ecosystem, want vendor support, or simply prefer to stay on the original with the largest install base.
• Either is a safe default for codifying AWS today. The state and language compatibility means this is not a one-way door for most teams.

Switching between them

Many teams migrate Terraform → OpenTofu by installing the tofu binary, pointing it at the same configuration and state, and running a plan to confirm no changes. Test in a non-production workspace first, watch for any feature you use that's version-specific, and keep your state backed up. Because the state format is shared, the switch is usually undramatic — which is exactly the point of a compatible fork.

If you haven't codified your AWS account yet, you can sidestep the question entirely at the start: generate standard HCL that works with both, then pick your binary. That's how InfraSync approaches it — the Terraform it generates from your live AWS account is compatible with both Terraform and OpenTofu, so the tooling choice stays yours. See our guide to generating Terraform from AWS to get started.

FAQ

Is OpenTofu a drop-in replacement for Terraform?

For most projects, yes. OpenTofu was forked from Terraform 1.5 and remains broadly compatible with the same HCL, providers, modules, and state format, so many teams switch by changing the binary. As the projects diverge, very new version-specific features from one may not exist in the other.

Why was OpenTofu created?

In August 2023, HashiCorp changed Terraform's license from the open-source MPL 2.0 to the Business Source License (BSL), which restricts certain competing commercial uses. In response, the community forked the last MPL-licensed version and created OpenTofu, now stewarded by the Linux Foundation under MPL 2.0.

Does OpenTofu use the same providers as Terraform?

Yes. OpenTofu uses the same provider plugin protocol and the same providers (such as the AWS provider). It maintains its own registry, but the provider plugins themselves are shared, so AWS, Azure, GCP, and others work across both.

Can InfraSync generate OpenTofu-compatible code?

Yes. InfraSync generates standard HCL compatible with both Terraform and OpenTofu, so you can adopt either tool without changing how you codify your AWS account.