HashiCorp relicensed Terraform and a community fork spun up overnight. Here's how OpenTofu actually differs and which one your team should run.
Terraform vs OpenTofu — Which to Choose After the License Change
In August 2023 HashiCorp switched Terraform from the Mozilla Public License to the Business Source License (BSL). The practical worry wasn't for teams writing infrastructure code, it was for anyone building products around Terraform: CI runners, wrappers, cost tools, TACOS platforms. The BSL says you can't use the software in something that competes with HashiCorp's commercial offerings. That vagueness was enough to make a lot of vendors nervous, and within weeks a fork appeared. It's now called OpenTofu, it lives under the Linux Foundation, and it kept the old MPL license.
Two and a half years later this is a real decision, not a protest vote. Here's what actually differs and how to pick.
The BSL change didn't ban internal use. If your company runs terraform apply to manage its own AWS account, nothing about that is restricted. The friction was for companies whose product is Terraform automation. Spacelift, env0, Scalr, and similar platforms suddenly had a license a lawyer could read as hostile. Rather than negotiate individually with HashiCorp, a group of them backed a fork, seeded it with engineering time, and handed governance to the Linux Foundation so no single vendor controls it.
The upshot: OpenTofu is MPL 2.0, community-governed, and free in the sense Terraform used to be. Terraform is still free to download and run, just under a license with strings that matter to a specific slice of users.
OpenTofu is a fork of Terraform 1.5.x, the last MPL release. Early versions were close to identical. The CLI is tofu instead of terraform, it reads the same .tf files, uses the same HCL, and speaks the same provider protocol. If you handed an OpenTofu-managed codebase to someone who only knew Terraform, they wouldn't notice for a while.
It uses providers and modules from its own registry at registry.opentofu.org, which mirrors the vast majority of what's on the HashiCorp registry. The AWS, Google, Azure, Kubernetes, and Helm providers are all there and current.
For everyday configs, migration is genuinely boring, which is the highest compliment you can pay a migration. State files are compatible. The commands map one to one:
# Before, with Terraform
terraform init
terraform plan -out=tfplan
terraform apply tfplan
# After, with OpenTofu: same workflow, different binary
tofu init
tofu plan -out=tfplan
tofu apply tfplan
The honest caveat is version drift. OpenTofu forked at 1.5 and Terraform has kept shipping. Features added to Terraform after the fork (some newer for_each behaviors, certain built-in functions, provider-defined functions timing) landed on different schedules in each project. In practice most teams pin a provider and module set that works on both, but if you rely on a bleeding-edge Terraform-only function, check it before you switch.
A realistic migration for an existing project looks like this:
# 1. Install OpenTofu (Homebrew shown; packages exist for apt, yum, Windows)
brew install opentofu
# 2. From your project root, initialize with the tofu binary.
# It reads your existing .terraform.lock.hcl and backend config.
tofu init
# 3. Confirm no drift: this should show zero changes on a clean repo
tofu plan
# 4. If your state lives in S3/GCS/Azure/Terraform Cloud remote backend,
# nothing moves. OpenTofu reads the same remote state.
tofu state list
The tofu plan producing an empty diff is the signal that you're safe. Point your CI pipeline's binary at tofu, keep the same backend, and you're done. Teams running Atlantis, Spacelift, or GitHub Actions typically change one line: the tool name.
The projects have diverged enough that OpenTofu now has features Terraform doesn't, and vice versa.
State encryption: OpenTofu added client-side state and plan encryption natively. You configure it in the terraform block and it encrypts state before it hits the backend, using AWS KMS, GCP KMS, or a PBKDF2 passphrase. Terraform relies on backend-level encryption (S3 SSE, for example) instead of encrypting the file itself.
terraform {
encryption {
key_provider "aws_kms" "primary" {
kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abc-123"
region = "us-east-1"
key_spec = "AES_256"
}
method "aes_gcm" "default" {
keys = key_provider.aws_kms.primary
}
state {
method = method.aes_gcm.default
}
}
}
Provider registry: OpenTofu runs its own registry with a different signing and submission model, so a handful of niche providers show up in one but not the other on any given week. For the mainstream providers this is a non-issue.
Terraform Stacks and Terraform Cloud features: HashiCorp ships commercial features (Stacks, the newer policy tooling in HCP Terraform) that OpenTofu doesn't have and won't, because they're proprietary. If your workflow depends on HCP Terraform, that's a Terraform-side lock-in worth naming.
Tooling support is effectively at parity now. tfsec, Checkov, Terrascan, Infracost, and terraform-docs all understand OpenTofu configs because it's the same HCL. The Terraform VS Code language server works against both. Pre-commit hooks need a one-word swap. The tflint linter runs against either. Documentation-wise you'll still lean on the Terraform registry docs for provider arguments, since the schemas match.
For related tradeoffs against a different tool entirely, see our Terraform vs Pulumi breakdown, and the broader best Infrastructure-as-Code tools roundup.
Pick OpenTofu if you want a permissively licensed tool with no BSL ambiguity, you value community governance under a neutral foundation, you're building a product or internal platform on top of the binary, or you want native state encryption without wiring up backend-specific tricks.
Pick Terraform if you're committed to HCP Terraform's commercial features, you need a specific post-fork Terraform function today, or your organization's procurement and support processes are built around a HashiCorp (now IBM) contract and that vendor relationship is worth more to you than license purity.
For the large middle ground running self-managed state in S3 or GCS with mainstream providers, either works, and the choice comes down to license preference.
For a new project with no HCP Terraform dependency, start on OpenTofu. The license is cleaner, the governance is harder to yank out from under you, and the migration cost if you ever need to reverse is close to zero because the formats stay compatible. For an existing Terraform shop that isn't using commercial HashiCorp features, plan the switch as a low-drama one-sprint task: swap the binary in CI, run tofu plan, confirm the empty diff, and move on. The only teams that should stay put without a second thought are the ones genuinely using HCP Terraform Stacks or its paid policy tooling, where the fork simply doesn't play.
