HashiCorp announced today that they’re relicensing all their products — Terraform, Vault, Consul, Nomad, Packer, Vagrant, Waypoint, and Boundary — from the Mozilla Public License 2.0 (MPL 2.0) to the Business Source License (BSL 1.1). The change takes effect immediately for new releases. If you use any of these tools, and if you’re doing DevOps in 2023 you almost certainly use at least Terraform, this affects you.
The infrastructure-as-code community is reacting with a mix of anger, resignation, and frantic evaluation of alternatives. Let me walk through what’s actually changing and what it means.
What the BSL Actually Means#
The Business Source License, originally created by MariaDB, is not an open-source license. The Open Source Initiative (OSI) does not recognize it as such, and it doesn’t meet the Open Source Definition. Under BSL 1.1, you can view, modify, and redistribute the source code, but you cannot use it for “production” purposes that compete with HashiCorp’s commercial offerings.
The specific restriction in HashiCorp’s BSL is: you cannot provide a competing commercial product or service that uses the covered code. After four years, the code converts to MPL 2.0 — so today’s Terraform release will become genuinely open source in 2027. But the current, actively maintained version? That’s BSL.
For most end users who deploy their own infrastructure using Terraform, nothing changes in practice. You can still use Terraform to manage your AWS, Azure, or Google Cloud resources. The restriction targets companies that offer Terraform-as-a-service or embed Terraform functionality in competing infrastructure management platforms.
Who This Actually Affects#
The obvious targets are companies that compete with HashiCorp Cloud Platform (HCP): Terraform Cloud competitors like Spacelift, env0, and Scalr. Managed service providers who offer Terraform-based infrastructure management are also in the crosshairs. These companies have built businesses on top of HashiCorp’s open-source tools, and the BSL specifically targets their use case.
But the restriction’s boundaries are ambiguous enough to create uncertainty for a much wider set of users. If your company uses Terraform internally but also sells infrastructure services, does that count as “competitive”? If you’ve built internal tooling around Terraform that you want to productize, are you in violation? HashiCorp has published an FAQ attempting to clarify these boundaries, but licensing ambiguity is itself a risk.
For platform teams inside enterprises, the practical impact may be minimal today. But the precedent it sets — and the possibility of future restriction changes — introduces a new category of risk into your infrastructure tooling decisions.
The Open Source Trust Deficit#
HashiCorp’s decision follows a pattern we’ve seen repeatedly: MongoDB (SSPL), Elastic (SSPL/Elastic License), Redis (Commons Clause, then RSAL), Confluent (Community License), and now HashiCorp (BSL). Each company follows the same playbook: build an open-source project, attract contributions and adoption, build a business around managed services, then change the license when AWS or other cloud providers start offering competing managed services.
I understand the business logic. Cloud providers genuinely do free-ride on open-source projects, offering managed versions without contributing proportionally back. HashiCorp’s annual revenue is around $500 million, but their market cap has been declining, and the pressure to protect their Terraform Cloud business is real.
But each license change erodes trust in the “open-source to commercial” model. Companies evaluating infrastructure tooling now have to factor in license change risk. “It’s open source” used to mean something about long-term availability and control. Now it comes with an asterisk: “until the company decides it’s not.”
The Technical Implications#
From a technical standpoint, the last MPL-licensed version of Terraform (1.5.x) remains available and can be forked. The Terraform provider ecosystem — all those AWS, Azure, GCP, and community providers — are separate projects with their own licenses, and they remain open source.
This means a community fork is technically feasible. The question is whether anyone has the resources and motivation to maintain a fork of something as complex as Terraform’s core. Early conversations are already happening in the community about exactly this possibility. The providers can be shared between the original and any fork, which lowers the barrier significantly.
For teams currently using Terraform, my immediate recommendation is: don’t panic, but start planning. Pin your Terraform version, evaluate your actual exposure to the BSL restrictions, and begin assessing alternatives like Pulumi, CDK for Terraform, or even CloudFormation/ARM/Deployment Manager if you’re single-cloud. None of these are drop-in replacements, but understanding your options now is better than scrambling later.
The Broader DevOps Tool Landscape#
This move has implications beyond Terraform. HashiCorp’s entire portfolio is affected. Vault is widely used for secrets management. Consul for service discovery. Packer for image building. If you’ve built your infrastructure platform on the HashiCorp stack — and many organizations have — you’re now dependent on BSL-licensed software across multiple critical components.
The good news is that the DevOps tool landscape has matured significantly. For almost every HashiCorp product, credible alternatives exist. The bad news is that migration is expensive, especially for deeply integrated tools like Vault where the switching costs include re-encrypting secrets, updating every application’s secrets retrieval logic, and retraining operations teams.
My Take#
I’ve used Terraform since the 0.x days. I’ve written providers, built modules, and advocated for infrastructure as code in organizations that were skeptical. This license change doesn’t erase any of that value, but it does change the relationship.
The BSL isn’t the end of the world for most users. But it is a signal. It tells us that “open source” in the VC-backed infrastructure space is a growth strategy, not a commitment. And it means that our technology choices need to account for licensing risk alongside technical merit.
If you’re starting a new project today, I’d look hard at the alternatives before defaulting to Terraform. If you’re already invested, keep using it — but start treating your Terraform investment the way you’d treat any proprietary vendor dependency: with clear exit criteria and a migration plan on the shelf.
The open-source model isn’t broken, but the “open-source-until-IPO” model clearly is.