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 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.
| Factor | Terraform (HashiCorp) | OpenTofu |
|---|---|---|
| License | Business Source License (BSL) — not OSI-approved | MPL-2.0 — OSI-approved, weak copyleft |
| Competitive-use restriction | Yes — vague restriction on products competing with HashiCorp | No |
| Governing body | HashiCorp | Linux Foundation |
| Roadmap driver | Terraform Cloud revenue objectives | Contributors who left HashiCorp's ecosystem over the license change |
| Migration effort | N/A | Syntax compatible at HCL layer; cost is in provider version pinning and CI pipeline updates, not logic rewrites |
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.
Why OpenTofu gained traction
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.
Three factors driving the decision
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.
Migration cost and compounding risk
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.
Where BSL ambiguity creates cost
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 status and procurement friction
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.
| License Dimension | MPL-2.0 (OpenTofu) | BSL (Terraform) |
|---|---|---|
| OSI Approved | Yes | No |
| Production Use | Unrestricted | Restricted if competing |
| Copyleft Scope | File-level only | None, but use-restricted |
| Legal Review Burden | Standard open-source review | Requires custom exception |
| Conversion to OSS | Already OSS | Four-year Change Date |
Recurring review burden compared
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.
Provider catalog and compatibility
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.
Governance, cadence, and tooling
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
Module registry fragmentation
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.
| Dimension | Terraform | OpenTofu |
|---|---|---|
| Provider catalog | Larger absolute count, vendor-tested | Full compatibility via SDK protocol |
| Release governance | HashiCorp/IBM roadmap control | Linux Foundation RFC process |
| State encryption | Managed service dependency | Native client-side, shipped 1.6 |
| Module registry | registry.terraform.io | Separate registry, major modules present |
| Third-party tooling | Broad legacy support | Dual-support growing post-2024 |
| Community triage | HashiCorp priority queue | Public, multi-company maintainers |
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 file compatibility risks
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.
Registry and CLI gaps
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.
Scoping your migration effort
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.
| Migration Task | Effort Level | Primary Failure Condition |
|---|---|---|
| State file portability | Low, schema-compatible | Experimental features in Terraform 1.6 and later |
| Registry source rewrites | Medium, mechanical | Dynamic source strings in module calls |
| CLI flag parity in CI | Low to medium | Pipelines using post-fork Terraform flags |
| Team runbook updates | Medium | Documentation debt causes onboarding errors |
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.
Profiles and recommendations
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.
Summary table by profile
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.
| Team Profile | Recommendation | Primary Failure Condition |
|---|---|---|
| Startup or growth-stage | OpenTofu | No hosted run environment; need self-managed runners |
| Regulated enterprise | Terraform with support contract | IBM restructures support tiers at renewal |
| Open-source-first culture | OpenTofu | Large registry.terraform.io source address backlog |
| Existing Terraform Cloud customer | Terraform until renewal, then migrate | Reactive migration if pricing changes mid-cycle |
Decision is reversible
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.
Frequently Asked Questions
Q: How does the fork that changed infrastructure-as-code forever apply in practice?
See the section above titled "The Fork That Changed Infrastructure-as-Code Forever" for the full breakdown with examples.
Q: How does bsl vs mpl-2.0: what the licenses actually mean for your team apply in practice?
See the section above titled "BSL vs MPL-2.0: What the Licenses Actually Mean for Your Team" for the full breakdown with examples.
Q: How does ecosystem, tooling, and community: how the two projects diverged apply in practice?
See the section above titled "Ecosystem, Tooling, and Community: How the Two Projects Diverged" for the full breakdown with examples.
Q: How does migration reality: what it actually takes to switch from terraform to opentofu apply in practice?
See the section above titled "Migration Reality: What It Actually Takes to Switch from Terraform to OpenTofu" for the full breakdown with examples.
Drop a comment if you've audited a similar spike. What was the dominant cause for your team? Share what worked or what blew up.
Top comments (0)