In September I wrote about the licence change and the fork and ended on a deliberately unsatisfying note: OpenTofu at that point was a governance structure, a foundation home, a great deal of goodwill and no release. Choosing it meant choosing a promise.

On the tenth of January the promise shipped. OpenTofu 1.6 is generally available under the Linux Foundation, built by several dozen developers in four months, and declared production-ready.

So: does that change my answer?

What was never really in doubt

That the binary would work.

Forking a mature codebase and keeping it running is a known quantity of engineering. The people doing it were already familiar with the code, the test suite came with it, and four months is a reasonable timescale for that work. It was going to compile and it was going to plan and apply.

What I said in September was that the value was never in the CLI — it is in the providers, the modules, the registries, and the fact that terraform is what the documentation of every other product tells you to run. A working fork is the necessary part of the answer and not the interesting part.

What actually matters now

Providers were never the problem. They stayed MPL, which was the detail most of the original panic skipped, and a fork reads them the same way.

Registries are where the real question sat, because a provider being openly licensed is not the same as there being a place to fetch it from that a given tool is allowed to use. OpenTofu shipping a GA release means it has had to answer that for itself, and how well that answer holds up under the weight of real usage is the thing I would watch over the next year rather than the next week.

The other thing that matters is boring and decisive: state file compatibility. The state is JSON, both tools understand it, and 1.6 tracks Terraform's 1.6-era behaviour. That is what makes this a reversible decision rather than a migration — and reversibility is most of what I want from an infrastructure tool choice.

What I am doing

Still nothing dramatic, which I recognise is an unexciting second post in a row on this subject.

The pinned version in CI remains the mitigation it always was. Nothing about my position changed in January except that the alternative went from hypothetical to real, which improves my options without creating an obligation to use them.

What I would do differently now is stop treating this as one decision. There are two, and they have different answers. Whether an existing estate should move is a question about risk, and the honest answer is that a working pipeline is worth more than a tidier licence. Whether a new project should start on one or the other is a much cheaper question, because there is no migration, and there the licence is a real input rather than a theoretical one.

The part worth keeping

The thing I will remember about this whole episode is how quickly the ecosystem demonstrated that it could route around a licence.

Five months from relicensing to a production-ready fork under a neutral foundation is fast. Not because forking is easy, but because the conditions for it were already in place: the code was open at the time it was taken, the providers were separately licensed, the state format was documented, and enough organisations had a concrete commercial reason to fund the work.

That combination is not guaranteed anywhere else. It is worth noticing which of those conditions exist for the other tools in a stack, because that is what determines whether a licence change is a nuisance or an emergency — and it is a much better question to ask now than during the week it happens.