OpenTofu: the Terraform Alternative After the License Change - init.d
IT

# OpenTofu: the Terraform Alternative After the License Change

Alessandro Corbelli~5 min read min
Table of Contents

Imagine building your house under a town’s rules. One day the town changes the building code, and things you used to do freely now need a permit, or are no longer allowed. The house is already up, but the rules of the game changed after the work was done. That is roughly what happened in 2023 to anyone using Terraform, the most widely adopted tool for infrastructure as code, the practice of managing servers, networks and firewalls by writing them in text files instead of configuring them by hand.

The company behind Terraform, HashiCorp, changed the product’s license, making it more restrictive. In response, part of the community that used and contributed to Terraform created an independent, derived version called OpenTofu, now maintained as a neutral open source project. For anyone who manages infrastructure, or relies on someone who does, understanding this story serves a concrete purpose: knowing what your work rests on, and what alternatives exist.

What happened to Terraform’s license

Until August 2023 Terraform shipped under a genuine open source license, the MPL 2.0: anyone could use, modify and redistribute it without particular constraints. Then HashiCorp moved to the Business Source License (BSL), a license described as source-available: the code stays visible and usable by almost everyone, but with a catch. You can no longer use Terraform to build a product that competes with HashiCorp itself.

The difference sounds technical, but the practical point is simple. A recognized open source license guarantees that nobody, in the future, can change the rules and restrict the use of what you adopted. A source-available license like the BSL removes that guarantee: the owner decides what is allowed and what is not, and can revisit it. For the vast majority of people using Terraform to manage their own servers nothing changes overnight, but for the ecosystem, meaning the companies and projects built around the tool, the signal was heavy. Those who had invested years in a free technology suddenly faced different rules set by a single company. Shortly afterwards, HashiCorp was acquired by IBM, which made the question even more concrete: who do you trust when you choose the tool that holds up your infrastructure?

What OpenTofu is and who governs it

Within weeks of the license change, a group of companies and developers announced a fork of Terraform. A fork is a copy of the code that continues on its own path, independent of the original. The project was named OpenTofu and handed not to a single company, but to the Linux Foundation, the same independent foundation that hosts Linux and, more recently, the MCP standard for connecting AI tools to external systems.

This step is the heart of the story. OpenTofu returned to a recognized open source license (the same MPL 2.0 Terraform had before), and its governance, meaning who decides how it evolves, is no longer in the hands of one company but of a community under a neutral foundation. The benefit is not ideological: it is a contractual guarantee that the license-change story cannot repeat itself. Nobody can later make OpenTofu source-available after the fact, because there is no single owner to decide it. For anyone building on a tool, knowing the rules will not shift under their feet is worth as much as the features.

Terraform or OpenTofu: what changes in practice

The best news for Terraform users is that OpenTofu was born as a compatible replacement. In the early days it behaved like a faithful copy: the same configuration files, the same HCL language, the same providers (the components that translate the description into calls to the various cloud providers). The command-line tool only changes in name: you type tofu instead of terraform, and in most cases everything else stays the same.

Terminal window
# Before
terraform init
terraform plan
terraform apply
# With OpenTofu, same files and same flow
tofu init
tofu plan
tofu apply

Over time the two projects began to diverge, each adding its own features. OpenTofu, for instance, introduced state encryption: the state file is the record the tool keeps of what it has already created, and it often holds sensitive information, so being able to encrypt it helps security. Terraform, in turn, follows its own roadmap. This means perfect compatibility mostly holds for those migrating from not-too-recent versions, while anyone using the latest features of either has to check case by case. For a typical project, though, migration stays painless: you point OpenTofu at the existing files and current state, run a preview of the changes, and if no unwanted changes appear you keep working as before.

When is it worth switching? There is no obligation, and Terraform keeps working perfectly. Choosing OpenTofu makes the most sense when having a genuinely open source technology with neutral governance matters: to avoid lock-in, meaning dependence on a vendor that can change the terms, for company policy reasons, or simply to stay on a community-driven project. It is the same prudence that applies to every piece of third-party software you depend on, from the packages that end up in your applications to the tool that governs your servers.

In short

In 2023 Terraform moved from an open source license to a more restrictive one, and the community responded by creating OpenTofu, a fork back to open source and handed to the Linux Foundation. The day-to-day practical difference for managing infrastructure is minimal, because OpenTofu was born compatible and migration is almost always a change of command. The real difference is in guarantees: with OpenTofu the terms of use do not depend on a single company and cannot change after the fact. Terraform remains the most widely used tool and a valid choice, but it is no longer the only one, and knowing the alternative is the first step to not being tied to a technology you do not control.

Sources

Tux versione Gandalf, mascotte del blog init.d

init.d is the team led by Alessandro Corbelli, a Linux systems administrator and backend developer with over twenty years of experience. He designs and runs cloud infrastructure (Google Cloud, AWS, Azure), server farms and high-availability architectures, and builds custom software in Laravel/PHP and Vue - from the Take2Me food delivery platform to our clients’ management tools. On this blog we share technical notes on Linux, system administration, development, DevOps and e-commerce.


More Posts