Terraform License Change: BSL vs Open Source Guide | Harness Blog

Picture this. What should have been a routine Infrastructure as Code upgrade suddenly triggers a legal review, a compliance escalation, and an awkward platform meeting nobody planned for. Just the kind of chain reaction the Terraform license change set off for many teams, often long after the technical work was already done.

When HashiCorp announced its move from the Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL) in August 2023, the reaction extended beyond ‘just noise’ pretty quickly. It exposed how deeply Terraform had been assumed to be “safe, open, and predictable” infrastructure glue. Overnight, teams who thought they were managing purely technical risk found themselves pulled into licensing discussions they were never set up to handle.

The question quickly shifted from what changed to what does this mean for how we run infrastructure going forward?

Understanding the Terraform BSL License and What Changed

Before August 2023, Terraform’s open source MPL 2.0 license allowed broad reuse, modification, and redistribution, including for commercial services. This model made Terraform an easy default for internal platforms, consultancies, and SaaS providers building IaC-powered offerings. It removed friction, and over time, that frictionless adoption became an assumption.

The Business Source License changes that calculus. Under the Terraform BSL license, use is still permitted for many internal scenarios, but explicitly restricted when Terraform is used to build competing commercial services. That distinction matters more than it first appears.

If you are:

• Operating an internal platform team offering IaC as a shared service.
• Running managed infrastructure for customers.
• Embedding Terraform into a commercial product.

You are no longer operating in a clearly open space.

The HashiCorp license change paired legal challenges with uncertainty. Legal and compliance teams dislike ambiguity, and infrastructure teams rarely want to be the ones explaining why a core automation tool might fall into a gray area six months from now.

This is the context in which the BSL vs open source discussion actually matters: not ideology, but operational predictability.

OpenTofu vs Terraform: Why an Open Baseline Matters

In response to the license change, the community did what it has done many times before: it forked. OpenTofu emerged as a continuation of the last MPL-licensed Terraform release, governed under the Linux Foundation with an explicit commitment to open, community-driven development.

From a practical perspective, OpenTofu started life as a drop-in replacement. Existing configurations, state files, providers, and modules continued to work. That was intentional. 

The goal was continuity without legal ambiguity.

Now, you and your team might ask, what makes OpenTofu compelling aside from feature novelty? And the biggest factor is governance clarity. OpenTofu provides an open source IaC tool whose roadmap, licensing, and contribution model are not tied to a single vendor’s commercial strategy. For organizations designing or evolving IaC platforms today, that matters…a lot.

Terraform, meanwhile, remains a powerful and widely adopted tool, particularly for teams already invested in Terraform Cloud or enterprise workflows. But its direction is now explicitly commercial-first. That does not make it wrong, but it does mean it is no longer the neutral baseline it once was.

This distinction is subtle but important. OpenTofu increasingly represents the default open path, while Terraform becomes a contextual choice driven by existing investment rather than long-term openness.

Common Pitfalls When Evaluating Terraform Alternatives

One of the biggest mistakes teams make after the Terraform license change is treating the decision as a simple binary swap. Replace the binary, update a few pipelines, move on. That approach works briefly, and then fails in production.

Migrating from Terraform requires more than CLI compatibility:

• Provider versions need validation.
• Module registries need auditing.
• State backends and locking mechanisms must be reviewed.
• CI/CD pipelines often hardcode assumptions that surface only under load.
  

Another common misstep is assuming ecosystem maturity is static. Terraform benefits from years of accumulated modules and institutional knowledge. OpenTofu is closing that gap quickly, but teams still need to inventory dependencies rather than assume universal parity.

Finally, many organizations ignore hybrid reality. Running OpenTofu for new workloads while maintaining Terraform for legacy environments is often the most pragmatic approach. The risk comes not from using both tools, but from managing them inconsistently.

Infrastructure as Code Licensing Is Now a Platform Concern

The Terraform license change highlighted a broader shift: infrastructure as code licensing is no longer a background concern. It is part of your platform architecture.

Infrastructure teams now have to think about:

• How licensing choices affect downstream products and services.
• Whether tooling decisions introduce future renegotiation risk.
• How easily execution engines can be swapped if assumptions change again?
  

This is where open source IaC tools regain their appeal. Not because they are “better,” but because they reduce surprise.

How Harness IaCM Supports OpenTofu and Terraform Without Lock-In

Regardless of where you land in the OpenTofu vs Terraform discussion, the operational challenge remains the same: running infrastructure changes safely, consistently, and with governance across teams.

Harness Infrastructure as Code Management (IaCM) is designed to absorb this kind of tooling evolution. It supports both OpenTofu and Terraform while treating the execution engine as an implementation detail rather than a strategic constraint.

With Harness IaCM:

• Module and Provider Registry standardizes reusable components across teams.
• Variable Sets and Workspace Templates ensure consistency without duplication.
• Default plan and apply pipelines enforce review, policy, and approval flows by default.

This approach allows teams to adopt OpenTofu where openness and governance matter most, while continuing to support Terraform where existing investment justifies it. Drift detection and policy enforcement apply uniformly, regardless of which tool is executing the plan.

Rather than forcing an immediate migration, Harness IaCM enables controlled evaluation and gradual transition, reducing the risk that licensing decisions fragment your platform.

Summary: Make Licensing a Design Decision, Not a Surprise

The Terraform license change was a reminder that infrastructure tooling choices have consequences beyond syntax and state files. The BSL vs open source distinction affects governance, risk tolerance, and long-term platform flexibility.

OpenTofu provides a clear open baseline for teams who want to avoid licensing ambiguity going forward. Terraform remains relevant, especially where commercial tooling is already embedded. The key is designing your platform so that this choice does not become a single point of failure.

Harness Infrastructure as Code Management helps teams do exactly that. By supporting both OpenTofu and Terraform with consistent workflows and guardrails, it allows organizations to adapt without disruption.

The question is no longer which tool you prefer. It is whether your infrastructure platform can handle change when the rules shift again.

Explore Harness IaCM and design your IaC workflows for flexibility, not assumptions.

Check out the Terraform to OpenTofu migration to bring this flexibility into play and take back control of your infrastructure.