The information contained in this blog does not, and is not intended to, constitute legal advice
On August 10th, 2023, HashiCorp announced a transition from the Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL, or BUSL) v1.1 for future releases of all products and several libraries, Terraform being one of them. From a legal standpoint, the general consensus in the industry is that HashiCorp is well within their rights to make this change. The part of the change that is most interesting is one where they “prohibit embedding of Terraform to build a product that is competitive to HashiCorp” [1].
This is an event of profound importance in the DevOps world as beyond in-house use of Terraform by DevOps teams for automation, dozens of third party tools embed terraform internally. Almost every system integrator touts pre-baked Terraform modules as their key assets that they distribute to their customers.
As per the license update, in order to impact one’s use case two conditions must be true:
(a) Embedding Terraform: If one were to package Terraform code libraries and distribute them to multiple clients that would be embedding.
(b) Build a product that is competitive: This is somewhat ambiguous because it is to HashiCorp’s discretion to determine if a certain product is competitive. They have suggested reaching out to the HashiCorp team.
Terraform Use Cases and Impact by License Change
- In-house Cloud Automation: Millions of SaaS companies hosted in the public cloud have DevOps engineers who write Terraform scripts to build and maintain their own cloud infrastructure. This is purely for internal purposes.
We believe there is no impact on this usage. See https://www.hashicorp.com/license-faq#implications-of-change-for-users
“One could be worried if Hashicorp in the future could make all use cases of Terraform paid. This is unlikely because Terraform is the gateway to cloud provider usage, and hence AWS, Azure and GCP, will probably fork a free version for users.” - DevOps Product Companies: If a DevOps tools company embeds Terraform as part of the product then this change puts the business at substantial risk. From our understanding of the DevOps product landscape a vast majority of these embed Terraform in one form or the other.
“Many DevOps ISVs impacted by the license change can be found in OpenTf”.
OpenTf is a form of Terraform. It remains to be seen if it will be a viable alternative to HashiCorp Terraform. At the time of writing this blog, there are no large companies or cloud providers backing the effort. Building and maintaining Terraform is not just about contributing code, there is a tremendous effort involved in customer research, partnerships with cloud providers, QA, validation and so on. Most end customers are likely to stay with HashiCorp Terraform. - DevOps System Integrators: Almost every system integrator touts pre-baked Terraform modules as their key assets that they distribute to their customers. Most also claim to have a DevOps “Platform”. A few examples are Accenture Cloud Platform and Infosys Cobalt. If you are a System Integrator it would be prudent to communicate with HashiCorp and confirm that they don’t view your platform as a competitive product. One may want to get a custom license. But there always remains a possibility that HashiCorp might build a comprehensive DevOps Platform in the future and may change the license terms.
“If you are a client who is leveraging an SI and their platform, you should talk to them and ensure that they have a custom license. Further validate that the SI is prepared for future license changes.” - Non DevOps Companies Embedding Terraform in their Product: This would be a class of companies that build products which are potentially unrelated to the DevOps space and HashiCorp’s core business. Say you are an ISV in the fintech space and sell a product that installs in a customer’s cloud account and involves ongoing provisioning of resources for which you have a DevOps Automation Component that leverages Terraform underneath. Talking to HashiCorp and getting a custom license for this use case might be the safest approach given that the business has a foundational dependency on Terraform.
In our opinion, if you are a business that is embedding and distributing Terraform, regardless of whether HashiCorp has a competing product today or not, you should talk to HashiCorp and get a custom license. It would be prudent to revisit the reliance on HashiCorp’s terraform.
Building DevOps Automation Platforms with First Principles (APIs)
Many DevOps Platforms are built by using Terraform underneath to orchestrate resource provisioning in cloud providers. Terraform in turn calls the cloud provider APIs. There are many technical drawbacks to this approach and are detailed in this blog. The key rationale is that one cannot build a distributed system like a DevOps platform using unattended scripts. Instead we need a systems approach where the platform implementation, using a higher level language (like Java, Go, or Python), orchestrates the cloud provider’s APIs directly. Terraform should certainly be leveraged, but only at the External interface by having a provider that gives an IaC interface to the platform along with API and UI. This has several advantages:
- A systems approach to building a platform is more scalable and extensible than using linear scripts.
- No Terraform embedding hence no license implication.
- The Terraform provider is just an alternative mechanism to interface with a system along with UI and APIs, where Terraform is not strictly essential. It is also not impacted by the license change.
Conclusion
The license change around Terraform is a seismic event in the DevOps automation world which is practically the entire cloud world given how extensively it is used. If you are not embedding and distributing code then you are unaffected. However, there is an impact on everyone else near term or long term. One cannot operate in the same modus operandi of a GPL license. While some companies may have to find alternatives, others might need to talk to HashiCorp and get clarity and potentially a custom license. DevOps Platform ISVs might want to re-architect their systems to leverage the cloud provider’s APIs rather than using Terraform at that layer. Easier said than done, but not doing this poses an essential risk.
