HashiCorp & Terraform Risks: what is the appropriate mitigation?

Introduction

Since August 2023, there has been ongoing discourse surrounding HashiCorp’s licensing changes and the implications for enterprise Platforms that rely on its products, particularly Terraform and Vault. This change has sparked significant concern and uncertainty among organisations that have built their Enterprise Platforms using these Products.

Looking specifically at Terraform, this blog adopts a Program Management perspective to evaluate the risks posed to Enterprise Platforms by these August 2023 licence changes in order to answer the following questions:

• How do we mitigate the risk of this uncertainty?
• Are any mitigation options valid?
• Will my Platform circumstances impact my mitigation choice?

Background

HashiCorp transitioned to a Business Source License (BSL) in August 2023, significantly affecting the future of Enterprise Platforms utilising Terraform and other HashiCorp products.

Examining Terraform specifically, from version 1.5.7 onwards, the BSL prohibits competitors from incorporating, embedding, or distributing new Terraform versions. The wording of the BSL raised severe concerns within the cloud native community about Terraform’s future use, concerns which were amplified further when HashiCorp announced its partnership with IBM in April 2024.

Risks

Below are the two risks for which we will be looking to find mitigations.

R-001 — HashiCorp / Terraform usage in Production

There is a risk that HashiCorp will consider an Enterprise Platform utilising Terraform beyond version 1.5.7 a competitor and in violation of its BSL licence.

The material released from HashiCorp needs to clarify whether an Enterprise Platform providing services to customers can utilise Terraform for Infrastructure as Code in production or whether they would be considered a competitor by doing so.

R-002 — Terraform Commercial Uncertainty

There is a risk that HashiCorp will change its licensing costs and begin charging Terraform users from version 1.6 onwards.

While HashiCorp’s current statement is that users are free to continue using Terraform, this is not guaranteed to continue, especially given IBM’s recent acquisition.

Project Management Risk Log

We have a full document where both the risks and mitigations are explored, assessed and rated here: PM Risk Log.

Mitigations Assessed

To mitigate the risks R-001 and R-002, we explored six different mitigation options, assessing the benefits, disadvantages, and effort involved with each option.

For the full details, see the detailed write-up and the PM Risk Log, but we will include a short summary in the blog.

M-001 OpenTofu: OpenTofu is a Terraform fork created in response to HashiCorp’s switching to its BSL license. The codebases are extremely similar, making this a like-for-like alternative to Terraform.

M-002 Pin Terraform at Version 1.5.7: Given that both risks can only materialise in future versions of Terraform, it is possible to pin your Platform’s Terraform version at V1.5.7 as a valid mitigation to R-001 and R-002.

M-003a Cloud Provider Products: The first “alternative product” to Terraform will depend on your chosen cloud provider. You may want to consider the respective product(s) to align your cloud infrastructure with your IaC product. Below, we look at three of the most popular Cloud providers and their respective IaC products:

• AWS -> AWS CloudFormation
• Azure -> Azure ARM Templates
• GCP -> Google Deployment Manager

M-003b Pulumi: Another “alternative product” to Terraform is Pulumi. From Pulumi’s Website:

“Pulumi is a modern infrastructure as code Platform. It leverages existing programming languages—TypeScript, JavaScript, Python, Go, .NET, Java, and markup languages like YAML—and their native ecosystems to interact with cloud resources”.

M-003c In-House Developed Product: On the face of it, developing your own IaC product seems completely viable. Negating the principal risks and giving ownership and control of the product would prevent a licensing change in the future, as it has with Terraform. However, delving deeper has significant implications and really is a mitigation to avoid.

M-004 Accept the risk: Essentially, this is the “do nothing” / “carry on” approach. If you believe no mitigations are appropriate, or you think the cost and impact of mitigating are more significant than the combined likelihood, cost, and effort should the risks materialise.

Conclusion

Whilst we have assessed several mitigations available, three stand out as potential options depending on your circumstances.

For the full results of our evaluation, read the complete and detailed write-up here: The HashiCorp & Terraform Risks.

Scenario 1 — Existing Platform with Engineering bandwidth

In this scenario, there is value in making the move from Terraform to OpenTofu (M-001). While this option becomes less appealing over time, if your engineering team currently has the bandwidth, mitigating these risks while the codebases are similar is a very appealing option.

Scenario 2 — Existing Platform with no Engineering bandwidth

If your existing team is fully utilised with pressing new features and addressing critical CVE’s amongst other important tasks, our recommendation is to pin Terraform at version 1.5.7 (M-002). The benefit of this is you give yourself and your team time to see if HashiCorp releases any new information in the future. With little engineering effort, you can remove the risks and have the flexibility to pivot in the future should you need to.

Scenario 3 — Building a New Platform

Whether you are in the design stages or having early discussions about creating a Platform, both Pulumi (M-003b) and OpenTofu (M-001) are the standout candidates. Pulumi will be an attractive candidate for your engineering teams, given the flexibility in languages you can use. On the other hand, OpenTofu is the closest direct replacement for Terraform, which will remain Open Source for its lifetime, given the nature in which it was created. These mitigation options will allow you to design and build a platform without the potential impacts of R-001 and R-002.

Full Graph Summary

The above summary shows the top-performing mitigations in our assessment. The size of the bubbles indicates varying degrees of effort involved in each option, with Pinning Terraform requiring the least effort and migrating to Pulumi requiring the most effort of the three.

Contributing Documents

The full paper which goes into further details of the mitigations assessed can be found here: The HashiCorp & Terraform Risks.

You can find the full Project Management Risk Log, which contains the details of how each risk and mitigation’s values were assessed and calculated, here: PM Risk Log.

This document references the LiveWyer architectural best practices and design principles. The full details are available on our website: LiveWyer Platform Design Principles.