Does the Terraform BSL license affect your company

An internal platform team runs Terraform to provision infrastructure for its own company's products and teams. This is the situation the Business Source License was least likely to restrict, because the company is not offering a competing product to third parties. The licensing question to take to counsel is narrow: confirm that the internal use falls within the production use permitted by the license text, and confirm that no internal business unit is billed as a separate commercial service. Illustrative example: a bank's platform group provisions networks and clusters for its own lines of business, and no outside party consumes that tooling. This setup usually points toward staying on Terraform under a documented BSL review, provided counsel agrees with the reading. Teams that want a license with no field-of-use limits and a neutral governance model often still choose OpenTofu for this case.

• Internal production use: Running Terraform to manage your own infrastructure is the core use the license is designed to allow, so confirm the wording with counsel.
• Internal shared services: If other departments are charged internal rates, ask counsel whether that counts as offering a service to third parties.
• Contractors on your team: Ask whether contractors who operate the platform on your behalf change the analysis.
• Version pinning: Record which Terraform version is in use, since the license terms apply to each release.
• Governance preference: Weigh whether a Linux Foundation and CNCF governed fork matters to your architecture board.

Confirm the internal scope in writing with counsel before the next major upgrade.

A SaaS vendor that exposes infrastructure provisioning to its customers, for example through a self-service portal that runs Terraform behind the scenes, sits closest to the case the BSL was written to address. The licensing question is whether the Terraform functionality is a competitive offering in the license sense, meaning whether customers can use it in a way that substitutes for HashiCorp's own products. Counsel should read the definition of a competitive offering closely and assess how customers actually interact with the tooling. Illustrative example: a vendor's portal lets customers request a managed environment, and the vendor's backend runs Terraform to create it. This case tends to point toward a move to OpenTofu, or a documented legal opinion that the use is outside the restriction.

• Competitive offering test: Ask whether customers could substitute your service for HashiCorp's hosted products.
• Customer-visible tooling: Note whether customers can write or run Terraform configurations directly.
• Hidden versus exposed use: Document whether Terraform is an internal implementation detail or a product feature.
• Contract terms: Review customer agreements for any statements about the tooling used.
• Migration cost drivers: Count the pipelines, modules and customer-facing workflows that would change.

Confirm with counsel whether the offering is competitive before committing to either path, and record that decision.

A consultancy or managed service provider that runs Terraform for clients is in a different position from an internal team. The work is performed on behalf of third parties, and the provider may be delivering infrastructure operations as a paid service. The licensing question is whether running Terraform for clients, with the provider's own pipelines and state, amounts to a competitive offering or a permitted use under the license. Counsel should look at whether the provider's service includes a hosted run and state platform that competes with HashiCorp's products. Illustrative example: a managed service provider operates client environments through its own Terraform runner and state store. This pattern often points toward moving the tooling to OpenTofu, since that removes the question for each client engagement.

• Per-client scope: Ask whether each client's environment is run from a shared platform that the provider operates.
• Hosted run service: Determine whether clients can access a run or state service you provide.
• Client-owned state: Clarify whether clients own their state and can take it elsewhere.
• Contract language: Check statements in client contracts about tooling and licensing.
• Operational effort: Estimate the cost of moving every client pipeline, which grows with the number of engagements.

Confirm both the service model and the client contract language with counsel before you reuse the same tooling across clients.

A software vendor that bundles Terraform inside its own product, for example by shipping the binary or invoking it from a deployment feature, faces a distribution question. Embedding a licensed tool changes what the vendor delivers to its customers, and the license terms govern whether that bundling is allowed and what notices or restrictions apply. Counsel should examine whether the product competes with HashiCorp's offerings and whether the bundled Terraform is a component the customer can separate from the product. Illustrative example: a vendor ships a deployment product that calls Terraform on the customer's own servers to create resources. This case often points toward OpenTofu, because it avoids an ongoing review of each release and each bundle version.

• Distribution model: Establish whether you ship the binary, call it from your code, or only document its use.
• Competitive positioning: Compare your product's features with HashiCorp's offerings in the license definition.
• Version lock-in: Track which Terraform release each product version bundles.
• Provider and module ecosystem: Confirm which providers your customers depend on and their compatibility with OpenTofu.
• Customer communication: Plan how release notes will explain any change in the bundled CLI.

Confirm the distribution model and the competitive analysis with counsel before the next product release.