A Fork Does Not Fix Your Infrastructure Governance

OpenTofu is now a CNCF sandbox project (opens in a new tab). That settles the question the fork was created to answer: whether a vendor could change the terms under a tool your platform depends on.

It does not settle the question that actually decides whether your infrastructure is governed, which is who can change production and what evidence exists afterward. That question lives in the state file, the plan review and the apply permission. A license change never touched any of them.

Sandbox status is also worth reading precisely. It is the entry stage in the CNCF, a statement that the project is part of the foundation and not yet a statement about maturity. Neutrality is now a commitment rather than a track record.

What the license change actually threatened

When HashiCorp moved Terraform to the Business Source License in August 2023, the risk was not that the tool would stop working. The risk was commercial: a vendor could restrict what you build on top of it, and a platform team that had built internal tooling around Terraform's plugin interfaces had a dependency they could not renegotiate.

The fork answered that. A community fork under a foundation, with an open license, is the standard insurance policy against a single-vendor terms change, and it worked here.

Insurance is the right word, though. You buy it against a risk, and it does not otherwise change how you operate.

Where infrastructure governance actually lives

Infrastructure as code is the most honest artifact in most IT organizations. It records what exists, what changed, and who approved the change. That record is the governance, and it has four parts that a license cannot touch.

The state file. It holds the mapping between your configuration and real resources. It is also the thing that determines whether a migration is a weekend or a quarter. If your state is remote, shared and locked, you have options. If it lives on an engineer's laptop, you have an incident waiting.

The plan. A plan is a diff against reality, and reviewing it is the last chance to catch a change that will delete a database. A pipeline that applies without a human-readable plan is not infrastructure as code. It is scripted infrastructure with a YAML theme.

The apply authority. Who can run an apply against production, under what identity, and is that identity separate from the one that writes the code? This is the control an auditor will ask about, and it is the one most teams answer with "the CI service account," which is not an answer.

The record. Every apply should leave an entry: the commit, the plan hash, the approver, the result. Without it you can rebuild the infrastructure and not the decision.

A fork changes who maintains the tool. It does not change who can delete your database.

What a migration costs, and what it does not buy

Moving from Terraform to OpenTofu is usually cheaper than teams expect at the syntax level and more expensive than they expect at the edges. The HCL is largely compatible. The state can be migrated. The trouble is in the parts that are not the language:

• Providers that lag the fork's releases, or that only test against the vendor's runtime
• Internal modules that encode assumptions about provider behavior
• CI images, policy engines and drift detection built against one binary
• The institutional knowledge of the two engineers who understand the pipeline

None of those are reasons not to migrate. They are reasons to treat the migration as a platform change with a rollback plan rather than a dependency bump.

The strategic question is not which binary you run. It is whether your modules are portable and your state is under control. A team with clean state and versioned modules can move in weeks. A team without them will discover the problem during the migration, which is the worst time.

The federal version

For a federal program, the license argument is a supply chain argument, and supply chain arguments need evidence rather than preference.

Three things belong in the file, whichever tool you choose.

1. Provenance of the binary. Which release, from where, verified how. An IaC tool that can rewrite your infrastructure is a privileged component, and its provenance is part of your authorization boundary.
2. Separation of duties. The person who writes the change is not the person who approves the apply, and neither is the service account that executes it. This is the control that turns infrastructure as code into an auditable process.
3. Reproducibility. Given a commit and a state version, can you produce the same plan six months later? If provider versions float, the answer is no.

The CNCF move helps with the first item. It does nothing for the second and third, and those are the ones an assessor will test.

What to do with the news

If you are on Terraform and your license risk is acceptable, stay. The fork is insurance, and you do not have to make a claim to benefit from holding the policy.

If you are migrating, migrate because your modules are portable and your state is under control, not because the foundation announcement made you nervous. And use the migration to fix the two things that were already broken: the apply authority and the record.

The tool was never the control. The pipeline was, and it is still yours to design.