HashiCorp joins a growing list of companies who are dramatically changing the way you can use their software under an Open Source agreement. 

Summary tl;dr 

HashiCorp has changed how they license their products from a common open-source License, MPL 2.0 to a more restrictive license, BSL. If you use these components to provide competing products / services, then you now need a commercial license, or consider alternatives.  

While open-source can be a tremendous accelerator, the landscape is changing (see https://www.thoughtsourceconsulting.com/articles/open-source-is-changing/), even for established components. HashiCorp is just the latest example of a component gaining traction, and changing its licensing model. You need to know your exposure by scanning your open-source dependencies, and doing it regularly. We help our clients with this service regularly, ease the pain and give you straight forward, actionable insights. 



What has happened 

HashiCorp have changed the licensing of its products and libraries. This includes Terraform, which is a commonly used Infrastructure as Code piece of software used to manage resources like virtual machines and other data center infrastructure. This change also includes HashiCorp’s other offerings – Packer, Vault, Boundary, Consul, Nomad, Waypoint and Vagrant. Previously, they were licensed according to the Mozilla Public License v2.0 (MPL 2.0). However, in August 2023, the license was changed to the Business Source License (BSL). 

This is the latest in a series of licensing changes of popular software, such as Elasticsearch and MongoDB, where something many companies relied upon changed their licensing, restricting the usage of the free version.  

The existing versions, based upon MPL are still available and can be used, but support is ending at the end of 2023. 

The new Business Source License (BSL), is not a traditional open-source license. It is a “source available” license, where you can use the source, but the traditional freedoms that open-source provides are not available. The main restrictions that this license have are around the use in competitive products. BSL stops you using the HashiCorp components that are BSL licensed (whether as source or executable) in competitive products without appropriate commercial licensing in place. 

License changes of this nature often cause significant discussion and activity in the community. Some vendors who built upon Terraform have already created a fork of Terraform at https://opentofu.org/ based on the last MPL version.  

What it means for you 

Like every issue related to software engineering – it depends.

The development of a fork project, OpenTofu indicates that some users of Terraform / competitors who build upon it, are seeking alternatives, due to how they were using HashiCorp offerings. This is similar to how Amazon forked Elasticsearch to create OpenSearch. But what about you, in your company? The key aspects of the BSL are: 

  • It’s a bit different to other restrictive licenses (GPL, AGPL, SSPL) in that it doesn’t require you to open-source your own proprietary code for components or your entire SaaS. You just aren’t allowed to use it if you violate the license. There is also a sunset clause on the license too – after 4 years, something BSL licensed reverts to an alternative license – MPL 2.0 in the case of HashiCorp. 
  • You can use BSL licensed products for production and non-production internal usage unless you are providing a competitive offering. And this is where the complexities reside. The definition of a competitive offering at https://www.hashicorp.com/license-faq is: 

A “competitive offering” is a product that is sold to third parties, including through paid support arrangements, that significantly overlaps the capabilities of a HashiCorp’s paid version of the Licensed Work. For example, this definition would include hosting or embedding Terraform as part of a solution that is sold competitively against our commercial versions of Terraform. By contrast, products that are not sold or supported on a paid basis are always allowed under the HashiCorp BSL license because they are not considered competitive.

If you are a plain old user of the products to configure your own systems, that you use yourself, then you are likely to be ok. If you have more exotic usage, then you will need to dig further to understand the implications, and if there are side effects, either technical or commercial for you.  

How do you know your exposure? 

The first step is to conduct an open-source scan and audit. This is where you essentially get an inventory of your open-source dependencies at the source and executable level, of all the versions used.  

The scan lets you work out the licensing implications of your estate, and what to do going forward, based on what you find. In the case of HashiCorp, you may have older, open-source versions, as well as newer BSL versions. You are also likely to find other components where you have licensing issues to be remediated, either through commercial licensing or replacing components.  

In addition to licensing issues needing remediation, we often find that clients have software components that are not current, and need updating to the latest version, for security and functionality reasons. 

Our Thought Source open-source scanning looks to see how your components are licensed, as well as how current your components are, and any security issues around your components. This gives you insights into licensing and risk around your open-source estate. We don’t just give you a massive spreadsheet of dependencies (although there is one created if you wish to delve into the gory details!), we highlight the dependencies that you need to take action around so you know what to do. 

How do you keep on top of open-source changes? 

Open-source dependencies change in many ways – licensing changes, as in the case of HashiCorp, as well as when components are updated, due to functional or security needs. How quickly they change depends on what ecosystems you use. If you are using Golang or Node.js, then dependencies change at a rate of knots, and every month you may run into dependency issues. Slower moving ecosystems, like Java, .NET are not updated quite as frequently. 

The way to keep your dependencies current is to run scans frequently, or upon commit of code. You can check using tools like Dependabot https://github.com/dependabot or Snyk https://snyk.io/ which are awesome. However, the output from this tooling can be difficult to diagnose and consume easily, along with deciding how risky the findings are given your business context. These tools are also focused on keeping modules up to date – not so much on the finer points of what licenses are suitable for your business. 

Thought Source scanning comes with a dedicated team who know how to speak the language of executives and technologists. Our service provides your with the key actions you need to take to ensure your open-source software choices won’t keep you up at night. It can be especially daunting the very first time you do one of these scans as there is often a substantial list of dependencies (tens of thousands), with complex licensing and components that are out of date. We navigate this for you and can help ensure your open-source compliance on an ongoing basis. 

Contact us now to discuss how we can help get you get “Open Source compliant”