Understanding relicensing risks: a guide for managing open source

5-minute read

Much has already been written about the relicensing of Terraform, the purchase of HashiCorp by IBM, and the potential impact of these moves. Many focus on analysis of these transactions and their potential impact on organizations using their relicensed projects (chiefly Terraform and Vault).

The TLDR of the Terraform relicensing (from Mozilla Public License (MPL) to the Business Source License (BSL or BUSL)) is that for most organizations, particularly those that are existing HashiCorp Cloud (HCP) or HCP Enterprise customers, is that these changes will have little to no impact. The Business Source License (BUSL v1.1) relicensing chiefly impacts competitors of HashiCorp. However, this episode calls on us to examine the wider implications of relicensing, the trends we see, and how we manage risks associated.

Here we will focus on the larger issue of relicensing (from open source to business source license) as a risk management issue. Specifically, we will look at ways an organization can identify OSS projects more likely to undergo relicensing and how we can manage the licensing in our existing project portfolios.

First, some further context in light of recent trends. Since 2018, there have been several high-profile cases of relicensing: Confluent (2018), MongoDB (2018), Redis (2018, 2022), Elastic (2021), HashiCorp (2023), ArangoDB (2023), and others. There appears to be an increase in the pace of these activities. And with the rapid rise in open source GenAI projects and the novel challenges they pose, we expect that in a few years hence, we will see another wave of relicensing. So now is a wonderful time to reexamine our OSS adoption policies before we get caught needing to refactor our code bases, models, and even data to replace or refactor an OSS project.

Most large organizations have formal policies for adoption of open source, and some even have an Open Source Program Office. However, relicensing opens up new challenges for organizations as it is a change to a license rather than adoption. The process of OSS adoption is usually lengthy for most regulated organizations or technology vendor companies. Even if the process of adoption is streamlined, the process of refactoring can be costly and a serious risk to timelines and reputation. Protecting ourselves by categorizing which OSS projects are likely to never relicense under BSL or other type of restrictive license is a solid step towards risk management.

Evaluating OSS sources

When we are evaluating new OSS projects or ones already in our portfolio, we need a decision tree that includes the following:

1. Is this OSS under a reputable OSS foundation that uses community-based decision models for licensing?
2. Does this foundation have a declared purpose in remaining non-commercial? For example, does it have a non-profit (i.e. tax-exempt) status or other legal bullwork that blocks it from relicensing under a commercial or business license?
3. Does the foundation have a track record of multiple-shareholder participation in governance decisions?

These questions need to be asked about all sources of our OSS. This is particularly important for core or mission-critical solutions that use or are built by OSS.

Some of the foundations that meet these requirements are the Linux Foundation and the Cloud Native Computing Foundation (a Linux Foundation group).

Managing large portfolios

The next challenge organizations face is in managing OSS projects in a large project portfolio across a large organization. The area of solution portfolio management has evolved and matured rapidly, with many important OSS projects contributing to this space; however, the challenges have also expanded. We are no longer merely concerned with source code used by solution teams. For DevOps shops, we are concerned with the code that builds our code, monitors our solutions, and builds our infrastructure. And for Advanced Analytics shops, in addition, we are concerned in some cases with the data that goes into our AI models and how the data is licensed.

The good news is that modern AppSec security scanning software can be configured to detect licenses and there are many vendors in this space as well as open-source solutions. Many offer the ability to pick and choose the scanners and add in custom scans. A software license scanner should be considered as part of any AppSec suite selection decision. Additionally, you need policies in place to ensure teams are regularly reviewing their scan results and adding AppSec mitigation tasks to their sprints, and you need to have policies in place to help teams understand how to deal with licensing policy violation findings. Without these in place, it’s likely that teams will not manage the findings effectively.

In conclusion, organizations that use OSS need to be aware of the relicensing trend and make appropriate changes to OSS selection criteria. Additionally, risk management of existing OSS in an organization’s portfolio requires licensing guidelines and policies as well as AppSec scanners for detecting licensing issues. Finally, dev teams and security teams need to monitor AppSec tools and ensure issues are being addressed regularly.

If your organization finds itself in need of refactoring or migration due to relicensing or other issues, the above guidelines should help in determining the right OSS source.

Sources:
https://www.linuxfoundation.org/blog/how-open-source-foundations-protect-the-licensing-integrity-of-open-source-projects
https://en.wikipedia.org/wiki/ISO/IEC_5230