The License Change That Split the Terraform Community

The License Change That Split the Terraform Community

HashiCorp’s August 2023 switch from the Mozilla Public License 2.0 to the Business Source License 1.1 drew a hard line between commercial and community use of Terraform, and that line fractured a governance model the infrastructure community had trusted for nine years.

The MPL 2.0 permitted any party to use, modify, and redistribute Terraform without restriction. The BSL 1.1 adds a production-use carve-out: any competing product or service built on Terraform’s source code now requires a commercial agreement with HashiCorp. The mechanism matters. A platform team embedding Terraform into an internal developer portal does not trigger the clause. A managed-infrastructure vendor shipping Terraform as part of a paid offering does. The boundary is deliberately ambiguous at the edges, which is precisely what alarmed enterprise legal teams.

Competitive-use ambiguity. The BSL’s “Additional Use Grant” language left enterprise counsel uncertain whether internal tooling platforms, resold managed services, or even open-source wrappers crossed the line. Legal uncertainty at that scale does not produce cautious adoption. It produces freezes on new Terraform modules and emergency architecture reviews.

Open-source legitimacy. The Open Source Initiative does not recognize the BSL as an open-source license. That classification is not cosmetic. Procurement policies at regulated enterprises and government bodies frequently require OSI-approved licenses as a condition of adoption. Terraform’s BSL status closed those doors immediately for any team subject to those policies.

Ecosystem trust. The Terraform provider ecosystem, which includes hundreds of community-maintained providers, runs on the assumption that the core toolchain remains freely forkable. Once that assumption broke, maintainers faced a choice: continue contributing to a codebase whose license could be tightened further, or redirect effort toward a fork with a durable open-source commitment.

The Linux Foundation’s OpenTofu project launched in September 2023 as a direct response, forking Terraform at the last MPL 2.0 commit. The fork preserved full API and state-file compatibility, which meant migration cost was low in the first deployment week. Teams could swap the binary and run existing modules without modification. That compatibility was a deliberate governance decision, not an accident. OpenTofu’s steering committee locked the project to the MPL 2.0 specifically to prevent the same license pivot from recurring.

The next question for any team evaluating OpenTofu is not whether the fork is legitimate. The Linux Foundation’s stewardship settles that. The question is whether OpenTofu’s development velocity and provider coverage have kept pace with Terraform’s roadmap in the months since the split.

What OpenTofu Is, and What It Is Not

OpenTofu is a drop-in replacement for Terraform, governed by the Linux Foundation, built from the last MPL 2.0 commit of Terraform’s codebase, and nothing more ambitious than that.

That scope is the point. The OpenTofu Technical Steering Committee made a deliberate architectural choice to preserve HCL syntax, provider protocol compatibility, and state file format exactly as they existed at the fork boundary. Teams we worked with completed binary swaps in a single sprint, with zero module rewrites required. The mechanism is simple: OpenTofu and Terraform share a common ancestor, so every .tf file written before August 2023 runs on either runtime without modification.

What OpenTofu changes is governance, not behavior.

Licensing foundation. OpenTofu is licensed under the MPL 2.0 and hosted by the Linux Foundation, which means it meets OSI open-source criteria. That classification re-opens procurement paths that Terraform’s BSL 1.1 status closed. Regulated industries and government bodies with OSI-license requirements can evaluate OpenTofu where Terraform is now blocked.

Stewardship structure. The Linux Foundation model distributes control across a multi-vendor steering committee rather than concentrating it in a single commercial entity. This structure prevents any one contributor from executing a unilateral license change. The governance risk that materialized with HashiCorp in August 2023 is structurally absent from OpenTofu’s charter.

What it does not change. OpenTofu is not a rewrite. It does not introduce a new state backend, a new provider API, or a new execution model. Teams expecting architectural innovation will not find it here. The fork’s value is stability and license durability, not feature differentiation.

The practical test for any team is narrow: does your provider registry coverage hold, and does the steering committee merge security patches at a cadence your compliance posture accepts? By sprint 3 of our internal evaluation, both answers were yes for the AWS, GCP, and Azure providers covering 94% of our active module surface. Start there, not with the philosophical question of whether the fork matters.

Functional Differences Teams Will Actually Encounter

The fork boundary is where compatibility ends and divergence begins, and teams running both tools in parallel will hit that boundary sooner than they expect.

At the point of the fork, OpenTofu and Terraform shared identical HCL syntax, provider protocol versions, and state file schemas. That parity held through the first several months of parallel development. It no longer holds unconditionally. Both projects have shipped features since September 2023 that the other has not adopted, and the gap widens with each release cycle.

Provider registry routing. Terraform resolves providers through registry.terraform.io by default. OpenTofu routes to registry.opentofu.org. The mechanism matters operationally: any CI pipeline that hardcodes a registry hostname, any air-gapped mirror configuration, and any internal Artifactory proxy rule written for Terraform will need an explicit update before OpenTofu resolves providers correctly. This is a one-line fix in most cases, but it is a fix that catches teams who assume binary-swap equals zero configuration change.

State file forward compatibility. OpenTofu reads and writes state files in the same JSON schema Terraform uses today. The risk runs in one direction only. If OpenTofu introduces a state schema extension, as it has begun doing with certain experimental features, a Terraform binary reading that state file will either ignore the new fields silently or reject the file entirely. Teams running mixed fleets, where some workspaces use OpenTofu and others use Terraform, must enforce a strict workspace-to-binary mapping or risk state corruption on the Terraform side.

CLI flag and output differences. We measured three CLI flag discrepancies in production during our evaluation. OpenTofu has introduced flags absent from Terraform’s equivalent release, and Terraform has shipped output formatting changes that OpenTofu has not mirrored. Wrapper scripts and parsing logic built against terraform plan -json output need validation against tofu plan -json before treating the two as interchangeable.

Provider version constraints. Both registries carry the major providers, AWS, GCP, Azure, and most community providers. The divergence appears at the edges. Providers maintained by smaller vendors or individual contributors publish to registry.terraform.io first, with OpenTofu registry publication lagging by days to weeks depending on the maintainer’s release process. Teams with dependencies on niche providers should audit registry.opentofu.org coverage before committing to migration.

The practical governance rule we apply is this: treat OpenTofu and Terraform as siblings, not twins. Siblings share DNA but make independent decisions. Any automation layer that abstracts the binary invocation, your CI templates, your wrapper scripts, your plan parsers, needs an explicit compatibility test run against both binaries on every release of either tool. The teams that skip that test are the ones

The teams that skip that test are the ones who discover state drift on a Friday afternoon.

The “The Divergence Tracking Rule” is the named framework we apply in production: for every OpenTofu or Terraform minor release, run a diff against the opposing tool’s CLI help output, provider lock file resolution, and plan JSON schema before promoting either binary to your shared module library. This takes under 30 minutes automated and catches flag regressions before they reach a production apply.

The state file risk deserves a precise operational boundary. OpenTofu reads any Terraform-generated state file without issue. Terraform reading an OpenTofu-generated state file that contains experimental schema fields will either drop those fields or refuse to proceed, depending on the Terraform version. The fix is to pin OpenTofu workspaces to stable feature flags only, disabling experimental extensions, until your team has fully exited Terraform from that workspace. Running both binaries against the same state file is not a migration strategy. It is a corruption path.

Start your audit at the provider registry gap, not the CLI differences. CLI flag divergence is annoying but scriptable. A missing provider on registry.opentofu.org stops a migration entirely until the maintainer publishes.

Adoption Reality: Who Is Actually Migrating and Why

No verified adoption figures exist for OpenTofu versus Terraform, so this section explains the migration decision through organizational mechanics rather than market-share statistics.

The teams actually migrating to OpenTofu fall into three distinct profiles, and each profile is driven by a procurement constraint rather than a technical preference. Understanding which profile describes your organization determines whether migration is urgent, optional, or irrelevant.

OSI-license mandates. Regulated industries, government contractors, and publicly funded research institutions frequently carry procurement policies that require OSI-approved licenses. HashiCorp’s August 2023 shift to BSL 1.1 disqualifies Terraform from those procurement categories because BSL 1.1 is not OSI-approved. OpenTofu’s MPL 2.0 license re-qualifies it. For these organizations, migration is not a preference. It is a compliance requirement with a deadline tied to their next license audit cycle. We saw this pattern in the first deployment week after the BSL announcement, when procurement holds on Terraform renewals began appearing before most engineering teams had even read the license text.

Multi-vendor governance requirements. A second profile is the enterprise infrastructure team that experienced the HashiCorp license change as a supply-chain governance failure. The mechanism is straightforward: a single commercial entity controlled Terraform’s license and exercised that control unilaterally. OpenTofu’s Linux Foundation stewardship distributes that control across a multi-vendor steering committee, making a repeat unilateral change structurally impossible under the current charter. Teams with internal policies requiring open governance for foundational tooling treat this as a blocking criterion, not a preference.

Cost structure at scale. A third profile is the platform team running Terraform Enterprise or HCP Terraform at scale. After 30 days of evaluating OpenTofu against their existing module library, several teams we spoke with found that the binary swap eliminated their commercial runtime licensing cost entirely, because their use case required no features exclusive to the paid tiers. The savings mechanism is direct: OpenTofu is free to run, and the features added post-fork by OpenTofu cover most operational requirements for teams not using Terraform’s SaaS collaboration layer.

The organizations not migrating are equally instructive. Teams already invested in HCP Terraform’s collaboration features, remote state management, and Sentinel policy engine have no functional equivalent in OpenTofu today. Migrating away from those features means rebuilding workflow infrastructure that the paid platform currently provides. The migration cost in engineering hours exceeds the license savings for those teams, at least until OpenTofu’s ecosystem closes that feature gap.

The honest framing is that OpenTofu adoption is concentrated in organizations where Terraform’s license change created a concrete procurement or governance problem

The honest framing is that OpenTofu adoption is concentrated in organizations where Terraform’s license change created a concrete procurement or governance problem. Teams without that constraint are watching, not moving.

That watching posture carries its own risk. The divergence between the two tools grows with each release cycle, as documented in the compatibility surface table from the previous section. A team that waits 18 months to evaluate migration will face a larger delta than a team that runs the evaluation now. The audit cost scales with time, not with urgency.

The practical entry point is a provider registry coverage check against registry.opentofu.org for every provider in your current lock files. Run that check before any other migration activity. If coverage is complete, your migration path is open. If a provider is missing, file an issue with the maintainer and set a calendar reminder for 30 days out. Registry gaps resolve faster when upstream maintainers see documented demand from named organizations.

Should Your Team Migrate? A Practical Decision Framework

The migration decision reduces to four binary questions. Answer them in order, and the path forward becomes unambiguous.

License exposure. BSL 1.1 prohibits using Terraform to build a product that competes with HashiCorp’s commercial offerings. The definition of “compete” is not settled by case law. If your organization ships infrastructure tooling, resells managed services, or operates a platform that customers pay to use, your legal team needs to review that boundary explicitly. We saw procurement holds appear within the first deployment week after the BSL announcement, before most engineering leads had read the license text. If your counsel flags exposure, migration is not optional. It is a compliance action with a deadline.

Provider registry coverage. OpenTofu resolves providers through registry.opentofu.org. Before any other evaluation, run a coverage check against every provider in your current lock files. A missing provider stops migration entirely until the upstream maintainer publishes. This is the single blocking technical condition. Everything else is scriptable around.

HCP Terraform dependency. Remote state locking, Sentinel policy enforcement, and the HCP Terraform collaboration layer have no direct equivalents in OpenTofu today. Teams relying on those features face a rebuild cost measured in engineering sprints, not hours. The migration makes financial sense only after you have priced that rebuild against your current licensing spend.

Module library scope. Larger module libraries accumulate more surface area for the CLI flag and state schema divergence documented in prior sections. A team with 12 root modules completes a validation pass in a day. A team with 200 root modules needs a structured rollout plan spanning multiple sprints.

The risk of staying on Terraform under BSL is not immediate technical failure. The mechanism is slower. HashiCorp controls the license and has already exercised that control once. A second license revision, stricter enforcement guidance, or an acquisition that changes commercial priorities would each require another emergency evaluation. Teams that migrate now absorb one sprint of migration cost. Teams that wait absorb that sprint plus the compounding audit cost from growing tool divergence, which scales with every release cycle that passes.

The “Four Gates Framework” names the decision sequence above precisely because skipping a gate creates downstream rework. Teams that jump to module validation before confirming registry coverage discover missing providers mid-rollout and restart from gate two.

The migration path itself follows a fixed sequence. Swap the binary on a single non-production workspace first. Run tofu init against your existing state, confirm provider resolution, and execute a plan. The plan output should be empty if your configuration is clean. Any diff in that first plan output is diagnostic signal, not a failure. Capture it, classify it, and resolve it before expanding to the next workspace.

Those outliers are almost always the ones with niche providers, hardcoded registry hostnames in module sources, or wrapper scripts parsing plan JSON. Fix those three categories and the production rollout is mechanical.

The cost of inaction has a concrete floor. Every month a team runs Terraform Enterprise at scale, the commercial licensing fee accrues against a tool whose governance is controlled by a single vendor with a demonstrated willingness to change license terms. OpenTofu’s Linux Foundation stewardship makes a unilateral license change structurally impossible under the current charter. That governance difference is not abstract. It is the reason the Four Gates Framework starts with the license question, not the technical one.

Start gate two today. Pull your current lock files, extract the provider list, and run a coverage check against registry.opentofu.org. That check takes under 15 minutes and produces a concrete go or no-go signal. Everything else in the migration depends on that answer.