HashiCorp BSL for Software Vendors and ISVs

A software vendor lives closer to the licensor than an end user does. When an ISV builds a product on top of someone else's software and sells access to it, the line between using a tool and competing with its maker grows thin. The Business Source License was written with this exact relationship in mind. For an ISV, the right response to the HashiCorp change is not to assume the worst or to ignore it, but to map precisely how the product uses the covered component and to test that use against the competitive restriction.

Why ISVs carry the most concentrated exposure

As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1, which restricts competitive production use and converts to an open license after a delay, commonly four years. The restriction targets offerings that compete with HashiCorp's commercial products. An enterprise managing its own infrastructure rarely competes with HashiCorp. An ISV that embeds Terraform in a platform and offers infrastructure provisioning to its own customers may be doing exactly that. The same component that is low risk for an internal user is high risk for a vendor, because the vendor's business model is the thing the restriction was designed to reach. The general shape of the competitive test is set out in is your Terraform use competitive under the BSL.

The patterns that put an ISV inside the restriction

Several common product patterns deserve careful testing. Embedding a HashiCorp product as a component customers rely on, exposing its functionality through your own interface, bundling it into an appliance or image you ship, or offering it as a managed capability within your platform all move toward the competitive line. None of these is automatically a breach, because the deciding factor is competition with the licensor rather than the mechanism of distribution. But each is the kind of use that an ISV should map deliberately rather than treat as settled. Where the product offers the covered functionality as a service, the analysis overlaps with the service patterns covered in relicensing and cloud and managed service use.

The options an affected ISV holds

An ISV that finds itself inside the restriction has a familiar set of paths, each with a cost to cure. It can move to the OpenTofu fork, which continues under a recognized open source license and removes the competitive use question entirely. It can negotiate a commercial license with the vendor, which keeps the original but sets a price against the product's usage. It can redesign the product so it no longer embeds the covered component. Or it can stay on a pre change version where that remains viable for the product. The fork option and its tradeoffs are covered in the OpenTofu and Valkey fork story, and recovery and standby configurations that vendors often overlook are covered in HashiCorp BSL and disaster recovery environments.

How an ISV should approach the analysis

The work is to map the product, not the company. Identify every place the product depends on a HashiCorp component, direct and transitive, record which versions and whether they predate the change, and describe exactly how each is used and exposed to customers. Test the offering patterns against the competitive restriction and route the genuinely ambiguous questions to counsel. Where the analysis shows exposure, size the cost to cure across the available paths so the product team can choose on real numbers. A relicensing exposure review produces this analysis, and the wider context sits on the HashiCorp and Terraform pillar.

We are independent and buyer side. We take no vendor fees and resell no software, so our read of an ISV's Business Source License exposure reflects the product's risk and nothing else. This is commercial and licensing risk advisory, not legal advice. For interpretation of the Business Source License and your compliance position, engage your own counsel.