TL;DR overview
- This post examines the current landscape of open-source software licenses, highlighting how license proliferation and the mixing of incompatible licenses create legal and compliance risks for organizations that use open-source dependencies.
- Permissive licenses (MIT, Apache 2.0, BSD) dominate modern open-source adoption, while copyleft licenses (GPL, LGPL, AGPL) introduce obligations that can affect a company's ability to distribute proprietary software that links to GPL-licensed libraries.
- SonarQube Advanced Security's SCA capabilities include license compliance tracking, automatically identifying the licenses of all direct and transitive dependencies and flagging combinations that may violate organizational policy.
- SBOM generation in SonarQube Advanced Security provides a machine-readable inventory of all software components and their licenses, enabling compliance and legal teams to audit dependency risk at scale.
Open source software has become a cornerstone of modern application development (approximately 98% of applications contain open source software components), but with its widespread adoption comes the critical need for organizations to understand and navigate the nuances of open source licenses. Whether your organization operates in highly regulated industries such as financial services or healthcare, or you’re a government organization—or if you're simply using open source components—understanding open source software compliance is essential to avoid potential legal pitfalls.
Before we dive into it, let’s imagine that your development team uses an automated development tool to reduce the time it takes to release your next update. Three months after deployment, your legal team discovers that one of the dependencies pulled in by the tool doesn’t have a license—opening the door to potential copyright claims—and they request that the update be pulled. What was at first an attempt to save three months of development time has now turned into six months of remediation and re-coding. This is why understanding open source licensing and what licenses are in the open source in use at your organization is crucial to preventing compliance risk.
In this post we will cover why it’s important to know what licenses accompany the open source in use at your organization, how licenses are tracked (and why you should track them), the basic types of licenses, and the continuously evolving world of open source licensing and artificial intelligence (AI).
Understanding open source licenses
At its core, an open source license provides the permissions and restrictions governing the use of open source software. These licenses can vary, ranging from permissive licenses that impose minimal restrictions to copyleft licenses that require redistributed modifications to remain open. For organizations aiming to ensure open source compliance, it is vital to be aware of the specific obligations tied to each license.
In our 2020 survey, 46% of respondents from large organizations stated that “resolving licensing issues or complying with the organization's license policy” was one of the common challenges their organization experienced when using open source software. Understanding an open source license’s usage and limitations is key to minimizing compliance risks.
Tracking open source licenses
Traditionally, licenses were tracked using LICENSE files or file headers—an approach that was manageable when dealing with a limited number of packages. However, as software supply chains have grown in complexity, this method has proven insufficient. Errors in copying, lack of standardization, and the sheer volume of packages now in use have led many organizations to adopt machine-readable licensing standards like SPDX or CycloneDX.
Each license is listed using its SPDX license expression. They maintain machine-readable SDPX license data for over 1 million open source packages. You can read more about how they gather, analyzes, and helps organizations understand licensing data in our documentation.
The challenge of packages without licenses
One of the most significant risks in the open source landscape is the use of packages that lack explicit licensing. Even if a developer intends for their code to be open source, failing to include a license opens the door to potential copyright claims. This issue is more common than you might think—the analysis of over 1.1 million packages revealed that 14 percent had unknown licenses.
The challenge of licenses changing
Risk averse organizations need to monitor the license on each of their open source dependencies for every release of that dependency. It is important to understand the licenses embedded in any additional files in the dependency download. Having accurate data that is updated per-release ensures that users understand their risk profile and that risk policies can be built and applied accurately.
It’s important that this data is refreshed on a per-release basis, because licenses can change, and it can result in copyright violation consequences. TinyMCE and iText are two recent examples of licensing changes that have a very different set of requirements for legal usage. When an open source project with restrictive licensing is used inside of your product, the licensing requires that you now distribute the source code of your product.
Conflicting licenses and their impact
The diversity of open source licenses—from permissive to restrictive—means that organizations must be diligent in understanding which licenses apply to their software dependencies. Complicating this further are cases where license information conflicts between package managers and source code repositories. One way to check for conflicting license information is to compare the information the package managers provide, usually based on a configuration file, to what the corresponding source code repository on GitHub says. Ideally these two match.
But it turns out that the license information provided by package managers conflicts with that provided by GitHub for more than 82,000 packages (or about 7 percent of all packages). The problem is even worse for the most popular packages: the inconsistency rate goes up above 10 percent for the top decile and over 12 percent for the top 1 percent most popular packages.
Permissive vs. copyleft licenses
Permissive licenses, such as MIT and Apache, are straightforward—they require notice and attribution, which are often managed using software tools due to the number of licenses involved. On the other hand, copyleft licenses, like the GNU General Public License (GPL), impose more stringent obligations, requiring that any redistributed software remains under the same license.
Beyond copyleft, there are emerging licenses that challenge traditional definitions of "open." These include non-commercial licenses that restrict commercial use and ethical licenses that prohibit specific types of unethical use. As these licenses gain traction, it becomes increasingly important for organizations to stay informed about the evolving landscape of open source licensing.
The intersection of AI and open source licensing
As artificial intelligence (AI) and machine learning continue to evolve, so do the complexities of open source licensing in this space. The use of open source software in training AI models raises unique challenges, particularly regarding intellectual property rights and compliance with existing open source licenses. For instance, the recent legal debates surrounding AI tools like GitHub’s Copilot highlight the need for organizations to carefully navigate these waters to ensure regulatory compliance while fostering innovation.
Conclusion
Navigating the complexities of open source licensing is more important than ever, especially as the use of open source software becomes increasingly integral to business operations. From understanding the differences between permissive and copyleft licenses to staying informed about the latest developments in AI and open source, organizations that prioritize open source software compliance are better positioned to innovate securely and confidently. By staying proactive, you can minimize legal risks and ensure that your use of open source components supports your organization’s goals without compromising on compliance.