Managing HashiCorp & Terraform Risks: Best Mitigations

HashiCorp & Terraform license change mitigations

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.

This document adopts a Program Management perspective to evaluate the risks posed to Enterprise Platforms by these August 2023 licence changes. Through this risk and mitigation evaluation, we will aim to answer the following business questions:

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

By examining the available mitigations, we seek to provide actionable insights and strategic guidance for enterprises navigating the uncertainty of HashiCorp’s newly adopted licensing framework.

HashiCorp & Terraform license change history

In the dynamic world of cloud infrastructure, HashiCorp established itself as a cornerstone since its inception in 2012 by Mitchell Hashimoto and Armon Dadgar. The company that brought us Terraform and Vault achieved significant milestones over the years that shaped the landscape of Infrastructure as Code (IaC).

In March 2020, HashiCorp’s influence and relevance in the Cloud Native space were cemented further when it joined the Cloud Native Computing Foundation (CNCF), underscoring its commitment to Open Source and community-driven development.

Terraform V1.0 was announced in June 2021, marking its general availability and affirming its maturity and stability for enterprises to use at the core of their Cloud Platforms.

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

Examining Terraform specifically, from version 1.5.7 onwards, the BSL states that:

“A ‘competitive offering’ is a Product that is offered to third parties on a paid basis, including through paid support arrangements, that significantly overlaps with the capabilities of HashiCorp’s paid version(s) of the Licensed Work”

Source: HashiCorp BSL

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 & Assumptions for affected organisations

When HashiCorp changed its source code licence from a Mozilla Public License v2.0 (MPL 2.0) to a Business Source Licence v1.1 (BSL), it impacted the future releases of all products. While existing versions of Terraform remain unaffected, future iterations beyond 1.5.7 will see restrictions for Enterprises and their Platforms, restricting them from leveraging new versions of Terraform in their offerings.

The above actions from HashiCorp have resulted in two main risks for organisations utilising Terraform within their Enterprise Platforms. These risks are caused by the uncertainty created from both a commercial and delivery perspective.

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.

Assumptions

The following high-level assumptions about your Platform will be used to contextualise the mitigation options assessed and discussed later in this document:

• A-001 — The risks R-001 and R-002 relate to an organisation running a large Kubernetes Platform.
• A-002 — This Platform comprises both Development and Production environments.
• A-003 — The Platform is currently using version 1.5.7 of Terraform.
• A-004 — The Platform is built using solid architecture principles. (See LiveWyer principles for building a Platform on lwy.io).

Mitigating risks from the HashiCorp license change

Mitigations are available for every risk posed to a project, even if the mitigation is simply accepting the risk. This is a feasible action if the remediation effort will cost more than the impact of the risk should it materialise. That being said, it is crucial to consider all mitigation options thoroughly before remediation implementation occurs. Often, cheap short-term fixes have costly long-term consequences, particularly when the mitigations are for large and complex Enterprise Cloud Platforms.

This document will examine each mitigation, evaluating the positives, negatives, and effort involved to provide a detailed recommendation, ultimately answering the questions at the beginning of this document.

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.

You can find more information about its history on its website, particularly its FAQ section: FAQ | OpenTofu.

Transitioning from Terraform to OpenTofu is a viable solution that offers significant advantages, such as complete mitigation of risks R-001 and R-002, active community support, and minimal retraining due to similar codebases. However, the urgency of a swift decision is crucial, as delays could lead to increased complexity and operational difficulties due to the diverging codebases. While the effort required will span multiple sprints and involve significant architectural input and documentation updates, acting quickly will make the transition much smoother. Therefore, this mitigation option becomes less appealing as time progresses.

If your team has bandwidth, and the decision can be made quickly, OpenTofu is a fantastic mitigation option.

M-002 — Pin Terraform version at 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-002 offers significant benefits both by fully mitigating risks with minimal short-term impact on the Platform and providing flexibility for future adjustments based on HashiCorp’s updates. Although it has minor negatives, mainly due to the availability of more proactive mitigations, and not being able to take advantage of any Terraform new features, the minimal engineering and documentation effort required makes M-002 an attractive option, mainly if your engineering teams are occupied with other urgent matters.

M-003 — Alternative products

Given the wide variety of “Alternative products” available to replace Terraform, we have split this section to focus on three separate examples. These examples may not cover a complete list of available products, but they cover a broad range of options.

We have chosen the following three “alternative products” to focus on:

• M-003a — Cloud Provider Products
• M-003b — Pulumi
• M-003c — In-House Development

M-003a — Cloud provider products

Depending 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

Implementing M-003a is a viable mitigation. This would fully remediate the key risks, and alignment with cloud-specific support is particularly advantageous for Platforms on a single cloud. However, this transition comes with considerable technical limitations. One of which is the potential of vendor lock-in. Whilst this is a deviation from architecture best practices and could cause resiliency issues, this may be an acceptable risk if your Platform is only ever hosted on a single cloud. The second technical complexity is the lengthy and complex migration process. This will involve managing dual codebases during this period, and impose substantial burdens on architecture, engineering, documentation, and support teams, with existing Terraform efforts lost and new training required. The extensive effort involved necessitates significant resources across multiple teams and continuous complexity in platform operations and support. Therefore, whilst this mitigation is viable, other mitigations are more appealing.

M-003b — Pulumi

In this section, we examine the potential of Pulumi as an alternative to Terraform so that we can mitigate the risks associated with HashiCorp’s BSL license. By detailing the positives, negatives, and implementation efforts, we aim to provide you with a comprehensive assessment. This can form the basis of any decision regarding Pulumi as a viable mitigation for your Platform.

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”.

Based on the description above, Pulumi seems to be a modern alternative to Terraform. When dealing with IaC, we want it to be declarative as a key architectural principle. Multiple threads online discuss whether Pulumi is imperative or declarative. For the sake of this report, we will assess it as a declarative tool, as stated by Pulumi.

Using Pulumi to replace Terraform is a viable option and mitigates risks R-001 and R-002 in their entirety. That being said, the negatives involved in implementation are vast for an existing platform, and we do not consider this a pragmatic option, primarily because of the additional effort, complexity, and cost the Platform would undertake.

If you were building a Platform from scratch, this option would become much more appealing, but we believe it should be considered only in this scenario.

M-003c — In-house developed product

Below, we assess the validity of developing an IaC tool In-House with your development team. On the face of it, this 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.

But delving deeper may have other implications, so let’s explore this mitigation in more detail.

Whilst the in-house developed product is a viable option for mitigating risks R-001 & R-002, the negative implications and vast development, migration and maintenance effort make this option extremely unappealing. Developing the product will take a significant amount of time. Therefore, you would be managing risks R-001 and R-002 for a lengthy period before you can even begin the migration process.

If you were designing a Platform on a greenfield site, the nature of this being a Product for your engineering team to maintain and develop alongside the Platform would make other options much more viable and appealing while still managing to mitigate the risks fully.

Control over the Product and the roadmap, while a positive aspect of this option, does little to negate the large negatives and effort involved with this mitigation.

Overall, as a mitigation, we strongly advise against pursuing the development of an in-house tool.

M-004 — Accept the risk and continue with Terraform

We have explored a number of mitigations, but the one remaining is to purely accept the risk. In essence, this is the “do nothing” approach, as no mitigations are appropriate, or you believe the cost and impact of mitigating are more significant than the combined likelihood, cost, and effort should the risks materialise. Let’s delve into the positives, negatives, and efforts of accepting these risks below.

Given how significant the impact could be if they materialise, we would not advise accepting the risk. Whilst it could be an attractive option given how little effort is involved and the fact you can continue to use Terraform and any new features it may release in the future, the fact that neither risk has been mitigated results, in our opinion, this should not be an option for your Platform.

Summary of Hashicorp & Terraform risk mitigations

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

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.

Download this whitepaper