OpenTofu: The Fork That Kept the Version Numbers

HashiCorp relicensed Terraform under the BUSL; fifteen days later its competitors forked the last MPL release and handed it to the Linux Foundation.

Sources

Most forks are born angry and die quiet. OpenTofu is the exception: born in six days from a license change, handed to a foundation within a month, and still shipping version numbers that shadow the product it left. This is the story of how a competitor coalition turned the last MPL-licensed Terraform release into a foundation-run project, rebuilt the distribution registry it could no longer trust, survived a cease-and-desist over one code block, and ended up building features (state encryption, ephemeral resources, native S3 locking) that the original still doesn't have — while keeping drop-in parity with an upstream that now belongs to IBM.

The Origin: A License Change, Six Days, and a Manifesto

August 2023: the BUSL ultimatum

On , HashiCorp announced it was moving Terraform — along with Vault, Consul, Nomad, and Packer — from MPL 2.0 to the Business Source License v1.1, effective for all future releases. For end users, almost nothing changed: production use, modification, and internal hosting stayed allowed. But for the vendors whose entire products run other people's Terraform — Spacelift, env0, Scalr, and their peers — the BSL's grant excludes offering a competing product built on the code. Read as a vendor, the license was aimed directly at their business model. (We tell the licensor's side of this in full in our Terraform tale.)

The response was faster than anyone predicted. The opentofu/opentofu repository was created on — six days after the announcement — seeded from the last MPL-2.0-licensed 1.5.x line. The git archaeology is unusually clean because the fork inherited Terraform's entire commit history: the first new commits are renames. On August 17, ohad maislish (co-founder and CEO of env0, the cloud-automation vendor most directly threatened by the BSL) merged PR #1, "Rename Terraform to OpenTF in README," and Kuba Martin landed "Rename root module name" (#4), the GitHub Actions fixes (#5), and the migration guide (#23, merged August 18). The project's first week was spent erasing its own parent's name.

# Deepest new commits in opentofu/opentofu (everything before is
# inherited HashiCorp history, MPL-2.0 era):

DATE        SHA          AUTHOR          MESSAGE
2023-08-16  b9573d438b   ohad maislish   Rename Terraform to OpenTF in README
2023-08-17  01b77c6b64   Kuba Martin     Add freeform issue template. (#2)
2023-08-17  ebcf7455eb   Kuba Martin     Rename root module name. (#4)
2023-08-17  5bb46d0f65   Kuba Martin     Fix GitHub actions (#5)
2023-08-17  a458568bec   ohad maislish   Merge pull request #1 from .../rename-...
2023-08-18  01421147b2   Kuba Martin     Create MIGRATION_GUIDE.md (#23)

# The last inherited upstream commits days earlier:
2023-08-09  f8b1fe47dd   hashicorp       Make config errors more important (#33628)
2023-08-08  e26d07dda4   hashicorp       Merge pull request #33634 (jbardin)

Nine days later, on , the OpenTF fork announcement went public — 1,711 points on Hacker News, the biggest Terraform story of the decade. The manifesto asked HashiCorp to relicense; when the answer was no, the fork had already moved. On , the Linux Foundation announced OpenTofu — renamed from OpenTF over trademark concerns — backed by Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver, and Terramate, with pledges from 140+ organizations and 600+ individuals, and a commitment of at least 18 full-time developers over five years.

What makes the origin unusual among forks is what the founders didn't do: they didn't rename the binary semantics, didn't fork the version numbers, didn't fork the language. The migration path is deliberately boring — swap the terraform binary for tofu, keep your state, your modules, your providers, your required_version constraints. The fork's stated contract, drop-in replacement, is a strategy as much as a promise: it minimizes switching cost for users while maximizing the surface on which OpenTofu must never fall behind.

The Timeline: From Fork to Foundation to Parity and Beyond

Crisis Points & Architectural Pivots

1. The trust problem the fork inherited (2023) — a registry it couldn't verify

Terraform's real moat was never the core; it was the registry — the distribution, discovery, and signing infrastructure for thousands of providers. The moment OpenTofu forked the binary, it faced the problem HashiCorp spent a decade solving: where do providers come from, and who vouches for them? The first RFC in the fork's history, dated — three weeks after the repo existed — is titled "Provider GPG Key Handling in OpenTF Registry": the new registry did not possess copies of the GPG keys provider authors sign with, so validation failed outright. The temporary fix was an environment variable, OPENTF_ENFORCE_GPG_VALIDATION, which bypassed validation when keys were missing — a documented weakness shipped as an honest workaround.

The architectural answer, decided in the TSC meeting of November 2, 2023, is one of the most instructive decisions in the fork's history: instead of building a mission-critical SaaS to serve artifacts, the team chose Homebrew-style resolution backed by a plain git repository. The stated reasons: keep the core team on the CLI, "stand on the shoulders of giants (GitHub/AWS)" for availability, and — their words — "the transparency of the solution as a git repository, which is at the core of our competitive offering." Provider onboarding became a GitHub issue: open one, maintainers verify org membership and process your GPG keys. The engineering post reports almost 1,000 pull requests and issues processed that way. It is infrastructure as literature: the registry is auditable by anyone who can read a git log.

2. The cease-and-desist trial by fire (2024)

The ugliest chapter is small, technical, and deeply human, and we tell it in full from the licensor's side in the Terraform tale: in January 2024, contributor Evi1Pumpkin implemented the removed block (PR #1158) — a feature Terraform itself had shipped in v1.7.0 that same month. On April 3, HashiCorp's lawyers sent a cease-and-desist alleging the implementation incorporated BSL-licensed code, contributed by a developer with access to both codebases. Eight days later OpenTofu published its response — the redacted letter, plus a source-origin analysis tracing the implementation to the pre-existing MPL-2.0 moved block, noting that HashiCorp's own removed block appeared to build on the same MPL-era code. No litigation followed. For a five-month-old project, the episode became an existential audit: every line of every PR now carries a provenance question, and the project's clean-room discipline hardened permanently.

3. The sanctions episode (2024) — when the registry became geopolitics

On , the maintainers merged registry PR #817, "remove some providers due to a new policy" — deleting Yandex Cloud and other Russian-originated providers under a sanctions policy. The thread is 150 comments of exactly what you'd expect when an infrastructure utility makes a political call: users asking where the new policy is published, arguments about whether Yandex LLC itself is sanctioned, one commenter claiming the removal violates GitHub's acceptable-use policies, and — the highest-signal line in the thread — "Just fork then." A revert PR (#824) was opened and closed, unmerged. HashiCorp had never had to make this call for its users; a vendor with commercial relationships makes de-listing decisions quietly. A foundation project had to make it in public, in a git repository, where the fork's own transparency principle turned a policy decision into a 150-comment public trial. The registry stayed on GitHub — which means the registry's availability, and its provider listings, ultimately sit inside a US company's sanctions-compliance perimeter. That is the fine print of "infrastructure as a git repository."

4. The RFC process breakdown that rebuilt itself (2023→2024)

State encryption — the fork's flagship feature — started as GitHub issue #874, which grew "in size/scope/complexity to the point that it was unintelligible," in the RFC's own words. Four contributors (@JanosDebugs, @StephanHCB, @Yantrio, @cam72cam) extracted the design into a document revised by PR — and the failure itself became policy: the episode "formed the basis of the new RFC process" (RFC 20240524). The result is visible today: the rfc/ directory reads as the project's design journal — execution architecture, static evaluation, OCI registries, security-patch policy, contribution docs, linting — each dated, each with authors. The engineering culture iterates on its own process the same way it iterates on the engine.

5. The engine under everything: parity as a discipline

The drop-in promise forces a specific engineering posture: track upstream features while shipping your own, without ever letting the version numbers fork. The pattern repeats across the timeline. Provider-defined functions: Terraform shipped them in its 1.8 era, OpenTofu in v1.9.0 (January 2025). Ephemeral resources — a Terraform 1.10-era feature class — OpenTofu announced in nightlies on September 11, 2025 and shipped GA in v1.11.0 (December 2025), with the docs now covering ephemeral resources and write-only attributes as a first-class language surface. And where the fork innovates ahead, it does so in language semantics that upstream must eventually match or cede: v1.13's assume* function family and Symbol Libraries — reusable value and function collections importable like modules — have no Terraform equivalent at all. (We covered the v1.13 mechanics in our OpenTofu 1.13.0 release analysis.)

What the Fork Actually Built: State Encryption as Case Study

The feature that best separates the two engines is state encryption. Terraform state files historically sit in whatever backend you point at, plaintext — containing every secret every resource ever wrote into an attribute. HashiCorp's answer was workflow-level (Terraform Cloud, then HCP Terraform, then post-acquisition IBM-hosted tiers); OpenTofu's answer was engine-level: encrypt the state and plan artifacts themselves, client-side, with your own key provider. The design went through issue #874's chaos into the RFC process, was integrated into the state backends by @cam72cam in PR #1288 (merged March 4, 2024), and shipped GA in v1.7.0. The configuration surface is deliberately explicit:

terraform {
  encryption {
    key_provider "some_key_provider" "some_key_provider_name" {
      # Key provider options here
    }
    method "some_method_type" "some_method_name" {
      # Method options here
      keys = key_provider.some_key_provider.some_key_provider_name
    }
    state {
      # Encryption/decryption for state data
      method = method.some_method_type.some_method_name
    }
    plan {
      # Encryption/decryption for plan data
      method = method.some_method_type.some_method_name
    }
  }
}

The key-provider roster is the tell: pbkdf2 for passphrase-based setups, aws_kms, gcp_kms, vault — and OpenBao, the Linux Foundation's own fork of Vault, which was added as a key provider in April 2024. A foundation-run fork naturally accumulates foundation-run dependencies: OpenTofu encrypting state with OpenBao is the BUSL crisis's recursive punchline — the two major HashiCorp relicsensing casualties, now wired together under LF governance. The production-grade details accumulated the honest way: v1.7.0 shipped the GA; PR #2232 (December 2024, @cam72cam) made OpenTofu force a state change when decryption fell back to an unencrypted path — closing the silent-downgrade hole that a naive "encrypt your state" rollout leaves behind. That patch is the difference between a feature and a security posture.

Community Engine & Corporate Influence: Who Actually Built It

The contributor graph is the most honest artifact in the whole story, because the fork inherited it wholesale. OpenTofu's top contributors by commits are the same names that top Terraform's — they carried over with the git history:

CONTRIBUTIONS  LOGIN            WHO
4025           mitchellh        Mitchell Hashimoto — HashiCorp co-founder (inherited history)
3535           jbardin          James Bardin — HashiCorp staff (inherited history)
3232           apparentlymart  Martin Atkins — long-time Terraform maintainer, now OpenTofu TSC
2121           stack72          Paul Stack — community maintainer era (inherited history)
1728           catsby           Nick Snygg — inherited history
1245           phinze           Mitchell's early HashiCorp colleague (inherited history)
1154           radeksimko       Radek Simko — HashiCorp staff (inherited history)
1116           jen20            James Nugent — inherited history
 324           cam72cam         Christian Mesh — OpenTofu TSC, state-encryption lead

The inherited block is the fork's foundation in the most literal sense: the first ~4,000 commits of "OpenTofu" are HashiCorp's MPL-era work, preserved with authorship intact. What matters is who commits now. The current maintainer roster is seven people: Andrei Ciobanu (@yottta), Christian Mesh (@cam72cam), Diógenes Fernandes (@diofeher), Ilia Gogotchuri (@Gogotchuri), James Humphries (@Yantrio), Martin Atkins (@apparentlymart), and Larry Bordowitz (@lbordowitz). The affiliations tell the business story: @apparentlymart is the most significant individual link between the two projects — a long-time Terraform core maintainer who now holds OpenTofu's TSC seat; @Yantrio's email domain is spacelift.io — a Terraform-competitor platform and named Linux Foundation backer, employing a maintainer. The corporate engine of the fork is literally its sponsor coalition: Spacelift, env0, and Scalr sell platforms that orchestrate Terraform, Gruntwork sells services around it, and the fork guarantees their license position forever. That is a different failure mode than HashiCorp's single-vendor dependency: instead of one paycheck, a coalition of competing vendors coordinated through a TSC with supermajority rules, biweekly public meetings, and decisions documented in a public folder within three days. The TSC notes from September 2026 are four lines long and one of them is "Releasing 1.13 tomorrow." Boring governance, working.

Current Trajectory: The Verdict

Three years in, OpenTofu has done the two things forks almost never do: it survived, and it stopped being defined by the thing it forked from. The release cadence is metronomic — v1.6.0 (January 2024) through v1.13.1 (October 2026), eight GA minors plus patches, with v1.13's deliberately shortened cycle tying the support calendar to Go's release cadence and extending security support to August 1, 2027. The project's security advisory policy runs daily govulncheck scheduled scans against main and every non-EOL maintenance branch, source-mode for lowest false-positives — and codifies the judgment call of when a patch release is worth the risk. The engine rewrite (RFC 20250728) and built-in linting (RFC 20260406, "the most highly-voted issue in our GitHub repository") are the forward bets — the same language, a re-plumbed evaluation core.

The open threads are real. Upstream is now IBM's, with Terraform v1.17 shipping policy-as-code GA — and a corporation with a services arm behind it; the parity race continues on a new balance sheet. The registry-as-git-repo sits inside GitHub's sanctions-compliance perimeter, as PR #817's 150 comments demonstrated in public. And the maintainer bench is seven people deep — a bus-factor reality the TSC's own inactivity-removal rules acknowledge. But the verdict on the fork experiment itself is already in: OpenTofu proved that a hostile relicensing of a major open-source project can be reversed by the market rather than the courts — not by undoing the license, but by making it irrelevant to anyone who wants open IaC. The version numbers still shadow Terraform's; the features (state encryption, ephemeral parity, OCI-native distribution, S3 locking without DynamoDB) no longer do. For platform teams, the practical reading lives in our OpenTofu vs Terraform comparison; for the full history of the tool OpenTofu forked, our Terraform tale covers the licensor's side from 2014 to IBM.