Terraform: The Tool That Standardized Infrastructure, Broke Its Own License, and Got Bought by IBM

Mitchell Hashimoto's 'Initial commit' of May 21, 2014 — a graph-based, provider-plugin provisioning engine that became the de facto infrastructure-as-code standard, survived its own license crisis, and now belongs to IBM.

Sources

Very few tools get to define their category so completely that the category's name becomes a synonym for the tool. Terraform did it in under a decade: a provisioning engine one founder wrote in a two-week commit sprint became the language every cloud on earth ships a provider for — and then, at the exact peak of that dominance, its vendor decided the open-source license that carried it there was a liability. What followed is the most instructive governance story in modern infrastructure software: a fork backed by 140+ organizations, a cease-and-desist letter over a single language feature, and a $6.4 billion acquisition that quietly changed the licensor line in the LICENSE file to IBM. This is the origin-to-now story of the tool that standardized infrastructure as code — told through its commits, its license diffs, and its press releases.

The Origin: A Graph Engine One Founder Built in Two Weeks

HashiCorp — the company Mitchell Hashimoto co-founded with Armon Dadgar in 2012 — already had Vagrant, Serf, and Consul when the terraform repository was created on March 13, 2014. The first code landed two months later. Commit 649cf336e8 — "Initial commit", May 21, 2014, authored by Mitchell Hashimoto — kicked off a solo sprint that reads today like a design document for everything Terraform still is:

Two design decisions in that sprint outlived everything else. First, the execution graph: Terraform never operated on single resources, it operated on the dependency graph of an entire configuration, which made multi-resource change orchestration the primitive rather than an afterthought. Second, providers as plugins over RPC: every cloud, SaaS, and DNS service would be a separately-versioned binary speaking one protocol. That architectural wager is why the provider ecosystem grew to its current scale — and, as we'll see, it is also the exact mechanism that later split the community in half.

v0.1.0 shipped on July 28, 2014. The Hacker News thread reached 600 points — a striking number for a 0.1 of an infrastructure tool. Compare CloudFormation's single-vendor scope and you understand the pitch instantly: one language, one graph, every provider, plan before apply.

The Timeline: From Side Project to IBM Division

Crisis Points & Architectural Pivots

1. The provider amputation (2016–2020) — the pivot that created the ecosystem and the moat

Terraform's first scaling crisis was mechanical: with providers bundled into the main binary (v0.7.0's go-plugin consolidation), every AWS feature request, every Azure rename, and every minor DNS-provider fix shipped on Terraform core's release schedule. v0.10.0 cut providers out of the distribution entirely and made terraform init fetch them; v0.13.0 completed the pivot with automatic third-party provider installation from registry namespaces.

The honest accounting: this was a moat construction as much as an engineering decision. Once the Registry became the canonical distribution point, HashiCorp owned the ecosystem's namespace, its publishing pipeline, and its discovery surface — the same position npm holds for JavaScript, but controlled by the company whose commercial product sits on top. Every Terraform Cloud competitor (Spacelift, env0, Scalr) still builds on that registry today. The BUSL crisis of 2023 was only the explicit naming of a dependency that had been structural for six years.

2. The HCL 2.0 rewrite (2019) — the break that everyone paid for and nobody resented

v0.12.0 remains the most consequential breaking change in Terraform's history: an entire language replacement under the same command. Rich value types, first-class expressions, for_each, dynamic blocks, and a type system that made half of all existing module code invalid overnight. The migration tooling existed, but every module author on earth touched their code in 2019.

What makes 0.12 the reference point for every later argument about Terraform's governance is the consent. The community absorbed a full language rewrite because the value was obvious and the license was MPL — the deal was reciprocal. Four years later, a much smaller change (the license, not the language) produced a fork, because the reciprocity had quietly expired. When you hear "no one is forced to upgrade" deployed as a defense of BUSL, remember that 0.12 is what a change people accept looks like.

3. The BUSL switch and the fork (2023) — the license crisis, in full

On August 10, 2023, HashiCorp moved Terraform (with Vault, Consul, Nomad, and Packer) from MPL 2.0 to Business Source License v1.1, effective for all future releases. The mechanics of the grant, straight from the LICENSE file:

Licensor:        International Business Machines Corporation (IBM)
Licensed Work:   Terraform Version 1.6.0 or later
Change Date:     Four years from the date the Licensed Work is published
Change License:  MPL 2.0

Additional Use Grant:
  You may make production use of the Licensed Work, provided Your use
  does not include offering the Licensed Work to third parties on a
  hosted or embedded basis in order to compete with the Licensor's
  paid version(s) of the Licensed Work.

  ("Embedded" includes packaging that REQUIRES the Licensed Work to be
  accessed or downloaded for your competitive offering to operate.)

  Internal hosting/use within your organization is NOT a
  competitive offering.

Read it as an end user and almost nothing changes: production use, modification, and internal hosting all remain allowed. Read it as a vendor — the Spacelifts, env0s, and Scalrs of the world whose entire products run other people's Terraform — and the grant is aimed directly at your business model. The BSL is "source available," not open source in the OSI sense, and that distinction was the entire story: fifteen days later the OpenTF manifesto produced a fork backed by exactly those vendors, and on September 20, 2023, the Linux Foundation re-homed it as OpenTofu — a governance transfer at foundation grade, with a pledged 18-full-time-developer commitment.

The fork's technical position is also its most under-appreciated fact: OpenTofu didn't fork a dead codebase — it forked the last MPL release (1.5.x), then continued as a drop-in replacement that keeps version-number parity with the upstream it left. The two engines now ship parallel feature sets: OpenTofu's v1.6.0 GA landed in January 2024; its state-encryption work surfaced publicly during the C&D affair; and v1.13.0 (September 2026) continues the cadence — we covered it in full at the time in our OpenTofu 1.13.0 release analysis.

4. The removed-block C&D affair (2024) — the fork's trial by fire

The ugliest chapter is small, technical, and deeply human. In January 2024, contributor Evi1Pumpkin opened OpenTofu PR #1158 — "Add support for removed block" — a feature Terraform itself had shipped in v1.7.0 that same month. The removed block lets you remove a resource from configuration and state without destroying the infrastructure object:

removed {
  from = aws_instance.legacy_frontend

  lifecycle {
    destroy = false
  }
}

On April 3, 2024, HashiCorp's lawyers sent OpenTofu a cease-and-desist letter alleging the implementation incorporated BUSL-licensed Terraform code, contributed by a developer who had access to both codebases. On April 11, OpenTofu published its response — along with the C&D letter itself, redacted — and a source-code-origin analysis tracing the implementation to the pre-existing moved block, which is MPL-2.0 in both projects, noting pointedly that HashiCorp itself appeared to have built its own removed block on the same MPL-era code. No litigation followed. The fork had its trial by fire and stood.

The structural lesson outlives the dispute: once a codebase exists in both an open-licensed fork and a source-available upstream, every shared feature becomes a potential copyright claim. The two projects had the same commit history until August 2023; disentangling "independent implementation of a documented language feature" from "derived work" is now a permanent legal overhead on both sides of the fork. That is the true cost of the license change — not the grant text, but the permanent adversarial posture it installed between two codebases that share a mother tongue.

5. The IBM absorption (2024–2026) — what actually changed, and what didn't

IBM's April 2024 announcement ($35/share, $6.4B enterprise value) positioned Terraform as the provisioning half of a pair with Red Hat's Ansible Automation Platform inside IBM's automation software portfolio. The close took until February 27, 2025 — ten months from announcement, two past the original "end of 2024" target — with HashiCorp becoming a division within IBM Software, its day-to-day business continuing under the same leadership.

The measurable changes so far are smaller than the headlines. The release cadence held (six minors in the eighteen months post-close, v1.11 through v1.16, on a steady three-to-four-month rhythm). The BSL stayed. The core team's commit graph — jbardin, apparentlymart, and the same names that have carried the repo for a decade — kept landing. What changed in March 2026 was a single legal parameter: commit 4eba7c05 rewrote the LICENSE's Licensor line from HashiCorp, Inc. to International Business Machines Corporation, keeping every other term intact. IBM could have relaxed the BSL back to MPL and chose continuity instead — the most honest signal available about its intentions: Terraform is being managed as an acquired standard, not rescued as a community asset.

The product strategy tells the same story. The v1.14/v1.17 line — list resources, the terraform query command, and now Terraform Policy reaching GA in the v1.17.0-rc1 notes of October 7, 2026 — is governance and compliance tooling. That is an IBM-shaped roadmap: policy evaluation and audit surfaces are exactly what an enterprise software division sells into regulated customers, and exactly the features most likely to later show up gated behind HCP Terraform, the managed tier. Watch that boundary.

flowchart TD
    MH["2014: Mitchell Hashimoto - Initial commit - HashiCorp, MPL 2.0"]
    TF1["Terraform core - plan/apply graph - provider plugins over RPC"]
    SPLIT["2017: v0.10 - providers leave the binary - Registry becomes canonical"]
    HCL["2019: v0.12 - HCL 2.0 rewrite"]
    V15["2023: v1.5.0 - last MPL release"]
    BSL["2023-08: BUSL 1.1 - source available - HashiCorp licensor"]
    OTF["OpenTofu - Linux Foundation - MPL 2.0 - drop-in fork"]
    IBM["2025-02: IBM completes $6.4B acquisition - 2026-03: Licensor becomes IBM"]
    CD["2027-10: v1.6.0 Change Date - BSL reverts to MPL 2.0 per version"]
    MH --> TF1 --> SPLIT --> HCL --> V15
    V15 --> BSL
    V15 --> OTF
    BSL --> IBM
    IBM --> CD

Community Engine & Corporate Influence: Who Actually Built It

The contributor graph is unusually concentrated for a project this size — and unusually honest about who has been doing the work. The top contributors by commit count are jbardin (4,301), mitchellh (4,025), apparentlymart (2,955), stack72 (2,121), and catsby (1,728) — a mix of HashiCorp staff and long-term community maintainers who effectively became the project's institutional memory. The fork inherited this graph wholesale: OpenTofu's top-contributor list is the same five names, carried over by the shared history. The people didn't split in 2023 — the project did.

On the corporate side, HashiCorp was always the engine. Terraform Cloud (now HCP Terraform) existed from the early years, the Registry is a HashiCorp property, and every core maintainer paycheck until 2025 was a HashiCorp paycheck. The BUSL didn't create the vendor-dependency — it just converted it from a social arrangement into a legal one. The fork inverted the sponsorship model: OpenTofu's engine is a coalition of vendors who compete with HCP Terraform (Spacelift, env0, Scalr — all signed LF backers) plus services firms (Gruntwork) and end-users, coordinated through a foundation rather than a company. Both models are working; neither is neutral.

PlayerWhat they actually sellRelationship to the OSS core
HCP Terraform (IBM)Managed runs, state, policy as a serviceThe licensor's commercial tier — the product the BSL's Additional Use Grant protects
SpaceliftIaC orchestration and drift management platformLF OpenTofu backer; builds on the open engine, competes with HCP Terraform
env0Autonomous cloud control plane over IaCLF OpenTofu backer; same posture — the fork is existential for its license position
ScalrDrop-in Terraform Cloud alternativeLF OpenTofu backer; explicitly markets itself against the licensor's managed tier
GruntworkReference architectures and IaC servicesLF OpenTofu backer; services revenue, not platform revenue
OpenTofu RegistryCommunity registry for providers and modulesThe fork's answer to the distribution-moat problem — ecosystem infrastructure, not a product

The commercial comparison we maintain across this whole landscape lives in our OpenTofu vs Terraform guide, and the orchestration-layer vendors are mapped in our Pulumi and Spacelift comparison. The short version for this tale: Terraform created the only ecosystem in IaC where the core, the registry, and the leading commercial tier are all one balance sheet — and the fork exists because that balance sheet changed its terms.

Current Trajectory: The Verdict

Terraform won the language war, lost the community war, and sold the territory. HCL is the lingua franca of infrastructure: every provider on earth ships for it first, the Registry's gravity is unmatched, and IBM acquired a de facto standard at $6.4B — roughly the price of a company whose growth story had already stalled, precisely because the standard position is worth more than the revenue. The v1.x line is stable, the cadence is professional, and for the average end user nothing about the license or the acquisition has ever blocked a single terraform apply.

The costs are structural and they compound. The community that made Terraform the standard now maintains two engines, two registries, and a permanent copyright-paranoia tax on every feature that exists in both codebases. The BSL's Change Date means each version reverts to MPL 2.0 four years after publication — v1.6.0 in October 2027 — a slow-motion open-sourcing that changes little in practice (nobody runs v1.6.0 by then) but keeps the ideological argument alive forever. And the roadmap is now set in Armonk: policy evaluation, query surfaces, and audit tooling are enterprise-governance features, and the boundary between what the CLI does for free and what HCP Terraform charges for is the line to watch in every release notes post from here on.

Verdict: if you run Terraform today, keep running it — BUSL does not touch you, the cadence is strong, and v1.17's policy work is genuinely useful. If you're choosing an engine for a new platform in 2026, the decision is governance, not features: OpenTofu is a functionally equivalent, MPL-2.0, foundation-governed drop-in with its own registry, and the switching cost is an afternoon — our head-to-head guide walks it. And if you're a vendor whose product executes other people's Terraform, you already know what the LICENSE file says about you. The tool that taught the industry to version its infrastructure spent 2023–2026 teaching it a harder lesson: the license line in the repo is the one piece of infrastructure that never gets a patch release — only a rewrite.