OpenTofu and the Terraform licence split

A governance story that became a technical decision. Worth knowing for the same reason as the Redis/Valkey split — it tests whether you follow the ecosystem.

What happened

In August 2023 HashiCorp relicensed Terraform from MPL 2.0 (open source) to the Business Source License 1.1 — source-available, with a restriction on offering competing commercial products.

The response was fast: the Linux Foundation forked the last MPL-licensed version as OpenTofu, backed by Gruntwork, Spacelift, env0, Harness and others. IBM then acquired HashiCorp, completed in 2025, which did not reverse the licensing decision.

Same shape as Redis → Valkey: a licence change that primarily targets vendors, answered with a foundation-governed fork. See ../../09_caching/valkey/01_valkey.md.

What it means for you

If you use Terraform to manage your own infrastructure, the BSL does not restrict you. The restriction targets companies building competing Terraform-based commercial offerings. Most teams are unaffected in practice.

The reasons to care anyway:

• Provider ecosystem. The registry and provider licensing have been a friction point; OpenTofu maintains its own registry.
• Vendor risk. A licence that changed once can change again. Some organisations have a policy against BSL dependencies.
• Feature divergence. They’re no longer the same tool.

Where they’ve diverged

OpenTofu shipped features Terraform hasn’t:

State encryption is the substantive one. Terraform state contains secrets in plaintext — database passwords, generated keys, anything a resource returns. Backend-level encryption (S3 SSE) protects it at rest in storage but not from anyone with read access to the bucket. OpenTofu encrypts client-side, so the state is opaque even to the backend.

That’s a real security improvement and the strongest technical argument for OpenTofu. See 01_terraform_state.md.

Terraform meanwhile has its own additions (stacks, enhanced testing) and the commercial HCP Terraform platform.

Migrating

For most codebases it’s close to a drop-in:

# OpenTofu reads .tf files and existing state
tofu init
tofu plan

Same HCL, same state format, same providers. The friction points are: modules pinned to the Terraform registry, required_version constraints, CI images and tooling that shell out to terraform, and any Terraform Cloud/HCP integration.

Migrate for a policy reason or a specific feature, not for its own sake. A working Terraform setup does not need to move.

Interview angle

• “What’s OpenTofu?” — a Linux Foundation fork of Terraform created after HashiCorp moved from MPL 2.0 to the Business Source License in 2023. Backed by several infrastructure vendors; HashiCorp was subsequently acquired by IBM without reversing the change.
• “Does the licence affect you?” — not if you’re managing your own infrastructure. The BSL restricts offering competing commercial products built on Terraform. The practical concerns are provider ecosystem, policy positions on BSL dependencies, and the fact that a licence which changed once can change again.
• “Have they diverged technically?” — yes. OpenTofu added client-side state encryption, early variable evaluation in backend and module-source blocks, and provider for_each. Terraform has pursued stacks and its commercial platform.
• “Why does state encryption matter?” — Terraform state stores secrets in plaintext. Backend encryption protects it at rest in the bucket but not from anyone who can read the bucket. Client-side encryption keeps it opaque to the storage layer entirely.
• “Would you migrate an existing setup?” — only for a policy requirement or a specific feature like state encryption. It’s largely drop-in — same HCL, state format and providers — but registry pins, version constraints and CI tooling all need touching, and a working setup is not a problem to solve.