OpenTofu vs. Terraform: Which IaC Tool Really Delivers
License change and IBM acquisition have turned OpenTofu into a serious Terraform fork.
Since Terraform switched to a more restrictive license and HashiCorp became part of IBM, every team relying on Terraform code must seriously consider OpenTofu: open-source under MPL 2.0, backed by the Linux Foundation. By 2026, the focus won’t be on a universally “better” tool, but on aligning operations, compliance, and supply chains.
Key Takeaways
- The license is the trigger, not a feature: Terraform has been under the Business Source License since version 1.6, while OpenTofu uses MPL 2.0 under the Linux Foundation. For the vast majority of existing configurations, the switch is a simple binary swap.
- By 2026 the tools diverge: OpenTofu offers native state encryption and provider-defined functions, whereas Terraform introduces ephemeral values and HCP stacks. HCL syntax and state format remain on par.
- The DACH decision is about governance, not CLI: NIS2 supply-chain rules, DORA third-party risk, and vendor concentration often outweigh a single command-line feature.
Related:AI sovereignty starts with infrastructure / Cloud-native matures with Kubernetes 1.34
Why a license change became an architecture question
In August 2023, HashiCorp moved Terraform’s license from the Mozilla Public License to the Business Source License. The BSL bars direct competition with HashiCorp’s own products and only converts to true open source four years after each release. To end users this initially looks like a footnote, but for anyone embedding Terraform in a product, platform, or managed service, it introduces legal risk.
The response was swift. A coalition of vendors and the community forked Terraform 1.5-the last MPL release-into OpenTF, which became OpenTofu under the Linux Foundation in September 2023 and joined the CNCF in April 2025. At the same time, IBM completed its acquisition of HashiCorp for roughly €5.9 billion in late 2024. Today Terraform sits under a single large vendor, while OpenTofu operates under a multi-party foundation. For teams bound by governance mandates, that governance model is now a decisive factor.
What is OpenTofu? OpenTofu is an open-source fork of Terraform under MPL 2.0, split from the last permissively licensed Terraform version. It is governed by a Technical Steering Committee within the Linux Foundation; no single company controls the roadmap. The CLI, HCL language, and state format remain largely compatible with Terraform.
Where OpenTofu and Terraform Diverge
Until 2025, OpenTofu could primarily be described as a license-clean alternative to Terraform. Since then, the projects have diverged functionally. Both now release their own versions on independent schedules, and their feature sets are drifting apart. OpenTofu is currently at version 1.9, Terraform at 1.14. When making a choice, weigh it against concrete features, licensing implications, and operational dependencies.
The most significant difference is state encryption. OpenTofu encrypts state and plan files client-side before they leave the machine, optionally against a KMS provider. Terraform traditionally leaves this to the backend-such as server-side encryption in an S3 bucket. If you handle regulated data in state, OpenTofu adds an extra layer of protection. That matters because secrets often end up in state more often than planned. Additional distinctions include provider-defined functions and earlier variable evaluation in OpenTofu, while Terraform emphasizes ephemeral values and tight integration with HCP Stacks.
| Criteria | OpenTofu | Terraform |
|---|---|---|
| License | MPL 2.0, OSI-approved | BSL 1.1, not OSI-approved |
| Governance | Linux Foundation, multi-party | IBM / HashiCorp, single-vendor |
| State Encryption | native, client-side | via backend |
| Distinct Strengths | provider-defined functions, earlier variable evaluation | ephemeral values, HCP Stacks |
| HCL and State Format | compatible | reference |
The table highlights the dividing line: OpenTofu leans toward openness and state security, Terraform toward its own cloud platform. No blanket recommendation emerges. If you don’t use HCP Stacks, switching won’t cost you any functionality. If you do, you first need to untangle that dependency.
Migration: what the switch actually costs
Technically, the migration is usually straightforward. State format, HCL and the provider protocol are compatible; in many existing setups you only need to swap the binary. Commands change from terraform init to tofu init, while most workflows remain the same. The real risk isn’t in the code-it’s at the edges: dependencies on Terraform Cloud, HCP Stacks or in-house wrappers that are hard-wired to the HashiCorp stack.
If you’re migrating, don’t flip the entire estate at once. Start with one module, then one state, and always run a clean plan-diff before and after the swap. This staged approach keeps a seemingly small tool change from turning into a production headache. Cost is rarely the driver; both tools are open-source, so the bill comes from the surrounding platforms and integrations.
Why switch
- License clarity for products and managed services
- Native state encryption without a backend detour
- Multi-party governance instead of a single-vendor roadmap
Why stay
- HCP Stacks lock-in must be unwound first
- Procurement that explicitly names HashiCorp as the vendor
- Toolchain with hard-coded Terraform assumptions
The DACH decision: NIS2, DORA and the supply chain
In the DACH region the question is shifting from technology to governance. NIS2 demands documented due diligence across the software supply chain, while DORA-targeted at the financial sector-addresses third-party risk and explicitly tackles concentration risk at ICT service providers. In this context, an infrastructure tool under foundation control, open-source and without a single commercial owner, is easier to defend in an audit than a product whose license and roadmap are tied to one vendor.
That doesn’t mean OpenTofu is automatically the compliance-friendly choice; it means the license and control question lands on the table in any NIS2 or DORA audit and must be answered. Market momentum is still measured: roughly 12 percent of IaC practitioners already use OpenTofu in 2026, and about another quarter are evaluating or expanding its use. It’s no landslide, but a steady drift in one direction.
Conversely, there are clear reasons to stay with Terraform. If you rely on HCP Stacks, operate in an IBM Cloud Pak environment or have procurement rules that explicitly mandate HashiCorp as the vendor, Terraform remains the more direct path. The decision isn’t a matter of faith; it’s a balance of license risk, supply-chain governance and concrete platform dependencies-and the outcome varies from one organization to the next.
Frequently Asked Questions
Can Terraform be replaced by OpenTofu without any modifications?
For the vast majority of configurations, yes. The state format, HCL syntax, and provider protocol are compatible; in practice, simply swapping the binary is usually sufficient. Friction arises from dependencies on Terraform Cloud, HCP Stacks, or in-house wrappers. A module-by-module migration with plan diffs before and after the switch catches edge cases.
What exactly happened to the Terraform license?
In August 2023, HashiCorp transitioned Terraform from MPL 2.0 to the Business Source License 1.1. The BSL restricts usage in competition with HashiCorp’s products and only reverts to free open source four years after each release. This was the catalyst for the OpenTofu fork.
Which features does OpenTofu offer that Terraform lacks?
Most visibly, native client-side encryption of state and plan files. It also adds provider-defined functions and earlier variable evaluation. Terraform, in turn, offers its own features like ephemeral values and tight HCP Stacks integration. Core syntax remains identical on both sides.
When is Terraform the better choice?
When operations rely on HCP Stacks, run in an IBM Cloud Pak environment, or vendor procurement mandates HashiCorp. In these scenarios, switching creates more overhead than it saves in licensing and governance benefits.
What does the choice mean for NIS2 and DORA compliance?
NIS2 requires documented due diligence over the software supply chain; DORA addresses third-party and concentration risks in ICT services. A fully open-source tool under foundation governance is easier to justify in an audit than a single-vendor product. The question must be answered in both cases, regardless of the chosen tool.
Image source: AI-generated cover image (June 2026), C2PA certificate embedded
