On 10 August 2023, HashiCorp announced that it was changing the license on its core products — including Terraform, the dominant infrastructure-as-code tool — from the Mozilla Public License 2.0 to the Business Source License (BSL) 1.1. Within two weeks a group of users, vendors, and contributors had announced a fork. Within six weeks that fork had a name, a foundation backer, and momentum. The episode is a compact case study in how open-source licensing, commercial pressure, and community governance interact — and it has consequences for any organization that has standardized on Terraform.

What Actually Changed

For most of its life, Terraform was distributed under the Mozilla Public License 2.0, a recognized open-source license that permits commercial use, modification, and redistribution with few restrictions. The new Business Source License is not an open-source license in the sense the Open Source Initiative defines. The BSL permits source availability and most uses, but adds a restriction: you may not use the software to provide a competing commercial product to HashiCorp’s offerings.

HashiCorp’s framing was that the change targets a narrow class of users — vendors who build commercial products and services on top of HashiCorp’s software in direct competition with HashiCorp itself — and that the vast majority of users, who simply use Terraform to manage their own infrastructure, are unaffected. The BSL also includes a “change date” mechanism: each released version converts to the open Mozilla Public License after four years.

The technical reality for an ordinary Terraform user is, indeed, that day-to-day use is permitted. The controversy is not primarily about today’s permitted uses. It is about the precedent, the ambiguity, and the loss of the guarantee that an open-source license provides.

Why the Community Reacted

The strength of the reaction reflected several distinct concerns.

  • The ambiguity of “competing.” The BSL’s restriction turns on whether a use “competes” with HashiCorp. For companies and projects in the broad infrastructure-tooling space, that line is genuinely unclear, and ambiguity in a license is itself a cost — it requires legal review and introduces risk where there was previously certainty.
  • The unilateral nature of the change. Terraform’s ecosystem — providers, modules, integrations, training material, tooling — was built by a large community over years on the understanding that the software was open source. Changing the license unilaterally altered the terms under which that ecosystem had been built.
  • The precedent. Several other formerly open projects had relicensed under source-available terms in preceding years. Terraform’s move, given its central position in the infrastructure stack, was read by many as confirmation of a broader trend that the community wished to resist.

From OpenTF to OpenTofu

The community response was rapid and organized. On 25 August 2023, a coalition published the “OpenTF Manifesto,” calling for a fork of Terraform to be maintained under its original open-source license, and inviting HashiCorp to reverse course. The manifesto gathered support from a substantial list of companies and individuals, several of whom pledged engineering resources to the effort.

When HashiCorp did not reverse the change, the fork proceeded. On 20 September 2023, the project was renamed OpenTofu and announced its intention to join the Linux Foundation, placing the fork under neutral, foundation-level governance rather than the control of any single company. The fork starts from the last Mozilla-licensed Terraform release and continues development under that open license.

The governance point is the substantive one. A fork maintained by a single vendor merely relocates the risk that triggered the fork in the first place. A fork stewarded by a neutral foundation, with multiple corporate backers and an open contribution model, offers a structural guarantee: it cannot be unilaterally relicensed or discontinued by one actor, because no single actor controls it. That is the property the community lost when Terraform moved to the BSL, and the property the foundation model is designed to restore.

The Governance Lesson

This episode illustrates a principle that the distributed-systems and open-infrastructure communities have learned repeatedly: the durability of a piece of infrastructure software depends not only on its code but on its governance. Software that an organization depends on operationally is, in effect, a supply-chain dependency. If the governance of that dependency permits a single commercial entity to change the terms of use, then the dependency carries a risk that no amount of code quality can offset.

Open-source foundations exist precisely to manage that risk. Neutral ownership, transparent governance, and a contributor base spread across competing interests make a project resistant to capture or unilateral change. Organizations that build on foundation-governed projects are buying not just code but a governance guarantee — and the Terraform episode is a sharp reminder of what that guarantee is worth.

What Infrastructure Teams Should Consider

For an organization with a substantial investment in Terraform, the practical questions are immediate but not urgent — existing use remains permitted, and there is time to evaluate.

  • Inventory the dependency. Understand how deeply Terraform is embedded — the modules, providers, CI integrations, and team skills built around it. The depth of that investment shapes the cost of any future migration.
  • Watch OpenTofu’s trajectory. A fork’s viability depends on sustained contribution and a credible roadmap. The Linux Foundation backing and multi-vendor support are strong early signals, but adoption and release cadence over the coming months will determine whether OpenTofu becomes a durable alternative or a footnote.
  • Assess your own license exposure. Most users are unaffected by the BSL restriction. Organizations that build products or services on top of Terraform should review the license terms with counsel to understand whether the “competing” restriction touches their use.
  • Treat tooling as a portability question. The episode is a reminder to favor configuration and skills that are not irreversibly tied to a single tool’s proprietary direction. The Terraform configuration language and provider model are, for now, shared between Terraform and OpenTofu — that compatibility is itself a hedge worth preserving.

The license change is a recent event and its consequences are still unfolding. What is already clear is that the open-source community retains the capacity to respond to a relicensing it disagrees with — and that foundation governance is the mechanism through which it does so.

Further Reading

Back to Blog