Dirk Riehle's Industry and Research Publications

Open-source software licenses

Part 1
Open-source software

Chapter 2
Free and open-source software

  1. Why use open-source software?
  2. Intellectual property rights
  3. Open-source software licenses
  4. End-users and distributors
  5. The copyleft obligation

Chapter 3
The open source program office

Chapter 4
The software bill of materials

Chapter 5
License compliance

Chapter 6
Supply chain security

Licenses are a contract (in most jurisdictions) between a licensor and a licensee. Typically, the licensor allows the licensee to use their property in return for some payment. 

Software licenses grant licensees some rights to the software. Software licenses can be limited in many ways: There may only be one user allowed at-a-time, the software may only be used until the end of the year, the software may not be used outside of Germany, etc. If someone says they bought some software, what they typically did was to assume the licensee role and pay the licensor a fee for a usage right to the software.

Open-source software licenses are licenses that have been approved by the Open Source Initiative (OSI). The Open Source Initiative is a U.S.-based non-profit organization that serves as a spokesperson for and an arbiter of what open source means.

Open source (software) licenses all follow a common pattern. They consist of four main sections:

  • The rights grant. An open source license always (by definition) grants the licensee the right to use the software, to receive the source code, to modify the source code and run the modified program, and to distribute the source code and resulting programs in unmodified or modified form.
  • The obligations. An open source license may impose obligations on the licensee. For example, if someone passes on the open-source software, they may have to create and provide legal notices of the open-source software to recipients. Obligations vary widely between licenses.
  • The prohibitions. An open source license may contain clauses that tell a licensee what they are not allowed to do. Typically, a licensee may not claim endorsement of any uses of the open-source software by the licensors of the open source code or the creators of the license texts.
  • The disclaimer. Most open source licenses disclaim warranties and liabilities. Licensors try to make sure that anything bad that happens through the open source code does not fall back on them. Such disclaimers may be limited by the laws of the jurisdiction where they apply. 

Software becomes open-source software, if the owner of the software decides to license out the software to the world using an open source license. Thus, the status of open source is not an intrinsic property of the software, but is decided by the original owner, who decides to become an open-source software licensor.

Across all open source licenses, the rights grant is always the same, whatever the specific choice of words. Prohibitions, if any, and the disclaimers are also almost always the same. Obligations, however, differ widely between licenses. 

The most important common obligations are:

  • Provision of legal notices. An open source user, upon distribution of a binary version of the open source code, must compile all relevant legal notices (license texts, copyright statements, and other notices) and provide them to the recipient of the code.
  • The copyleft obligation. An open source user, when distributing the open source code, must apply the license of the incoming open source code to the outgoing code, including any proprietary modifications made to it, or lose the right to use and distribute the code.
  • Indemnification. An open source user, who distributes open source code, has to help defend and indemnify any open source developer whose code they are distributing, if a recipient of the user’s distribution chooses to take legal action against the developer.

Legal notices and the copyleft obligation will be discussed in later sections of this book.

The Linux Foundation’s SPDX project has given us unique identifying names for established open source licenses. These so-called SPDX identifiers encode, in human-readable form, the name and version of a license and sometimes specific conditions.

  • An example of a simple SPDX identifier is MIT for the MIT license.
  • An example of a versioned SPDX license identifier is EPL-2.0 for the Eclipse 2.0 license.
  • An example of a complex SPDX license identifier is AGPL-3.0-or-later for the Affero GPL 3.0 license with the option to choose a successor license.

Open source license texts themselves are legal documents. Typically, they are free to use. Some allow modification, for example, the Apache-2.0 license, some don’t, for example, the GPL-2.0 license.



To be done.