As vulnerabilities in open source code continue to play a prominent role in headline-grabbing exploits, such as Heartbleed and Log4Shell, a hidden source of open source risk flies under the radar — license noncompliance. Open source software licenses present a major source of risk because even one noncompliant license in your software can result in legal action, time-consuming remediation efforts, and delays in getting your product to market.
Despite the obvious risk, maintaining license compliance is no small feat. Getting the visibility you need to understand and manage your licenses is complicated by the sheer variety of open source licenses and the difficulty of determining which licenses apply to your software.
Just as when you hunt for high or critical vulnerabilities, when you look for noncompliant licenses, you need to untangle the web of open source and transitive dependencies that frequently extend more than four or five levels deep. These dependencies often introduce multiple versions of the same open source package, and it’s not uncommon to find overly restrictive copyleft licenses hidden deep within this web.
Given this complexity, ensuring your licenses are compliant requires that you leverage advanced, context-aware software composition analysis to identify, surface, and prioritize the noncompliant licenses that threaten your organization.
Before we discuss how to get visibility into your open source licenses and maintain compliance, let’s take a step back and define some key terms.
A Primer on Open Source Licenses
When you hear the term “open source,” it’s easy to assume that you can use that package however you’d like, such as by leveraging it to build a commercial product. But even though the source code is open to the world, open source code isn’t without use restrictions.
Open source packages have licenses that dictate the use, reuse, sharing, modification, and distribution of that code. Hundreds of different open source licenses dictate how you can use open source code, and the penalty of noncompliance is real. If your organization leverages an open source package and doesn’t comply with its license, you could be forced to release your proprietary code as open source or go through the costly and time-consuming process of removing and replacing the noncompliant package across your entire codebase.
So how do you know what specific requirements you need to follow to remain compliant? This is where it gets tricky since requirements vary widely across licenses. Some licenses — copyleft, for example — are highly restrictive. Others are effectively pay-to-play, and others are free to use with correct attribution. But generally speaking, open source licenses come in two main categories — copyleft and permissive.
Copyleft Licenses
Copyleft software licenses are highly restrictive licenses that require you to open source any code that leverages the relevant open source software. These licenses require you to share your software’s source code files, which usually contain a copy of the license terms and acknowledge the authors of the code.
The most notable copyleft license is the GNU General Public License (GPL).
Permissive Licenses
Permissive licenses carry only minimal restrictions on how the software can be used, modified, and redistributed. These licenses usually include a warranty disclaimer.
Some popular examples of permissive licenses include the GNU All-permissive License, MIT License, BSD licenses, Apple Public Source License and Apache license. As of 2016, the most popular free-software license is the permissive MIT license.
One notable and successful open source software package that uses the Apache license is Kubernetes.
Now that we’ve covered license compliance 101, let’s jump into what noncompliance looks like.
A Case Study in Copyleft Noncompliance
In 2008, the Free Software Foundation (FSF) sued Cisco for selling LinkSys-branded software that was noncompliant with the open source code it leveraged. As is often the case, the noncompliant software that created a GPL copyright violation was introduced into Cisco’s software as the result of an acquisition.
Given the ubiquity of open source software, the proliferation of acquisitions, and the depth of dependency trees, it’s becoming increasingly difficult to identify open source licenses that persist deep in our commercial software offerings. But noncompliance can derail efforts to keep commercial intellectual property private. For example, if an organization is noncompliant they may be required to open source their software or halt sales of that software. And even if a license is not as restrictive as a copyleft license, it can still require teams to re-engineer their software to unstick a key dependency, which is costly and dampens release velocity.
Evolving Risks and Continuous License Compliance Monitoring
As if identifying all your licenses wasn’t complicated enough, any given open source license can change at any moment. For example, a common open source package called Elasticsearch switched from its formerly permissive license to a more restrictive one in 2021.
Checking for license compliance isn’t a “one and done” exercise, as you can see. Instead, compliance management requires a continuous approach that involves the same level of diligence we bring to other open source security processes, such as updating third-party packages to newer and more secure versions.
Developing a Comprehensive Open Source Management Strategy
On first glance, maintaining open source license compliance may sound straightforward. But in reality, it’s as complex as the nature of open source itself. And the unfortunate truth is that even if your existing open source security strategy involves deep dependency scanning and vulnerability management processes, you may still have significant unaddressed open source risks. Because it only takes a single noncompliant package to render an entire application noncompliant with its licensing requirements, you need to embed proactive and comprehensive open source security into your strategy to adequately protect your supply chain.
By adopting a proactive approach that identifies and remediates open source license issues early in the development lifecycle, you can improve developer productivity while also reducing the heartache that comes with having to rip and replace noncompliant packages from your software later in the development lifecycle.
Adopting comprehensive open source security can seem daunting, but it is achievable. And if approached right, it can even be developer-friendly. By integrating open source tools like Checkov into IDEs like VSCode and Jetbrains’ PyCharm, application developers and DevOps teams can get insights into vulnerabilities and potential license compliance issues as early as possible in the development lifecycle. That way, they can proactively fix issues with noncompliant packages and maintain their release velocity.
Interested in learning more about proactive open source security? Watch this 30 minute deep dive into software composition analysis (SCA).