SPDX License Identifiers are standardized abbreviations for common open source software licenses. For example, the License Identifier for the Apache License 2.0 is Apache-2.0.

SPDX License Expressions are used to communicate the context that informs how a license(s) applies to the open source code it governs. For example, License Expressions can be used to describe license exceptions (e.g. GPL classpath) and multi-licensing scenarios, among others.

Together, License Identifiers (also referred to as License IDs) and License Expressions work in tandem to communicate open source licensing information accurately and simply in an SPDX bill of materials. They are also used in the REUSE Specification, which is designed to help reliably identify licensing information in source files.

License Identifiers and Expressions are important because they address several areas of potential confusion and friction related to communicating licensing information. These include:

  • There are multiple versions of many common open source licenses, but it’s not always clear which version(s) apply to a given software component. For example, simply saying a license is “GPL” doesn’t make it clear what version of the GPL (or even the LGPL or AGPL) governs a given file. This has the potential to create confusion for SBOM consumers.
  • Multi-license scenarios can be difficult to communicate and interpret.
  • It can be time-consuming and difficult to add long-form license names and license text to each file.

In this blog, we’ll provide additional context around License Identifiers and explain how to use them. We’ll also discuss the six types of SDPX License Expressions, with examples for each.

License Identifiers and the SPDX License List

SPDX License Identifiers are based on the SPDX License List. The License List is a comprehensive listing of common open source licenses, including the following descriptors along with the full license text:

  • Full license name
  • License Identifier
  • Whether the license is OSI (Open Source Initiative) approved
  • Whether the license is listed as free by the Free Software Foundation

Each entry in the “Full License Name” column links to a separate page with more information and context about a given license, including links to the license text and, if applicable, the OSI page.

The License List is continuously updated to account for new licenses (and to deprecate licenses which have been superseded by other licenses). Always note the license list version, currently 3.21 2023-06-18, which you may find on both the SPDX license list or a generated SPDX SBOM.

It’s worth noting that the use of SPDX License Identifiers isn’t limited to only SPDX. CycloneDX (the other commonly used machine-readable bill of materials format) has integrated License Identifiers, meaning that if you deal in SBOMs with compliance information, you’ll often come across SPDX IDs, regardless of specification.

SPDX License Expressions

Not every software component will be under just one of the licenses on SPDX’s License List. You might encounter a choice-of-license or multi-license situation. Or, there are times when an (uncommon) open source license won’t have an SPDX License Identifier. SPDX License Expressions account for these situations along with more conventional single-license scenarios.

There are six types of license expressions, which we’ll review below.

Simple License Expressions

  • Where there’s a single license and that license has an assigned SPDX License Identifier
  • When there’s a single license but that license doesn’t have an assigned SPDX License Identifier
  • When there’s a single license, but later versions of the license are also permitted

Composite License Expressions

License Exceptions

Sometimes, licensors choose to add permissions or restrictions to open source licenses. SPDX refers to these as exceptions. One particularly well-known example is the GPL Classpath Exception, which allows linking of GPL libraries with independent modules to produce an executable under terms of the licensee’s choice, provided that those terms are compatible with other linked libraries.

SPDX uses the syntax “WITH” to communicate License Exceptions. You can find the full list of SPDX Exceptions on the specification’s website. Interestingly, although the current SPDX 2.3 has a defined list of exceptions, the forthcoming release of SPDX v3.0 is expected to add the ability to use custom exceptions.

Choice-of-License Scenarios

In other cases, software may be offered under a choice of multiple licenses. These are also referred to as disjunctive licenses. SPDX uses the syntax “OR” to communicate disjunctive license scenarios.

Multiple-License Scenarios

The third composite license expression is when two or more licenses must be simultaneously applied; in other words, the licensee must comply with the terms of multiple licenses. These are also referred to as conjunctive licenses. SPDX uses the syntax “AND” to communicate conjunctive license scenarios.

There are also occasions when you may see a combined license expression, where, for example, there are both conjunctive and disjunctive license scenarios. This, of course, may raise the question: Which license expression takes precedence over the other?

SPDX’s default order is as follows:

+
WITH
AND
OR

For example, software under either a) the Mozilla Public License 2.0 or b) both the MIT and ISC licenses would be communicated as:

MPL-2.0 OR ISC AND MIT

Because “AND” takes precedence over “OR,” this license expression would be interpreted as:

  • ISC and MIT

OR

  • MPL-2.0

Much like in algebraic expression, parentheses are used in situations where there is a different order than the default. For example, if the intent of an expression is:

  • MPL-2.0 OR ISC

AND

  • MIT

This would be expressed:

(MPL-2.0 OR ISC) AND MIT

Using SPDX License Identifiers and Expressions

Before we explain how you can use SPDX License Identifiers with the License Expressions discussed above to communicate a range of licensing scenarios, it’s important to cover a few contextual notes

  1. SPDX has multiple different license fields, including “Declared” and “Concluded” licenses. The “Declared” license is stated by the component (e.g. package or file) author, while the “Concluded” license is determined by the SPDX document creator (which is often an SBOM tool or the document creator in the case of disjunctive licenses). For the purposes of this exercise, we’ll use the “Declared” field.
  2. SPDX supports multiple file types, and the formatting for each is slightly different. For the purposes of this exercise, we’ll use the tag-value format.

Simple License Expressions

Single License with an Assigned SPDX License Identifier

In a hypothetical where the “Declared License” is the MIT, this would be communicated as follows:

PackageLicenseDeclared: MIT

Single License Without an Assigned SPDX License Identifier

This is communicated with a user defined license reference. For example, consider the hypothetical new open source license “DZD,” which doesn’t have an SPDX License Identifier. This would be communicated as follows:

PackageLicenseDeclared: LicenseRef-DZD

Single License or Later Version of that License

A single license with an assigned SPDX License Identifier, where the “Declared License” is the Apache 2.0 or any later version, would be communicated as follows:

PackageLicenseDeclared: Apache-2.0+

Composite License Expressions

License Exceptions

License exceptions are communicated using “WITH.” For example, the GPL v2.0 with classpath exception is communicated as:

PackageLicenseDeclared: GPL-2.0-only WITH Classpath-exception-2.0

Choice of License (Disjunctive)

When there’s a choice between multiple licenses, the “OR” expression is used. For example, a disjunctive licensing scenario with the MIT or Apache 2.0 licenses would be communicated as:

PackageLicenseDeclared: MIT OR Apache-2.0

Multiple License (Conjunctive)

When two or more licenses must be followed, the “AND” expression is used. For example, a conjunctive licensing scenario with the Apache 2.0 and LGPL 2.1 licenses would be communicated as:

PackageLicenseDeclared: Apache-2.0 AND LGPL-2.1-only

More SPDX and SBOM Resources

We hope you found this overview of SPDX License Identifiers and Expressions useful. For a more comprehensive breakdown of using SPDX for license compliance (and some additional nuances related to License Identifiers and Expressions), we’d recommend referencing SPDX Annex D, which defines the license expression syntax, as well as the full SPDX spec.

For additional perspectives on SPDX and building an effective SBOM program, consider checking out the following on-demand webinars: