What are open source licenses?

Introduction

Open source software, also referred to as open source packages, projects, or components, comes with an open source license, and it's crucial for organizations—especially those in highly regulated industries such as public sector, financial services or health care—to be aware of the licenses used in their open source supply chain. Open source licenses outline usage permissions, specifically certain requirements that organizations must understand and follow to ensure compliance with the license.

Reflecting the importance of these restrictions, professional developers who responded to our 2019 survey indicated that open source license policies weigh heavily in their choices of what software packages to select and deploy within their companies. 86% of respondents indicated this information is very important.

How is licensing tracked?

Historically, licenses were tracked using LICENSE files, or file headers. This method had the advantage of simplicity for developers, and worked well when a small number of packages were used. Unfortunately, subtle changes, copy-paste errors, and low standardization made it hard for large scale consumers to use software to process this method into something useful.

In recent years, many enterprises have moved towards machine-readable licensing information standards, like SPDX or CycloneDX. (In the Tidelift Subscription, each license is listed using its SPDX license expression. You can read more about this and our license compliance standard in our documentation.)

Modern package management tools have also stepped in to help license tracking by providing license data and APIs. However, even with these improvements, there are still caveats such as missing data (unknown license) and conflicting licenses.

What about open source packages without a license?

Even if the creator of a package you use intends their work to be open source, if they fail to add a license explicitly saying it is, you and all downstream users of that software are open to potential copyright claims.

This failure happens more often than you think. Using Tidelift’s index of open source software—the most comprehensive database of its kind—we analyzed 7.3 million packages in large package managers (Maven, npm, Packagist, PyPI, RubyGems) and found that about 13 percent had an unknown license.*

*This statistic was found by the Tidelift team using libraries.io data. (September 2024)

Conflicting licenses

There is tremendous variation in the privileges different open source licenses grant and obligations they impose—varying from permissive to restrictive, it is critical to know which licenses your dependencies are made available under. In addition, there are some open source packages that have conflicting license information. 

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 10th percent and over 12 percent for the top 1 percent most popular packages.

Copyleft and permissive licenses

Permissive license

Standard “permissive” licenses require notice and attribution and almost all open source licenses include some variant of these two conditions. Notice is an obligation to tell recipients what licenses they have received code under, typically satisfied by providing the entire text of the license alongside information about what component(s) the license applies to. Attribution is the obligation to notify recipients of the name or other information about the copyright holders. These days, permissive licenses are often addressed with the help of software, as the number of licenses and libraries are too long for manual input. 

Popular permissive licenses include MIT and Apache.

Copyleft license

A “copyleft” (or “reciprocal”) license means that someone who uses and then redistributes source code under a copyleft license must “share alike” (i.e., allow the recipient to access the source to the distributed software under the same terms). Key questions to ask when identifying copyleft conditions:

1. In what situations do I have to share alike? (What counts as distribution?) 
2. And, what code do I have to share alike? (What is the scope of the obligation?)
   

Popular copyleft licenses include the GNU General Public License (GPL), the “network” Affero GPL (AGPL), and “weak” (gives recipient only modifications to original code) copyleft licenses like the Eclipse and Mozilla licenses.

Licenses beyond copyleft

There are a small but growing number of licenses that are referred to as “open”, meaning that the source code is available, but are not “open” in the sense of being approved by the Open Source Initiative. 

• Non-commercial (or non-compete) licenses prohibit commercial use, or prohibit certain types of commercial users.
• Ethical (or moral) licenses that prohibit the use of the unethical use of the software, as defined by the creator(s) of the license. Examples include: the Lerna project, 996.icu, carbon licenses, Hippocratic (aka Do No Harm) License, and the RAIL license. In 2020, we published a blog post on the topic of an ethical license for corporate use.
  

Open source licensing and AI

As AI and machine learning (ML) technologies continue to advance, the landscape of open source licensing faces new challenges. The integration of open source software into AI model training introduces unique considerations, particularly around intellectual property and adherence to existing open source licenses. Recent legal discussions, such as those surrounding GitHub's Copilot, underscore the importance of navigating these complexities delicately to ensure compliance with both regulatory and licensing requirements, all while fostering continued innovation.

Conclusion

Understanding open source licenses is crucial for maintaining compliance and safeguarding against legal risks, especially as organizations increasingly rely on open source software. Whether dealing with permissive licenses, copyleft licenses, or newer ethical and non-commercial licenses, it is essential to know the obligations each type imposes. Conflicting or unknown licenses add complexity, making it even more important to track and manage them effectively.

Ultimately, a thorough understanding of open source licenses not only helps organizations stay compliant but also strengthens their ability to innovate securely within the open source landscape. By understanding the licenses included in the open source software in use, organizations can be better prepared to minimize legal risk and build using open source components with confidence.

To learn more about license types, please visit our article on popular open source licenses.