Kapari
The exam Are they accurate? The Hub Partners Demo Version française Log in Start free
Kapari Hub / Kapari Deciphers
Kapari Deciphers

Changing software licenses: the cost of restricted freedom

HashiCorp modified the license for its flagship products in August 2023, limiting competitive commercial use of its source code.

Announcing a usage restriction can cost more than expected. On August 10, 2023, HashiCorp stated that its flagship products, from Terraform to Vault, would transition from an open-source license to a license restricting competitive commercial use. The new license excludes competitive offerings. Within weeks, part of the community had announced its own version of Terraform. How can such a measure cause such a division?
Decision of August 10, 2023Published Updated

How can a flagship product's license be changed without the community creating a competing alternative?

Anticipate the reaction of historical users and offer them a clear path before restricting use. When 47 simulated voices reacted to HashiCorp's decision, a little less than half opposed it, their objection centering on the principle of the restriction itself.

At a glance
More opposition than support, with a defector on the Competitors Who Fork side, whose sticking point is the workload.
How the panel responds
Divided response
Risk the announcement goes wrong
High
What holds it back first
Disagreement on principle
Simulated panel of 47 voices
14 in favor11 unsure22 opposed

The context, in plain terms

On August 10, 2023, HashiCorp, an infrastructure software publisher, announced a license change for future versions of its products. Tools like Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer, and Vagrant, previously under the Mozilla Public License v2.0, would now fall under the Business Source License v1.1. This new license allows free access to the source code, its copying, modification, redistribution, and non-commercial use. However, it restricts commercial use under specific conditions, notably excluding competitive offerings.

HashiCorp presented this modification as effective only for future versions, not as a retroactive relicensing of all existing code. Yet, only weeks after the announcement, a public fork of Terraform, named OpenTofu, was created by part of the community. Publicly, the financial impact of this decision is not established, and it is unclear if all products were immediately affected by the BSL for each distribution channel.

The price of protection: a divided community

HashiCorp's announcement on August 10 reads in two very different ways. On the company's side, the new license shuts out competitive offerings built on its code.

But for the teams that had built their infrastructure on these tools, the same announcement reaches the foundation of their business. A little less than half of the simulated voices declared against the decision, while about one voice in four doubted its relevance. About one voice in three supported it.

Among the voices against are those of long-time free users. For them, the stakes are existential: they invested time and resources in solutions based on HashiCorp's code, and the sudden license restriction threatens the viability of their own activities. They protect freedom of use and the stability of their operations, which the decision directly impacts.

When teams have built their infrastructure on a tool, its license is part of their business plan.

The principle of freedom of use challenged

What holds it back first is a disagreement on principle: the voices against contest the legitimacy of a company to restrict the use of code that prospered thanks to collective contribution. The objection is not so much about HashiCorp's need to generate revenue, but about how it does so by, in these voices' eyes, denying the foundations of its initial success. Doubt concerns the consistency between the past and future of the software strategy.

HashiCorp's decision created a gap between the company's business logic and its community's expectations. For these voices, an open-source product's value lies in its ability to be freely used and adapted, without conditions that could hinder innovation or create de facto monopolies. The restriction is perceived as an attempt to capture profit without fully honoring the implicit commitment of the previous license.

What builds up here has a simple name, a trust deficit: one can understand the need to protect margins and still not believe the company will keep its future promises if it changed the rules mid-game. The transition from an open to a more closed model, even if not retroactive, shakes, for these voices, the trust relationship established with developers and companies that depended on its products.

A license that closes on future releases reads as a promise withdrawn, even when the past stays open.

The developer who says no to the burden of forking

The yes camp has its arguments. A late-stage venture investor, for example, supports the decision, stating, "Protecting margins ahead of the IPO was the right call, community backlash is a small price for locking in enterprise revenue and shareholder value." This perspective prioritizes short-term financial value.

We ran the exercise twice: same answer. The objection also comes from a camp that leans in favor. An independent developer, counted among the competitors who fork but reluctant to do it, opposes the decision.

What tips him is the burden: when a license closes, the work of keeping an open version alive falls to people like him.

The first one left to maintain the code is not always the one who wanted to.

For a transition that honors the past

For a leader facing a similar decision, the first step would be to precisely map the expectations of historical users and contributors. This involves understanding what they protect and how the new license affects their business model or freedom of action. The announcement must then address these concerns, proposing alternatives or compensation for those who feel wronged.

HashiCorp made its announcement on August 10, 2023, for future versions of its products. Weeks later, the community reacted by creating OpenTofu, a Terraform fork. The decision was implemented.

The case does not tell us if HashiCorp attempted to dialogue with key players before the announcement, nor the exact nature of discussions on the specific BSL conditions for each distribution. Yet, OpenTofu's rapid emergence suggests that dialogue, if it occurred, was not enough to defuse the tension. On announcement day, HashiCorp closed its license to competitive offerings; within weeks, Terraform had a competing copy, OpenTofu. That is how a trust deficit gets paid.

A license can change for future releases; trust is judged on the whole past.

Where this story comes from

What you just read comes from a rehearsal, not a report. Before a panel of 47 simulated voices, the Kapari test bench let us hear that disagreement on principle held it back first, and that an independent developer reluctant to fork, from a camp leaning in favor, opposed it. The same exercise can be run before an announcement, to hear objections and unexpected allies in time, but it says nothing about actions the company should have taken in the past.

The full simulation, on the same decision
Open the full run, the very one this article reports on: the distribution, the decision note, the dissonances, and every voice on the panel, one by one, including those that contradict the conclusion. Nothing is held back, and no account is needed.
Open the full simulation
How the panel responds
Divided response
Risk the announcement goes wrong
High
What holds it back first
Disagreement on principle

The questions readers ask

What are the risks of a restrictive license for a community product?

A restrictive license can provoke a strong community reaction, even leading to the creation of competing alternatives, as OpenTofu's emergence after HashiCorp's decision showed. The ecosystem then splits between two versions.

How should historical users' reactions to a model change be managed?

Acknowledge the past investment of historical users and offer them viable solutions for the transition. Faced with HashiCorp's decision, a simulated startup user describes a costly choice between lock-in and migration: that choice is what an announcement has to address first.

Is this a poll or a prediction?

The voices cited in this case are simulated reactions, not those of a poll or a prediction. The numbers mentioned are those of a simulated panel of 47 voices, not a share of public opinion. Facts come from dated and named sources, verified beforehand. Kapari sheds light on the decision; it does not make it.

How Kapari computes and reads its signals: the method

ShareLinkedInXE-mail

Related cases

Your next decision deserves the same scrutiny.

Run it through the test bench before you announce it: a panel of voices reacts, you read the range and you see the frictions coming.

Start free