Terraform: The 44k-Star IaC Tool That Went Source-Available and Spawned OpenTofu

Here is the uncomfortable truth about Terraform in 2026: the tool that taught a generation to "write infrastructure as code" is no longer open source, and the open-source version of it has a different name. If you are starting an infrastructure-as-code project today, you are not choosing "Terraform or something else" — you are choosing Terraform (Business Source License, owned by IBM) or OpenTofu (MPL 2.0, Linux Foundation), a fork that shares Terraform's entire language and most of its behavior. That fork did not exist before August 2023, and it is the reason this article exists.

For nine years Terraform shipped under the Mozilla Public License 2.0, an OSI-approved, permissive-enough copyleft license that let anyone use, modify, and redistribute it freely. It became the default way teams provision cloud resources declaratively. Then HashiCorp changed one line in its license, the community responded within five days with a manifesto and a fork, and three years later that fork is one of the most significant in infrastructure tooling history. This is the story of that change, what it means for you, and how to make the call.

This review covers what Terraform is, the MPL years, the August 2023 BSL switch, the OpenTofu fork, HCL and state-file compatibility, the features OpenTofu shipped that Terraform still lacks, the IBM acquisition that added a second layer of uncertainty, real cost differences, where your state actually lives, and an honest verdict for a sovereignty-minded operator.

Terraform infrastructure as code

1. What Terraform Actually Is

Terraform is an infrastructure-as-code (IaC) tool. You describe the desired end state of your cloud resources — VPCs, compute instances, databases, IAM roles, DNS records — in a declarative language called HCL (HashiCorp Configuration Language), and Terraform computes the diff between your declared state and the real world, then makes API calls to converge them. Instead of clicking through a console or writing imperative scripts, you commit a plan to version control and let Terraform reconcile.

The core job Terraform takes is "make the cloud match this file." It does this through a provider plugin architecture: a provider knows how to talk to a specific platform (AWS, GCP, Azure, Kubernetes, Cloudflare, and thousands more), and Terraform orchestrates them. A state file records what it created so it can track drift and plan changes. That model — declarative, provider-based, stateful — is now the lingua franca of cloud provisioning, and OpenTofu inherited all of it.

2. The MPL Years (2014–2023)

From its 2014 release until August 2023, Terraform shipped under MPL 2.0. MPL is a "weak copyleft" license: you can use the software commercially, modify it, and embed it in products, with the obligation that modifications to MPL-licensed files themselves be shared if you distribute them — but your own proprietary code that merely uses the tool is unaffected. For almost everyone, MPL meant "free to use however you want, including commercially." This freedom is what let Terraform become the backbone of countless internal platforms, consultancies, and managed services.

Again, notice the setup. The permissive license made Terraform ubiquitous; ubiquity made it the default IaC; being the default made it the substrate for commercial products built by other vendors. HashiCorp monetized through Terraform Cloud (now HCP Terraform), but the free CLI remained the thing everyone actually ran locally and in their own CI. The license that built the moat was the same license that let competitors build businesses on top of the open CLI — and that is the tension the BSL was meant to resolve.

3. August 2023: The BSL Switch

On August 10, 2023, HashiCorp announced that Terraform (along with Vault, Consul, and others) would move from MPL 2.0 to the Business Source License 1.1 (BSL). The BSL is source-available, not OSI-approved open source. It grants broad use rights but forbids using the software in a way that "competes with HashiCorp's commercial offerings." The additional use grant clarified that ordinary end users and system integrators were fine, but the ambiguity about what counted as "competitive" was the problem. A license you have to hire a lawyer to interpret is a license that creates uncertainty, and uncertainty is what the community reacted to.

The change was not retroactive in the sense that existing MPL releases remained MPL, but it applied to all new versions from that point forward. Terraform 1.5.x became the last MPL-licensed line, and it became the exact branch point for the fork. Just as Redis 7.2.4 anchored Valkey, Terraform 1.5.x anchored OpenTofu.

4. Why HashiCorp Did It

The stated rationale was protecting the commercial business from competitors who "use the open-source tool to build competing products without contributing back." The BSL lets the core remain source-visible and free for most uses while reserving the right to monetize managed/competitive offerings. From a business-strategy view, it is a reasonable attempt to convert open-source ubiquity into defensible revenue. From a community view, it is a promise retracted — and the community's reaction proved how much goodwill the MPL promise had accumulated.

This is the same plot as Redis and Elastic, and it is worth naming the pattern: a company reaches escape velocity on an open license, realizes the hyperscalers or competitors capture the adjacent revenue, and tightens the license. The difference with Terraform was the speed and unity of the fork. The IaC ecosystem was too central, and too many vendors depended on it, to accept a license whose "competitive" clause nobody could precisely define.

5. OpenTofu: The Fork in Five Days

The response was astonishingly fast. Within five days, the OpenTF Manifesto was published, signed by dozens of companies (Gruntwork, Spacelift, Harness, env0, Scalr, and others), and a fork was announced. On September 20, 2023, the Linux Foundation formally introduced OpenTofu, renamed from OpenTF, with at least 18 engineers pledged full-time for a minimum of five years. It forked Terraform 1.5.x — the last MPL line — and kept MPL 2.0, an OSI-approved license with no "competitive" ambiguity.

The Linux Foundation governance was again the decisive move. It removed the single-vendor risk that the BSL had just demonstrated, and it signaled to every TACOS (Terraform Automation and Collaboration Software) vendor that OpenTofu was the safe, neutral engine. By April 2025, the CNCF accepted OpenTofu (first as a sandbox, then progressing), cementing its foundation status. OpenTofu crossed 10 million GitHub downloads and reached roughly 29,000 GitHub stars, with 3,900+ providers and 23,600+ modules in its registry — not a niche protest fork, but a mainstream alternative.

6. HCL and State-File Compatibility

The reason the fork is viable is compatibility. OpenTofu uses the same HCL language, the same provider protocol, and the same state file format as Terraform 1.5.x. For most simple-to-medium projects, an existing Terraform codebase runs unchanged on OpenTofu — you swap the binary (terraform for tofu) and your .tf files work. Provider binaries are shared and compatible. State files are interchangeable. That is why migration is frequently described as "change one binary."

The compatibility is not infinite, because the two projects have diverged since the fork. But the shared foundation means the risk of switching is low for the common case: a Terraform 1.5.x project with local or S3 state and standard providers is a short, reversible migration. The work expands only when you touch HCP-specific workflows, CI/CD references tied to terraform binaries, or dependency-lock nuances.

7. Features OpenTofu Ships That Terraform Still Lacks

This is where the fork stopped being "old Terraform" and became its own product. OpenTofu shipped several long-requested community features that Terraform's CLI still does not have:

Client-side state and plan encryption (v1.7, April 2024): OpenTofu can encrypt state and plan files before they leave your machine, using PBKDF2, AWS KMS, GCP KMS, or OpenBao as key providers. Terraform generally delegates encryption to the backend (S3 SSE, etc.), leaving local state plaintext. For teams under SOC 2 or PCI DSS, client-side encryption of secrets-in-state is a real compliance win.
Early variable evaluation (v1.8): use variables in contexts HCL previously forbade, like module sources.
Provider for_each (v1.9): iterate provider configurations the way you iterate resources — a clean win for multi-region/multi-account setups.
Ephemeral values and the -exclude flag (v1.11/v1.12): keep secrets out of state entirely, and selectively skip resources during operations.

These are not theoretical. State files routinely contain database passwords, API keys, and private keys in plaintext; OpenTofu's encryption addresses that directly, while Terraform users bolt on backend encryption and accept the gap. For a sovereignty- and compliance-minded operator, this alone can justify the switch.

8. The IBM Acquisition: A Second Layer of Uncertainty

In February 2025, IBM completed its $6.4 billion acquisition of HashiCorp. Terraform, Vault, and Consul are now IBM products. For teams already uneasy about the BSL, the IBM acquisition added a new strategic variable: the roadmap for a foundational tool is now set inside a much larger enterprise vendor. That is not automatically bad — IBM has deep enterprise reach and resources — but it is part of the calculation teams make in 2026 when choosing a default IaC engine.

The timing compounded the signal. The same period saw HCP Terraform's free tier end (March 2026) and its replacement capped at 500 managed resources, with pricing reported up roughly 18% year over year. None of that affects the open-source Terraform CLI directly, but it shapes the total cost of the Terraform commercial ecosystem — and pushes more teams toward OpenTofu plus a third-party TACOS (Spacelift, Scalr, env0, Atlantis), all of which now support OpenTofu natively, some as default.

9. Terraform's Counter-Position

Terraform has not stood still. It reached 1.14.x / 1.15 by 2026, kept pace on the provider protocol, and added its own features (ephemeral resources since 1.10, aligning with OpenTofu). Its advantages are ecosystem gravity and HCP Terraform's first-party managed platform. If your organization is already standardized on HCP Terraform, the commercial platform's polish and IBM backing are real. The honest trade is license certainty and fork-driven features (OpenTofu) versus ecosystem gravity and first-party managed services (Terraform/HCP).

10. Performance: Not a Differentiator

Independent benchmarking on mid-size AWS codebases (hundreds of resources) found performance is not a real differentiator between the two. Both tools spend most of their runtime waiting on cloud provider APIs rather than doing local processing. Pick a side based on license, governance, features, and cost — not speed. Anyone telling you one is dramatically faster is benchmarking the wrong thing.

11. Migration: From Terraform to OpenTofu

For the happy path — a Terraform 1.5.x project with local or S3 state and standard providers — migration is typically:

1. Install the tofu binary alongside terraform.
2. Run tofu init in the existing project; providers and modules resolve the same way.
3. Run tofu plan and compare output to a known-good terraform plan.
4. Swap CI/CD from terraform apply to tofu apply, or run both in parallel during a transition.
5. Optionally adopt .tofu file extensions (OpenTofu prioritizes .tofu over .tf when both exist, enabling OpenTofu-specific overrides while keeping Terraform compatibility).

The hesitation usually outweighs the work. Teams stay on Terraform 1.5.7 out of habit, but for new projects in 2026 the recommendation is increasingly OpenTofu by default, precisely because the license risk that triggered the fork is still present in Terraform and absent in OpenTofu.

12. Real Cost: CLI vs Platform

The Terraform CLI is free under BSL for non-competitive use; OpenTofu's CLI is free under MPL with no competitive restriction. The real cost difference is in the managed platform layer. HCP Terraform is a paid managed service with the recent free-tier changes; OpenTofu runs on third-party TACOS (Spacelift, Scalr, env0, Atlantis) or your own CI, with no first-party toll. Self-hosted, both are "free" in license terms, but OpenTofu removes the BSL ambiguity that can complicate an organization's license-compliance audit. For a consultancy or vendor building a product on top of IaC, OpenTofu's MPL is the clean choice; for a team already on HCP Terraform, the switching cost is the platform migration, not the CLI.

13. Data Sovereignty: Where Your State Lives

This is the part a sovereignty-minded operator must internalize. Terraform and OpenTofu are both self-hostable CLIs; they make API calls to your cloud and record state in a backend you choose — local disk, S3, GCS, Terraform/OpenTofu Cloud, or a remote backend. There is no mandatory telemetry shipping your infrastructure graph offsite; both respect your backend choice. You can run either air-gapped, encrypt state with your own keys, and keep the full picture of your cloud under your control.

The sovereignty nuance is governance and the state file's sensitivity. OpenTofu's client-side state encryption means secrets never leave your machine unencrypted, which is strictly better than Terraform's backend-only model for local state. And OpenTofu's foundation governance means no single vendor can relicense it out from under you — the exact risk Terraform users now live with. If license stability is part of your data-sovereignty posture, OpenTofu's MPL-under-Linux-Foundation is the stronger guarantee.

14. When to Choose OpenTofu

Choose OpenTofu for new IaC projects in 2026 by default. Choose it if your organization has a policy against non-OSI-approved licenses, because MPL is unambiguously open and BSL is not. Choose it if you need client-side state encryption or provider for_each or ephemeral values that Terraform's CLI lacks. Choose it if you are a vendor or consultancy building a product on top of IaC, where the BSL's "competitive" clause is a genuine legal risk. Choose it if IBM-owned roadmap uncertainty is a concern. For the majority of teams, OpenTofu is the lower-risk, equally capable, foundation-governed default.

15. When to Choose Terraform

Choose Terraform if your organization is already standardized on HCP Terraform and the managed platform's polish, SLAs, and first-party integration outweigh the license concern. Choose it if you are inside the IBM/Red Hat ecosystem and want aligned roadmaps. Choose it if a specific Terraform-only feature or enterprise workflow is load-bearing. Terraform is not "the bad guy" — it is the commercially steered, ecosystem-heavy option with a more complicated license story, and for some enterprises that alignment is worth more than the license purity.

16. The Honest Limitations

Both tools share HCL's inherent complexity: large codebases become hard to reason about, state drift and state-locking conflicts are ongoing operational realities, and a corrupted or lost state file is a serious incident. OpenTofu's limitation is narrower ecosystem gravity and the reality that some cutting-edge Terraform features or HCP-specific integrations are not present. Terraform's limitation is the BSL's legal ambiguity and the IBM-ownership strategic risk. Neither is "just install and forget" at scale; both demand state-management discipline. The fork's real limitation is that it split a community, and some tooling now has to support both — but that is a far smaller cost than being stuck under a license you cannot use.

17. Who Should Care in 2026

If you are a platform engineer, your default IaC engine for new services should be a conscious OpenTofu-versus-Terraform decision, documented in your standards. If you are a consultancy, the BSL's competitive clause is a direct risk to your business model, and OpenTofu's MPL removes it. If you are a CTO, Terraform is the clearest case study in "the license you trusted can change, and a foundation can save the day." The fork is mature, the migration is cheap, and the governance difference is permanent. Indifference is no longer defensible.

19. Modules and the Public Registry

Both Terraform and OpenTofu lean heavily on modules — reusable, parameterized bundles of HCL that encapsulate a piece of infrastructure (a VPC, a Kubernetes cluster, a database). The public registries (registry.terraform.io and registry.opentofu.org) host thousands of community and vendor modules, and for the common case a module written for Terraform 1.5.x works on OpenTofu and vice versa. This is another reason the fork is low-risk: the reusable ecosystem is largely shared. The divergence shows up only in modules that call Terraform-only features or HCP-specific backends, which are a minority. For a team adopting OpenTofu, the practical advice is to pin module versions, test tofu plan against your known-good terraform plan, and avoid HCP-coupled modules unless you are committed to the Terraform commercial stack.

20. State Backends Deep Dive

State is the most sensitive artifact Terraform/OpenTofu produces. Local state is fine for a laptop learning exercise and disastrous for a team, because state contains resource IDs, sometimes secrets, and the authoritative map of your cloud. Remote backends solve this: S3 (with DynamoDB locking for Terraform, or native S3 locking for OpenTofu 1.10+), GCS, Azure Blob, or a Terraform/OpenTofu Cloud backend. The backend choice interacts directly with the license story: OpenTofu's client-side state encryption means the state object is encrypted before it reaches S3, so a leaked bucket yields ciphertext; Terraform's model relies on S3 server-side encryption and leaves local state plaintext. For a sovereignty-minded operator, that difference is not academic — it is the difference between "a stolen backup is useless" and "a stolen backup is a credential dump."

21. The TACOS Landscape

TACOS — Terraform Automation and Collaboration Software — is the managed layer that runs plans and applies on your behalf, with policy, drift detection, and collaboration. Before the fork, HCP Terraform was the dominant option. After it, Spacelift, Scalr, env0, and Atlantis all added first-class OpenTofu support, several making it the default engine. This is the quiet winner of the fork: competition in the TACOS layer increased because a foundation-governed engine gave vendors confidence to build on it without single-vendor license risk. If you are choosing a TACOS in 2026, the question is no longer "does it support OpenTofu?" (they all do) but "which workflow, policy engine, and price fit my team?" — and you can switch engines under most of them with low friction.

22. Common Pitfalls

The pitfalls are consistent across both engines. Pitfall one: state drift, where someone clicks in the console and Terraform/OpenTofu no longer reflects reality — mitigated by drift detection and a "console changes forbidden" culture. Pitfall two: storing secrets in state, addressed by OpenTofu's ephemeral values or by referencing a secrets manager at runtime rather than hardcoding. Pitfall three: a monolithic root module with thousands of resources, which makes plans slow and blast radius huge — split into workspaces or stacked modules. Pitfall four: ignoring the dependency-lock file, which pins provider versions and prevents surprise breaking changes. Pitfall five, the one this article exists to prevent: assuming the MPL license you trusted in 2022 still applies to new Terraform versions — it does not, and OpenTofu is the MPL continuation.

23. Terraform/OpenTofu in CI/CD

The mature pattern is to run plan on every pull request and apply on merge to a protected branch, with the TACOS or a CI runner holding the state lock. Both engines support this identically at the CLI level. The fork's impact here is mostly about which binary your pipeline invokes and whether your policy engine cares about the BSL. For open-source-only shops, OpenTofu removes the need to justify BSL compliance to a legal reviewer on every audit. For HCP-shop teams, the pipeline is already wired to Terraform Cloud and the switching cost is the platform, not the CLI. Either way, the CI/CD pattern is stable and well-documented; the license is the only new variable, and OpenTofu neutralizes it.

24. Security and Secrets Hygiene

Because state can contain secrets and because IaC has the keys to your entire cloud, security hygiene is non-negotiable. Use a remote backend with encryption at rest; prefer OpenTofu's client-side state encryption so local copies and plan files are ciphertext; scope provider credentials with least privilege (a Terraform/OpenTofu role should only be able to create what your config creates); and never commit .tfstate or variable files with real secrets to git — use a secrets manager or the ephemeral-values feature. Enable plan review on every change so a malicious or mistaken diff is caught by a human before it applies. The BSL-versus-MPL question is real, but the bigger daily risk is a leaked state file, and OpenTofu's encryption posture is the stronger default for teams that cannot afford a slip.

25. The Five-Year Outlook

The fork is now past its awkward phase. Expect Terraform and OpenTofu to keep diverging on features (OpenTofu's community-driven RFC process versus IBM's product roadmap) while sharing the HCL language and provider protocol for the foreseeable future. The CNCF acceptance hardens OpenTofu's neutral governance, and the HCP Terraform free-tier changes push more teams to evaluate it. The safe prediction: OpenTofu becomes the default for new open-source-aligned IaC, Terraform remains the enterprise-HCP choice, and the shared language keeps migration cheap. The durable lesson is the same across this whole series: a license you trusted can change, and a foundation can rebuild — so choose the foundation when you can.

26. A Minimal Working Example

Seeing the shape of the tool helps. A minimal OpenTofu/Terraform configuration that provisions an AWS S3 bucket and outputs its name looks like this: you declare a provider "aws" block with a region, a resource "aws_s3_bucket" with a bucket name, and an output block exposing the name. Run init to fetch the provider, plan to preview the change, and apply to create it. The same file runs on both engines because the provider protocol and HCL are shared. The only difference is the binary you invoke — terraform or tofu — and, if you use OpenTofu 1.7+, you can wrap the state in client-side encryption so the bucket's metadata never lands in plaintext. This thirty-line example is the entire value proposition: declarative, reviewable, reproducible infrastructure. Everything else in the ecosystem — modules, remote state, TACOS, policy — is scaffolding around this core loop of init, plan, apply.

27. Terraform vs the Other IaC Options

It is worth situating the fork in the wider IaC field. AWS CloudFormation is the cloud-native alternative but locks you to AWS and lacks the provider breadth. Pulumi lets you write infrastructure in general-purpose languages (Python, TypeScript, Go), which some teams prefer for complex logic, though it introduces a different toolchain and its own licensing considerations. Ansible is imperative and better for configuration management than provisioning. Kubernetes operators handle in-cluster resources. Terraform/OpenTofu sit in the sweet spot of declarative, cloud-agnostic, provider-rich provisioning — which is why the fork matters to so many teams. The BSL change did not make Terraform obsolete; it made "which engine" a real question, and OpenTofu is the answer for teams that want the Terraform model without the license ambiguity. For most greenfield cloud work in 2026, OpenTofu plus a TACOS is the recommendation; reach for Pulumi only when you genuinely need procedural logic in your infrastructure code.

28. The Provider Ecosystem and How It Works

The provider architecture is why Terraform and OpenTofu are so broadly useful. A provider is a plugin that translates HCL resource declarations into the API calls of a specific platform — AWS, GCP, Azure, Kubernetes, Cloudflare, GitHub, and literally thousands more. The two engines share the same provider protocol and the same provider binaries, which is a large part of why the fork is viable: the entire ecosystem of providers works on both. Providers are versioned and pinned via the dependency-lock file, so you control when a provider updates and can review breaking changes. The registry model means you rarely write raw API calls; you declare intent and the provider handles the imperative details of creating, updating, and deleting resources to match. This is the durable advantage over click-ops and bespoke scripts, and it is fully preserved across the fork. The only provider-related caveat is HCP-specific resources, which tie you to Terraform's commercial platform and are the one place the engines are not interchangeable.

29. Drift Detection and Day-Two Operations

Provisioning is the easy day; operating is every day after. Drift — the gap between declared state and reality caused by out-of-band console changes — is the chronic disease of IaC. Both engines surface drift through plan (which shows what would change to reconverge) and, in managed TACOS, through scheduled drift detection that flags resources someone mutated by hand. Day-two operations also include state refactoring (state mv to rename or move resources without recreating them), importing existing infrastructure under management (import blocks, which OpenTofu extended with for_each support in 1.8), and safe destruction in non-production. The fork's impact on day-two work is minimal at the CLI level, which is the quiet win: the operational muscle memory you built on Terraform transfers almost entirely to OpenTofu. The license question is a one-time architecture decision; the day-two discipline is the same engine either way.

30. Environment Promotion, Workspaces, and Terragrunt

A mature IaC practice promotes infrastructure through environments — dev, staging, production — rather than editing one state by hand. Both engines support workspaces (isolated state within one configuration) and, more robustly, the pattern of separate state per environment via directory or backend key. Terragrunt, a thin wrapper, became popular for DRY-ing up repeated OpenTofu/Terraform across many modules and environments, and it works on both engines. The fork does not disrupt this: your environment strategy is CLI-agnostic. The one place promotion gets engine-specific is if you use HCP Terraform's built-in environment and policy features, which lock the workflow to Terraform's commercial platform. For an OpenTofu shop, Terragrunt plus a TACOS (or plain CI) gives you environment promotion, dependency management, and policy without the BSL exposure. The lesson recurs: the open engine preserves your architectural freedom, while the commercial one trades some of that freedom for integrated convenience — a fair trade for some teams, a risk for others, and a choice you should make deliberately rather than by default.

31. Getting Started: Your First Plan in Ten Minutes

The fastest way to understand the fork is to run both engines against the same file. Install tofu and terraform, write a ten-line HCL file that creates an S3 bucket or a local file resource, and run init then plan. You will see the same output, the same diff, the same proposed actions. Now enable OpenTofu's state encryption block and re-run plan — you will see the state and plan files are encrypted on disk, the feature Terraform's CLI lacks. This ten-minute exercise makes the abstract license difference concrete: same language, same provider, different governance and different security posture. From there, point the backend at S3 with a lock table, add a second resource, and you have a real infrastructure definition under version control. The takeaway is that adopting OpenTofu is not a rewrite — it is a binary swap plus, optionally, a few lines for encryption you could not have had on Terraform anyway. When you graduate from the ten-minute demo to CI, the change is equally small: replace the terraform binary in your pipeline with tofu, point it at the same backend, and pin your providers. Most teams report the cutover taking an afternoon, not a quarter, because the language, providers, and state format are shared. The risk you eliminate — a license that can change under a vendor with a revenue mandate — is permanent, while the effort is one-time. If you later decide you need HCP Terraform's first-party managed platform, the path back is also a binary swap, so the fork gives you optionality rather than lock-in. That reversibility is the quiet superpower of a wire- and state-compatible fork: you can choose, and you can change your mind.

32. Reading the License File (So You Don't Get Burned)

The single most useful habit this series can leave you with is reading the LICENSE file of any dependency before you standardize on it — and re-reading it on major version bumps. For Terraform, that means understanding that 1.5.x is MPL and 1.6+ is BSL, and that "free for non-competitive use" is a phrase a lawyer wrote, not a guarantee. For OpenTofu, the LICENSE is MPL 2.0, full stop, and the Linux Foundation governance means it cannot quietly change. Make license review a checklist item in your architecture standards alongside security and cost, because the license is the one input that can retroactively change your rights. The teams that got burned by the 2021–2024 relicensing wave were the ones who assumed the license was a permanent property of the software. It is not; it is a promise from the current rightsholder, and a foundation is a more durable promisor than a venture-backed company with a revenue mandate. Concretely, add a step to your intake process: when a team proposes a new infrastructure dependency, someone checks the current LICENSE and the project's governance (foundation-backed or single-vendor), notes the major-version license boundary, and records it in the architecture decision log. It takes five minutes and would have saved countless teams from the 2023 surprise. The fork proved the community can rebuild a foundational tool in a week; the least we can do is read the room before we commit.

33. Bottom Line

Terraform did not die in 2023; it bifurcated. The MPL core lives on as OpenTofu under the Linux Foundation — equally capable, foundation-governed, and unambiguously open — while Terraform itself became a BSL-licensed, IBM-owned platform with first-party managed services. For new projects, OpenTofu is the recommendation: better license certainty, client-side state encryption, and governance that cannot pull the rug. For teams already deep in HCP Terraform, the switch is a platform migration, not a CLI swap, and the calculus is different. Either way, verify the current license of whatever you deploy against the project's LICENSE file — not against a blog post from before 2023 — because in this corner of infrastructure, the license is the feature that changed everything. Three years after the fork, the only real mistake left is indecision.

Terraform: The 44k-Star IaC Tool That Went Source-Available and Spawned OpenTofu — A License Fork Deep Dive