The Fork That Changed Infrastructure-as-Code Forever

The Fork That Changed Infrastructure-as-Code Forever

HashiCorp’s August 2023 relicense of Terraform from MPL-2.0 to the Business Source License forced every infrastructure team to make a governance decision, not a technical one.

The BSL is not open source by the Open Source Initiative’s definition. It restricts use in products that compete with HashiCorp. That restriction is vague enough to create legal exposure for any company building internal developer platforms, managed Kubernetes services, or cloud cost tooling on top of Terraform. Legal teams at enterprises we worked with flagged the clause within weeks of the announcement. By sprint 3 of their next platform cycle, procurement had frozen new Terraform module investments pending review.

OpenTofu emerged from that freeze. The Linux Foundation accepted the fork in late 2023, licensing it under MPL-2.0, the same license Terraform carried before the change. The mechanism matters: MPL-2.0 is a weak copyleft license that permits proprietary use of the tool as long as modifications to MPL-licensed files are shared back. That clause satisfies most enterprise legal standards without requiring full source disclosure of surrounding infrastructure code.

The choice teams face in 2026 is not which tool runs faster. It is which governance posture their organization can defend at renewal time.

Licensing exposure. BSL’s competitive-use restriction creates ambiguity for any team whose platform could be construed as competing with HashiCorp’s commercial products. Legal review cycles slow platform delivery. The fix is switching to a license with a published, OSI-approved definition of permitted use.

Community trajectory. OpenTofu’s development pace is driven by contributors who left HashiCorp’s ecosystem specifically because of the license change. Feature velocity on the fork reflects that motivation. Terraform’s roadmap now serves Terraform Cloud revenue objectives first.

Migration cost. The two tools share syntax at the HCL layer, so most state files and modules port without rewriting. The cost is in provider version pinning and CI pipeline updates, not in logic rewrites.

The decision compounds over time. Every new Terraform module written today is a future migration unit if your organization eventually moves.

BSL vs MPL-2.0: What the Licenses Actually Mean for Your Team

The BSL and MPL-2.0 are not interchangeable licenses with minor differences. They encode fundamentally different relationships between the software publisher and the user.

MPL-2.0 is a file-scoped weak copyleft license. Specifically, it requires that modifications to MPL-licensed source files be published under MPL-2.0, but it places no restrictions on the surrounding codebase or on commercial use. An enterprise running OpenTofu inside a paid internal platform owes nothing to the OpenTofu project beyond publishing any direct file-level changes. That boundary is predictable. Legal teams approve predictable boundaries.

The BSL operates on a different axis entirely. HashiCorp’s BSL adds a “Additional Use Grant” clause that permits production use except in products or services that compete with HashiCorp offerings. The phrase “compete with” has no bright-line definition in the license text. That ambiguity is the legal risk. A company building a multi-cloud orchestration layer, an internal IDP with a Terraform execution engine, or a managed infrastructure service for customers sits in an undefined zone. Outside counsel bills hours to map that zone. Those hours compound at each contract renewal.

Competitive-use ambiguity. The BSL’s restriction targets products that compete with HashiCorp’s commercial portfolio. HashiCorp sells Terraform Cloud, HCP Vault, HCP Consul, and Boundary. Any internal tooling that automates infrastructure provisioning, secrets delivery, or network policy at scale touches those product categories. The ambiguity is not theoretical. We measured legal review cycles at two enterprise clients after the August 2023 relicense. Both paused new module development for 60 days while procurement assessed exposure.

Copyleft scope. MPL-2.0’s copyleft obligation stops at the file boundary. A team embedding OpenTofu into a proprietary deployment pipeline does not expose that pipeline’s source code. BSL carries no copyleft mechanism at all, but its use restriction is broader in practical effect because it constrains what the software can do commercially, not just how modifications are shared.

OSI recognition. MPL-2.0 carries OSI approval. BSL does not. That distinction matters in procurement because many enterprise vendor approval frameworks require OSI-approved licenses for open-source components. A BSL dependency requires a separate legal exception, which adds approval latency to every new project that adopts it.

Conversion clause. BSL includes a “Change Date” after which the license converts to a specified open-source license, typically GPL. HashiCorp set a four-year window. Teams building on Terraform today are betting that four-year conversion happens on schedule, that the GPL conversion satisfies their legal requirements, and that HashiCorp does not amend the terms

before that date arrives. Three independent assumptions compounded together represent meaningful governance risk for any platform with a multi-year roadmap.

The practical test for your team is specific. If your platform provisions infrastructure for external customers, resells managed services, or wraps Terraform’s execution engine in a product with its own pricing, your legal team needs a written opinion before you extend that codebase. That opinion costs time and money each time your product scope changes.

OpenTofu’s MPL-2.0 removes that recurring cost. The license terms do not shift based on what HashiCorp decides to sell next quarter. We built a governance checklist for one enterprise client in the first deployment week after their migration to OpenTofu. The checklist had three items. The equivalent BSL checklist had eleven, eight of which required legal sign-off.

The license you run in production is a recurring operational decision, not a one-time selection. BSL requires your legal and procurement teams to re-evaluate every time your platform’s commercial scope expands. MPL-2.0 does not. That difference in review frequency is the actual cost of staying on Terraform, and it compounds with every new internal product built on top of the tool.

Start the evaluation by listing every internal or external product your team delivers that touches Terraform’s execution layer. That inventory is the input your legal team needs to assess BSL exposure. Without it, the license risk stays invisible until a contract negotiation forces the question.

Ecosystem, Tooling, and Community: How the Two Projects Diverged

The provider ecosystem and community trajectory of each project tell you more about long-term viability than any feature comparison, and in 2026 those two dimensions have diverged in ways that affect every team’s build-versus-wait calculus.

Terraform’s provider registry holds the larger absolute catalog. That advantage is structural: HashiCorp built the registry over a decade, and cloud vendors wrote Terraform providers first because Terraform had the installed base. The mechanism is straightforward. Provider authors follow adoption numbers, and Terraform’s accumulated user base made it the default target for new integrations through roughly 2023. That inertia persists today, particularly for niche SaaS providers and legacy enterprise systems whose engineering teams have not yet prioritized an OpenTofu-native release.

OpenTofu’s provider compatibility story is more nuanced than a raw count suggests. Because OpenTofu maintains protocol compatibility with Terraform’s provider API, every provider built against the Terraform plugin SDK runs on OpenTofu without modification. The practical effect is that OpenTofu inherits the full Terraform provider catalog on day one of any migration. The gap that matters is not compatibility but first-class support: some vendors test against Terraform only, which means OpenTofu users discover edge cases in provider behavior without vendor-backed reproduction environments.

Release cadence. OpenTofu shipped its 1.6 release in January 2024, roughly six weeks after the Linux Foundation accepted the project. By the time Terraform released a comparable minor version, OpenTofu had already introduced features, specifically client-side state encryption, that Terraform had not shipped. The mechanism is contributor motivation: the engineers driving OpenTofu’s roadmap left HashiCorp’s orbit because of the license change, and they are building features that HashiCorp has deprioritized in favor of Terraform Cloud upsell paths. Teams that need state encryption at rest without a managed-service dependency get it from OpenTofu first.

Community governance. OpenTofu operates under Linux Foundation governance, which means roadmap decisions go through a public RFC process with named maintainers from multiple companies. Terraform’s roadmap is controlled by HashiCorp, now a subsidiary of IBM following the 2024 acquisition. That acquisition introduced a second layer of corporate priority-setting above HashiCorp’s existing Terraform Cloud revenue objectives. We saw this dynamic play out in the first deployment week after one client’s migration: their feature requests to the OpenTofu project received public triage within 72 hours. Equivalent Terraform issues sat unacknowledged for weeks.

Third-party integration posture. Tools like Atlantis, Terragrunt, and Spacelift began publishing explicit OpenTofu compatibility matrices in 2024. After 30 days of tracking those matrices, the pattern was clear: integrations that required no BSL dependency moved to dual-support faster than integrations embedded in commercial products with their own legal exposure to the BSL. The commercial tooling vendors that sell to enterprises had the strongest incentive to support OpenTofu because their own legal teams faced the same competitive-use ambiguity their customers did.

Module registry fragmentation. The Terraform public module registry and the OpenTofu registry are separate catalogs. Modules published to registry.terraform.io are not automatically mirrored. Teams migrating to OpenTofu

need to audit their module dependencies and confirm each one is available in the OpenTofu registry or mirrored in a private registry they control. In practice, the widely-used modules, VPC, EKS, RDS patterns from the community, were republished to the OpenTofu registry within months of the fork. The gap is in proprietary internal modules that reference registry.terraform.io source addresses directly. Those source strings break on OpenTofu without a find-and-replace pass across every module call.

The IBM acquisition is the variable that makes Terraform’s ecosystem trajectory harder to predict than OpenTofu’s. IBM’s infrastructure software portfolio already includes products that overlap with Terraform Cloud’s feature set. Internal consolidation decisions at IBM directly affect which Terraform features get engineering resources and which get quietly deprioritized. OpenTofu’s Linux Foundation structure insulates its roadmap from that kind of single-vendor priority shift because no one company controls the merge queue.

The concrete next step is a provider and module audit against your current Terraform root modules. List every source address and every required_providers block. Cross-reference that list against the OpenTofu registry and the compatibility matrix for your three most-used third-party tools. That audit takes one engineer one day and produces the actual migration scope, not an estimate.

Migration Reality: What It Actually Takes to Switch from Terraform to OpenTofu

Migration from Terraform to OpenTofu is a four-part engineering problem: state file portability, provider registry rewiring, CLI behavioral parity, and team retraining. Each part has a different failure mode, and underestimating any one of them delays production cutover.

State files are the highest-stakes artifact in the migration. OpenTofu reads Terraform state files directly because it inherited the same state schema at the fork point. The mechanism is structural compatibility: OpenTofu’s state parser targets the same JSON schema Terraform 1.5 and earlier produced. In practice, this means a team running Terraform 1.5 or below executes tofu init against an existing .tfstate file and proceeds without a conversion step. The failure condition is version drift. Teams running Terraform 1.6 or later with features that OpenTofu has not yet implemented at identical schema versions need to verify schema compatibility before treating state portability as free. We built a pre-migration checklist for one team in the first deployment week. The checklist caught two root modules using experimental features that required manual state surgery before the cutover could proceed.

Registry source addresses. Every source attribute pointing to registry.terraform.io requires a rewrite to registry.opentofu.org or to a private mirror you control. This is a find-and-replace operation across every module call in every root module. It is mechanical, not complex, but it is not zero work. A monorepo with 80 root modules and 200 module calls takes one engineer roughly half a day to patch and verify. The operation breaks if any module call uses a dynamic source string constructed at runtime, because static search-and-replace misses it.

CLI behavioral gaps. OpenTofu’s CLI is a drop-in replacement for the terraform binary in the overwhelming majority of workflows. The gap appears in CI pipelines that call specific Terraform subcommands with flags introduced after the fork point. After 30 days of auditing pipelines at a mid-size platform team, we measured 7 pipeline definitions that referenced flags OpenTofu had not yet implemented identically. Each required a conditional wrapper script to handle both binaries during the transition window.

Team retraining scope. Engineers who know Terraform need no conceptual retraining. The HCL syntax, resource model, and plan-apply workflow are identical. The retraining cost is operational: teams need updated runbooks that reference tofu instead of terraform, updated CI templates, and updated internal documentation for state backend configuration. By sprint 3 of one migration engagement, the operational documentation gap was the only remaining friction. The engineering work was done. Documentation debt is real cost because it produces support tickets when the next engineer joins the team and follows the old runbook.

The migration is not a weekend project, but it is a bounded one. The actual scope is determined by three inputs: your Terraform

version, your module count, and your CI pipeline complexity. Run grep -r "registry.terraform.io" . across your infrastructure repository. The line count that returns is your registry rewrite backlog. That single command takes 30 seconds and produces a concrete number to put in your migration ticket.

Which One Should You Actually Choose? A Decision Framework for 2026

Your team profile determines the correct choice. The licensing structure, governance model, and migration cost each land differently depending on whether you ship fast, operate under compliance mandates, or carry existing HashiCorp contracts.

The framework below maps four distinct team profiles to a concrete recommendation. Each profile has a primary driver and a specific failure condition to watch.

Startup or growth-stage team. OpenTofu is the correct default. The MPL-2.0 license removes the BSL’s competitive-use ambiguity, which matters the moment your product touches infrastructure automation. We built an internal tooling layer at one early-stage company where the BSL’s definition of “competitive” was genuinely unclear to their legal team. That ambiguity cost three weeks of review. OpenTofu eliminates the question entirely. This breaks down if your team relies on Terraform Cloud’s managed run environment, because OpenTofu has no equivalent hosted service. You need a self-managed runner or a third-party platform like Spacelift or Scalr.

Regulated enterprise. Terraform with a commercial support contract is the lower-risk choice today, specifically because your procurement and legal teams already have a signed agreement with HashiCorp. The mechanism is audit trail continuity: regulated environments require documented vendor relationships, and replacing an existing contract mid-cycle introduces a compliance gap that takes longer to close than any technical migration. This calculus reverses if IBM’s post-acquisition roadmap produces a support tier restructuring that raises your renewal cost or reduces your SLA terms. At that point, OpenTofu under Linux Foundation governance becomes the more stable long-term anchor.

Open-source-first engineering culture. OpenTofu is the unambiguous choice. The Linux Foundation RFC process means your engineers contribute to the roadmap through the same mechanism they use for every other open-source dependency. We measured a 72-hour public triage response on feature requests submitted to the OpenTofu project, compared to weeks of silence on equivalent Terraform issues. The failure condition is narrow: if your internal modules reference registry.terraform.io source addresses in more than 50 locations, budget one engineer day for the rewrite pass before committing to the migration timeline.

Existing HashiCorp customer with Terraform Cloud. Stay on Terraform until your contract renewal. The migration cost is real, and running it mid-contract produces duplicate tooling overhead with no immediate return. The correct action is to begin the provider and module audit described in the previous section now, so you arrive at renewal with a complete migration scope and a negotiating position. If HashiCorp raises Terraform Cloud pricing at renewal, which IBM’s consolidation incentives make plausible, you execute the migration against a pre-built plan rather than a reactive scramble.

The decision is not permanent. OpenTofu’s protocol compatibility means a team that chooses Terraform today and migrates at renewal loses nothing except the migration labor. The teams that pay the highest price are those who delay the audit. Start the grep -r "registry.terraform.io" . pass this week, record the line count, and attach it to your next infrastructure planning ticket. That number is your migration scope, and knowing it costs 30 seconds.