IBM’s intention to acquire HashiCorp has led to a massive amount of speculation about whether the new owners will revert Terraform, HashiCorp’s most popular product, back to open source. After all, HashiCorp’s 2023 decision to move the tool from an open-source software (OSS) license to a Business Source License (BUSL) triggered a great deal of angst in the DevOps world.
Terraform is not the first, and won’t be the last, tool to switch from OSS to BUSL, or another for-part equivalent. After all, Linkerd and Elasticsearch have both already made similarly controversial moves, disrupting their developer communities. But knowing that licenses can change hardly helps to lower the outrage.
In the DevOps world, going closed-source is a sin against transparency, one of the central pillars of the DevOps mindset. It’s also seen as a form of theft, because the existing software is a result of the combined hard work of many individuals, whose only compensation was the free use of the fruits of their labors. In the words of Sharone Zitzman, a developer relations thought leader, “Once your license changes, and you have this dependency, and you suddenly have this package that’s tightly coupled in your stack, it really can wreak havoc.”
The question that remains is this: What can DevOps teams do to avoid this situation repeating itself with the rest of the stack?
Unfortunately, there isn’t much that any one individual can do to prevent any given open-source product from changing its license. The community can fork the software from an earlier version, like OpenTofu forked from Terraform, but that can be time consuming and tedious. It’s also not always as practical as it was for OpenTofu, which has the backing of the Linux Foundation.
Instead, teams should take steps to prepare for this eventuality. Here are actions that you can take to mitigate the impact of a license change, reduce the damage it could do to your ecosystem and leave yourself with options for how to move on.
5 Steps to Protect Against Open-Source License Changes
- Understand the problems of the open-source ecosystem.
- Scrutinize those governance policies.
- Pay attention to who is behind the software.
- Look for the earliest warning signs of license changes.
- Avoid automating yourself into a corner.
Understand the Problems of the Open-Source Ecosystem
The first step is always awareness. Remember that all OSS licenses are not created equal, so the software that you’re using might not be as dedicated to open-source principles as you think.
The company behind it could pull the rug out from under you, so evaluate its commitment to open sourcing carefully. You should consider your licensing exposure in similar terms to your security exposure.
Mike Dolan, SVP of Projects at the Linux Foundation, notes that “What the recent Terraform license change brings to the surface is the need for developers and organizations to carefully scrutinize which open source they decide to depend upon.”
Scrutinize Those Governance Policies
Governance policies reveal a lot about a given software package and its developers’ approach to licensing, so read them carefully.
Look for transparency around who can change the license, how people get promoted from contributor to approver or other levels of access, and what the processes are for approval and change on a deep level.
Examine the fine print closely to check if there’s a policy that defines how modifications can be made. This should include smaller adjustments as well as big changes like licensing principles.
Pay Attention to Who Is Behind the Software
As well as checking the governance policies, you should also investigate the individuals or entities that manage and control the software. It’s best to use code that is controlled by a set of diverse vendors or a mixture of vendors and end users, rather than a single vendor that might eventually need to buckle to monetization pressures.
CyberArk’s John Walsh warns that “Open-source projects driven by the community are those where the community of users has the lead role in creating, updating, supporting and securing the software, [while] open source projects that are driven by vendors are those where one vendor or a few vendors provide most of the software and maintenance. At the same time, the community of users may add some modifications, support and patches.”
Code that’s owned by a foundation is also generally considered “safer” than that owned by one vendor, but bear in mind that even a foundation isn’t bulletproof. Dig deeper into who owns and controls the foundation to check what’s going on under the surface.
Look for the Earliest Warning Signs of License Changes
Even if the software your team uses looks great when you first adopt it, you should still review it periodically to check for changes. Keep an eye open for something that could indicate a shift to close off open-source contributions.
Red flags include blocked contributions, or if the people maintaining the project stop responding, or stop responding as quickly, to suggestions from the community.
Avoid Automating Yourself Into a Corner
Finally, although DevOps teams love automation, sometimes it does more harm than good. Make sure you have guardrails in place to prevent an automatic upgrade from taking place before you realize that the license has changed and without having made a conscious decision about your preferred response.
“If you automatically update to the next release, if the next release has been relicensed, then you’re automatically becoming exposed without anyone having any judgment in the matter, just because you pulled the latest version, and that’s it,” says Dotan Horovits of Logz.io.
Don’t Leave Your Project Vulnerable to License Shifts
Although you can’t prevent your favorite software from switching its license, there’s no need to allow these changes to derail your projects. Looking more deeply into code policies and owners, limiting automated updates, and generally working with an awareness of the risk of license changes can help you protect your code from getting hijacked by license shifts.
