OpenTofu: The Open Response to Terraform’s License Change

javi
Placa con cables y circuitos representando infraestructura

On 20 September 2023, a coalition of companies and developers announced the OpenTF Manifesto, committing to maintain an open fork of Terraform after HashiCorp’s switch to the Business Source License (BSL). In the following weeks the project was renamed to OpenTofu, accepted by the Linux Foundation, and shipped its first alpha release.

If you manage infrastructure with Terraform, this story matters: it defines which tool you’ll use the next few years and under what legal terms.

Context: What Happened With Terraform

In August 2023, HashiCorp announced that its entire product suite (Terraform, Vault, Consul, Nomad, Packer) was switching from the Mozilla Public License v2 (MPL 2.0, OSI-approved) to the Business Source License v1.1.

BSL is not strictly “closed source”, but it imposes a key restriction: you can’t offer a competing product based on the code. For HashiCorp, “competitor” is broadly defined — it affects Spacelift, env0, Terraform Cloud alternatives, and potentially companies offering managed services. After 4 years, the code reverts to MPL.

For end users only applying Terraform to their infrastructure, the change has no immediate impact. For the ecosystem (service providers, tools orbiting Terraform, enterprise integrations), the change was perceived as breaking the implicit open-source contract.

OpenTofu’s Birth

After 6 weeks of public organisation on GitHub under the OpenTF name, the project was:

  • Forked from the last MPL commit of Terraform (version 1.5.5).
  • Renamed to OpenTofu to avoid Terraform brand conflicts.
  • Accepted as a Linux Foundation project in September 2023, ensuring neutral governance.
  • Backed by companies like Spacelift, Gruntwork, env0, Harness, Scalr, and dozens more with engineering commitments.

The first alpha appeared a few weeks after the fork. By 2024, full stabilisation with functional parity to the last MPL Terraform version is expected.

Compatibility

OpenTofu maintains file compatibility with existing Terraform configurations. Your .tf, .tfstate, and .tfvars files work without modification. The tofu binary replaces terraform in commands:

tofu init
tofu plan
tofu apply

The providers (AWS, Azure, GCP, Cloudflare, etc.) are the same — provider licences don’t change, only the Terraform core. OpenTofu can consume any provider from the Terraform Registry.

In the medium term, some divergence is expected: OpenTofu will add features the community requests but HashiCorp didn’t prioritise. That divergence will be incremental, not disruptive.

The Practical Question: Migrate?

Depends on your situation.

Migrate to OpenTofu if:

  • Your organisation has strict open-source licence policies (regulated sectors, public bodies).
  • You build products or services on Terraform where BSL could apply to you as “competitor”.
  • You’re part of the ecosystem (tool provider, consultancy) and governance neutrality matters.
  • You want to bet on the community trajectory long-term.

Stick with Terraform if:

  • You only use it internally to manage your own infrastructure.
  • You depend on Terraform Cloud or HashiCorp-specific integrations.
  • You have active enterprise contracts with HashiCorp.
  • You prefer waiting for OpenTofu to reach proven stability before adopting.

For teams that decide to migrate, a gradual approach reduces risk:

  1. Validate in an isolated environment. Test tofu init/plan/apply against a test environment, verify state reads correctly and plans are identical.
  2. Run in parallel. In CI, compare terraform plan and tofu plan output to detect differences before switching.
  3. Migrate pipeline by pipeline. No need to change everything day one. OpenTofu and Terraform can coexist while plans match.
  4. Update surrounding tools. Atlantis, Terragrunt, and similar are adding explicit OpenTofu support.

Long-term Implications

This change has a broader reading. It’s the second major open-source license break in 2023 (Elastic with Elasticsearch, Redis hadn’t announced its change yet at this point). It reinforces the thesis that neutral foundations (Linux Foundation, CNCF) protect the continuity of infrastructural projects better than the individual companies that started them.

For the next critical-infrastructure project you adopt, it’s worth asking: who “owns” the code and what incentives do they have? The answer matters.

Conclusion

OpenTofu is the predictable and well-organised community response to a license change many considered unilateral. It’s a viable option today and very likely dominant medium-term in the IaC space. Compatibility with existing Terraform drastically reduces switching cost. For most organisations, the decision isn’t urgent — but it’s worth making it informed.

Follow us on jacar.es for more on Infrastructure as Code and open-source ecosystem evolution.

Entradas relacionadas