Terraform's license now restricts competing hosted offerings

Terraform's value includes the software around it. Providers connect configuration to APIs, while automation systems arrange how teams plan and apply changes. A license that distinguishes permitted use from competing service offerings therefore affects the relationships between those systems. HashiCorp's August 10 announcement changes future product releases from MPL 2.0 to Business Source License 1.1, with a production-use grant that excludes competing hosted or embedded offerings.

The source remains available, but the permitted uses of that source change. The distinction matters for software that an organization may both run internally and incorporate into a service for others. Reading the original terms makes the difference clearer than treating availability on GitHub as a complete description of the license.

I admire what HashiCorp built with Terraform. Its reusable language above infrastructure APIs remains useful to me, including the provider model. That technical judgment does not remove my preference for permissions that allow independent implementation and distribution without asking whether a product competes with its original sponsor.

The original production grant is specific

The license file committed on August 10 contains the terms relevant to today's change. Its base grant permits copying, modification, derivative works, redistribution, and non-production use. Production use comes through the separate Additional Use Grant. That grant excludes offering the licensed work to third parties on a hosted or embedded basis that competes with HashiCorp's products.

This is not a general prohibition on commercial activity. The operative distinction is the form and competitive character of the offering described in the grant. An organization using Terraform to manage its own infrastructure and an organization offering a hosted Terraform-based service are examining different relationships to the licensed work. A statement that both organizations are businesses does not resolve that distinction.

The hosted and embedded language also means that distribution method alone cannot answer every question. A service can expose software through a hosted interface, while another product can incorporate it into a distributed package. The original text mentions both. Its condition concerns offering the licensed work to third parties in those forms when the offering is competitive.

The license provides an alternative if a use does not comply with the requirements in effect. A user must obtain a commercial license from the licensor or an authorized source, or stop that use. The document also provides a contact for alternative arrangements. This places some product decisions within a licensing relationship that the earlier general grant did not condition on competition.

That mechanism should be described precisely. Source availability allows inspection of how the implementation behaves. The production grant determines whether a particular use is permitted under those terms. The ability to inspect code and permission to use it in every business model are separate properties, and the new license treats them separately.

Each version has its own transition date

The original file sets the Change Date at four years after publication of the licensed work and names MPL 2.0 as the Change License. Its terms also specify the fourth anniversary of the first public distribution of a specific version, with the earlier applicable transition controlling. The document applies separately to each version, so the date can differ between releases.

That structure means the transition concerns a particular body of code. When an older version reaches its change date, that does not make every newer version simultaneously available under MPL. Each version's own timing still matters. A continuously updated product and a fixed historical version therefore have different licensing timelines.

The distinction affects maintenance planning. A competing service that cannot use a new version under the production grant cannot assume that the presence of a future MPL transition gives it immediate permission to incorporate current changes. Waiting for a version's transition is different from receiving current maintenance on unrestricted terms.

Existing MPL code supplies another separate case. The MPL license included with Terraform 1.5.4 grants rights in the covered contributions subject to its own conditions. Today's announcement concerns future releases. It does not replace the text included with that earlier version or supply that version with a new competition condition.

A dependency policy therefore needs to identify the actual version and source of code being used. The product name is insufficient. Two copies called Terraform can contain code distributed under different grants, and a source checkout can include changes beyond a previously released tag. The relevant record is the code and license associated with the selected version.

MPL imposes obligations without a competition test

The earlier MPL text includes conditions on distribution. Covered source and modifications to it must remain available under MPL, and executable distribution must provide a way to obtain the covered source. The document allows larger works combining covered software with separate material under other terms, subject to the conditions for the covered portion.

Those requirements have a different purpose from the new production-use condition. They specify responsibilities attached to covered code and its distribution. They do not ask whether the recipient's product competes with the original contributor. That difference is relevant even for a user whose present deployment remains permitted by the new grant.

MPL also treats trademarks separately from its copyright and patent permissions. It does not grant general rights to contributors' names or logos. The Business Source License file similarly withholds trademark and logo rights. Permission to reuse code has never meant an unrestricted right to represent a derivative product as the original vendor's product.

The comparison is therefore about the new restriction on use, not a claim that the previous license had no conditions. Both documents contain terms a distributor must respect. The new grant adds a question about competitive hosted or embedded offerings that changes what an independent service can do with future code.

I prefer a licensing boundary defined by the code being redistributed and the obligations that accompany it. Competition is harder to treat as an ordinary technical dependency constraint. It depends on the relationship between offerings, which may involve product positioning as well as the behavior of an executable.

Providers and the engine are separate dependencies

The announcement says HashiCorp's APIs, SDKs, and almost all other libraries remain under MPL. That matters because Terraform's ecosystem includes components beyond the engine. A license change to a product does not establish the license of every library used to integrate with it. Each component retains its own source and terms.

For a provider author, the practical question is which dependencies the provider actually incorporates. Using an SDK and copying implementation code from the engine are different acts. The announcement's distinction between products and libraries makes it necessary to identify the relevant component before drawing a conclusion about the effect on an integration.

For an automation service, the relationship can run in the other direction. The service may execute Terraform as a program without incorporating its implementation into a provider. The production-use condition still asks about an offering of the licensed work on a hosted or embedded basis. Separating binaries into processes does not by itself establish which permissions apply.

This is why an inventory of executable versions and copied source is more useful than a single organization-wide label such as a Terraform user. The same organization can operate internal infrastructure, publish a provider, and sell a hosted automation product. Those activities can involve different components and different grants. The license text supplies the conditions, while the dependency inventory identifies the work to which they apply.

Maintenance becomes part of the licensing choice

HashiCorp presents the change as a way to protect continued investment from competing vendors that benefit without materially contributing. That is the company's stated rationale, not evidence that every independent service has the same relationship to the project. The production grant implements the company's chosen restriction across the category described in its terms.

For an infrastructure dependency, current maintenance is part of the practical cost of a license decision. Staying on previously obtained code preserves that code's existing terms, but it does not automatically provide future bug fixes under the same terms. Moving to later code requires evaluating the grant attached to it. A per-version transition several years away does not eliminate that choice for present operations.

The original license also requires the license notice to accompany original and modified copies and derivative works. It states that those works remain subject to the license and that a violation terminates rights under its terms. These provisions make version provenance relevant to redistribution as well as to deployment. An independent build needs a record of which implementation changes it contains and which license accompanies them.

The immediate result is a changed dependency contract for future Terraform code. Source inspection remains available, and the production grant allows substantial use. A service offering the licensed work to others must also account for the competitive-use condition. That requirement now belongs alongside the implementation version when deciding which Terraform release an infrastructure product can incorporate.