Open source software licenses 101

It’s a common belief that when software is "open source,” it can be freely used, copied, modified, and distributed without restrictions. While software that’s in the public domain or “shareware” is free to use and modify without permissions, that’s not always the case for open source software, which is usually governed by specific licenses and is not always zero-cost. 

Unlike proprietary software, where the source code is inaccessible, open source allows for use, modification, and distribution, but within legal constraints defined by the license. Understanding and complying with these licenses is essential, because they protect both the software creators and users. 

There are many different individual open source licenses. To provide guidance on what makes a software license “open source,” the Open Source Initiative (OSI) created the Open Source Definition, specifying that an open source software license must allow for free redistribution, access to source code, no discrimination against a person or groups of people from using the software; and the license must not be specific to a product, among other requirements.

Types of open source licenses: Permissive vs. copyleft

Most open source software licenses can be categorized as either “permissive” or “copyleft.” Permissive open source licenses give developers the right to use, modify, and distribute the software, including using the open source code in their own proprietary software projects and releasing it under a different (or non-open source) license. By contrast, copyleft licenses include distribution terms that allow developers to use, modify, and redistribute the open source code, but only if the distribution terms are unchanged.

Common permissive open source licenses

Some of the most common permissive open source licenses include: 

• The MIT License (originating from MIT) is widely used and simple to understand. It allows developers to freely modify the original code, as long as the original copyright and license notice is included either in the distributed source code or software. It does not explicitly contain a patent grant.

• The Berkeley Source Distribution (BSD) License preserves license notices and copyrights, but allows larger or licensed works to be distributed without source code and under different license terms. The 2-clause BSD license is very similar to the MIT open source license, while the 3-clause BSD license adds more requirements or restrictions related to reuse and other terms.

• The Apache 2.0 License allows developers to modify, distribute, and sublicense the original code. It also permits commercial use, warranties, and permit claims. Unlike the MIT and BSD licenses, Apache licenses do contain a patent grant. When using the Apache license, developers must include the original copyright notice, a copy of the license text, and often a copy of the notice file with a disclosure of significant changes made to the original code.

Common copyleft open source licenses

Some of the most common copyleft open source licenses include: 

• The GNU General Public License (GPL) family: The GPL license preserves license notifications and copyright terms and is suitable for commercial, patent, and private use. Any software that uses GPL code must distribute all its source code under the same license. So if you use GPL code in your software (e.g., by using a GPL library), and distribute your application, all your source code must be made available under the same GPL license. 

  • The Affero GPL (AGPL) includes a remote network interaction clause that triggers the GPL license for any software used over a network.

  • The Lesser General Public License (LGPL) stipulates that smaller projects or objects accessed through larger licensed works do not require distribution of the larger project, and the modified source does not have to be distributed under the same terms that apply to the larger code project.

• The Mozilla Public License (MPL) allows for modification and use of code in proprietary software, as long as any code licensed under the MPL is kept in separate files and these files are distributed with the software. The MPL also includes patent grants and enforces that copyright notices be retained.

What is SPDX (System Package Data Exchange) and how does it relate to open source licenses?

The System Package Data Exchange (SPDX) is an open standard created by the Linux Foundation. It's used to communicate software bill of material (SBOM) information, including license and copyright information for the software and its dependencies. It provides a common format for license information, making it easier for maintainers and companies to share licensing information and enforce license compliance policies. 

To do this, the SPDX project includes a License List, which enables efficient and reliable identification of licenses and exceptions in an SBOM or source files. For each open source license, the License List includes a standardized short identifier (e.g., BSD-3-Clause), the full name, the license text, and a canonical permanent URL for the license and exception.

How do I make sure my organization stays in compliance with open source licenses?

To make sure that you're not inadvertently using dependencies with incompatible license types, here are two suggested actions:

Create a mapping of your open source dependencies

To understand whether you're using software with non-compliant licenses, you first need to understand what dependencies are in your software—including both direct dependencies and transitive dependencies, which are the dependencies of your dependencies.

You can generate a Software Bill of Materials, or SBOM, for your software program to get a list of all of your dependencies, including package names, versions, and licenses. If you're already using an SCA (Software Composition Analysis) tool, you can likely use this tool to generate an SBOM automatically. You can also use free and open source tools like Syft or Tern to generate SBOMs from container images, filesystems, and Dockerfiles.

Enforce policies for license usage

Implementing policies to allowlist or block certain types of open source licenses can help make sure that you're staying compliant with your organization's requirements. Many commercial SCA tools include automated license scanning capabilities. FOSSology is an open source license compliance toolkit that can execute license and copyright scans.

I’m writing open source software. How do I choose which license to use?

The main question you have to answer is whether or not you want to keep your software open source, or allow others to make money off of your open source code, e.g., by including it in their own commercial or proprietary software offerings. You should also consider whether attribution / getting credit as the author is important to you. 

If you want to make the code as reusable and shareable as possible, then choosing a permissive license is the best way to go. MIT licenses in particular are compatible with many other open source licenses, so they can be used in another open source project with a different license. 

If you’re writing open source code on behalf of your organization and not as an individual, you should check with your organization’s Open Source Program Office (OSPO) or legal team, to make sure you’re complying with your organization’s license policies.

Helpful resources about open source licenses

• Blue Oak Council has a great primer on open source software licensing. Blue Oak also publishes a list of permissive licenses, ranking them by level of permissiveness to make it easier for developers to identify and use permissive licenses.  

• Carnegie Mellon’s Open Source License Comparison Grid provides a more detailed overview and comparison of different open source licenses. 

• GitHub publishes the website choosealicense.com to help developers understand which software license to use. 

• Stacklok provides a free-to-use web app, trustypkg.dev, that displays license information for open source dependencies, along with data and analysis on the supply chain risk of those dependencies. Trusty indexes open source packages from five different language ecosystems (Go, Python, Rust, Java, and JavaScript).

Final considerations

When choosing a license for your open source software project, make sure you consider how you want your software to be consumed, and choose accordingly. And before consuming open source software, you need to be aware not only of the license for the library or framework you’re using, but also the licenses of the dependencies used to build that library or framework. Accessing the software’s SBOM can help you understand this and identify any potential legal risks.