Terraform Operations #7 OpenTofu and Licensing: The BSL Switch, the IBM Acquisition, and How to Choose

Infrastructure Terraform IaC OpenTofu
5 min read

The final part of this track is not about code but about the tool itself. It also settles a promise made back in Basics #1: “there is a fork called OpenTofu, and we will cover how to choose at the end.” Anyone learning Terraform today is effectively standing at a fork in the road. This part walks through why that fork appeared, what actually diverged, and how to choose — and then wraps up the track.

What happened: a timeline from 2023 #

  • 2023-08: HashiCorp switched Terraform’s license from open source (MPL 2.0) to the BSL (Business Source License). The abrupt change triggered community backlash, and within weeks OpenTofu launched as a fork of the last open-source version (1.5).
  • 2024: OpenTofu began shipping independent releases under the Linux Foundation, starting with 1.6, and feature divergence from Terraform began.
  • 2025-02: IBM completed its acquisition of HashiCorp ($6.4 billion). Terraform became part of the IBM product portfolio.
  • 2025-04: OpenTofu was accepted into the CNCF (Cloud Native Computing Foundation), making it a project of the same foundation as Kubernetes.
  • 2026, today: numbers vary by survey, but OpenTofu adoption sits in the low teens of percent, and Terraform remains the majority. The share of teams putting OpenTofu on their evaluation shortlist, however, runs much higher than that.

What the BSL actually prohibits #

License debates overheat easily, so let’s narrow this down to the facts. Under the BSL, Terraform’s source is public, it is free to use, and using it to manage the infrastructure of a commercial service is also fine. What is prohibited is embedding Terraform in a product that competes with Terraform. In other words, companies running businesses like the execution platforms we saw in #6 are directly affected, while for most end users managing infrastructure there is no practical legal change. The fork happened anyway because the issue was trust more than license text. A license changed once can change again, the footing of the tool companies that made up the ecosystem was shaken, and the IBM acquisition reconfirmed the worry about “a tool hanging on the decisions of a single company.” That is why OpenTofu puts its foundation home (the Linux Foundation, later the CNCF) front and center.

What has diverged #

In the early days of the fork the two tools were effectively identical, but release after release the divergence became real.

  • Syntax and core: still largely compatible. The HCL, state, module, and workflow concepts you learned in this track carry over to both as-is. The provider and module ecosystems are mostly shared as well (OpenTofu runs its own registry).
  • OpenTofu-specific: its pattern is to ship long-requested community features first — most notably state encryption (encrypting the state file itself at rest).
  • Terraform-specific: the newest language features sometimes land in Terraform first, like the ephemeral and write-only family we used in Practice #6, and the commercial ecosystem — HCP Terraform and Sentinel — is Terraform-only.

The practical implication is clear: concept learning is a shared asset, and portability breaks first in code that depends on specific new features. Within this track, write-only arguments are the main thing to check.

How to choose #

  • Teams already on Terraform: there is no reason for a forced migration. The BSL imposes no practical constraint on end users, and switching costs are real. Just make the decision knowing that every new-feature dependency you add is one more bridge you cannot cross back over.
  • Teams starting fresh: if foundation governance and license stability matter most, OpenTofu; if you want the HCP Terraform ecosystem, Sentinel, or the newest language features, Terraform. Job postings still mostly say Terraform, but since the concepts are shared, the difference from a resume perspective is small.
  • Organizations building execution platforms or tools: you are directly in the BSL’s scope, so do not embed Terraform without legal review. Here OpenTofu is the default.

Migration itself tends to go smoothly for versions near the divergence point (1.5/1.6), since state is read as-is; the further apart the versions, the more the first step is an audit of which features you use. The official migration guide provides checklists per version path, so treat checking the latest guide before running anything as a precondition.

Closing the track #

Nine parts of the basics series covered syntax and principles, ten practice parts built the entire myapp infrastructure, and seven operations parts covered team workflow and governance. If I had to pick one theme running through all 26 parts, it is turning infrastructure decisions into reviewable records. Starting with the habit of reading plans (Basics #2), then guardrails (Basics #7), secrets (Practice #6), CI gates (#1), and policy (#4) — all of it was a variation on that theme. If you want to cap the learning with a certification, HashiCorp’s Terraform Associate is the standard; the exam was revised from 003 to 004 starting January 2026, so check the current code at the time you register and prepare for that. The basics and practice parts of this track cover most of the exam scope.

Recap #

What this post covered.

  • The timeline of the current landscape: the 2023 BSL switch → the OpenTofu fork → the completed IBM acquisition and CNCF acceptance in 2025
  • What the BSL prohibits is embedding in competing products; most end users managing infrastructure face no practical constraint. The fork was driven by governance trust more than license text
  • Syntax and concepts remain largely shared; divergence starts with new features, like state encryption (OpenTofu) and ephemeral/write-only (Terraform)
  • Existing teams default to staying, new teams choose between governance and ecosystem, and tool-building organizations default to OpenTofu
  • The Associate certification is on 004 as of 2026-01. This track’s basics and practice parts cover most of the exam scope

The 26-part Terraform track concludes here. As next steps for infrastructure code, GitHub Actions automation extending this track’s CI parts and a combination with the Kubernetes track are the natural neighbors. Either way, the code from this track is your starting point as-is.

X