Guidelines and HOWTOs/Licensing

This document explains how to state license information in KDE projects according to the KDE Licensing Policy. Stating licenses correctly is a very important task, because only correctly licensed software can be distributed and delivered to our users.

Introduction

Every source code file shall contain information about its license to inform the user of the file how it may be used. Such information is usually added in the form of source code comments at the top of the file. Traditionally, those comments were formulated as so-called "license headers", which are either the complete license texts or short texts that explain where to find the license text for the file along with some legal constraints. Nowadays, this system is getting replaced with "SPDX Expressions", which should become the default way to state a license (see REUSE.software).

In a Nutshell

Whenever adding new source to a KDE repository, follow this checklist:

1. The file must have a license defined, which shall be one of the licenses in the KDE Licensing Policy.
2. You should add yourself to the copyright holders whenever you do a non-trivial contribution to a file.
3. The copyright and license statements shall follow the REUSE.software specification (see below)

Thus, your file shall start with a license statement similar to:

/*
    SPDX-FileCopyrightText: [CURRENT YEAR] [YOUR NAME] <[YOUR MAIL ADDRESS]>
    [FURTHER CONTRIBUTORS]

    SPDX-License-Identifier: [LICENSE IDENTIFIER EXPRESSION FROM POLICY]
*/

REUSE.software

REUSE.software is an initiative by the Free Software Foundation Europe (FSFE), which provides recommendations to make licensing easier. Their guidelines state how to use SPDX identifier to easier license statements in source files. When following their recommendations, the correct statement of license information can be tested by the "reuse" Python tool, which checks the syntactical correctness of the license statements and the overall conformance with the REUSE specification:

• https://reuse.software/spec/

SPDX Identifiers and Expressions

Software Package Data Exchange® (SPDX) is an open standard for communicating software bill of material information. The SPDX specification is developed by the SPDX workgroup, which is hosted by The Linux Foundation. The idea is to have a public registry of all open source licenses and important license exceptions, such that license statements can be reduced to simply stating short license identifiers.

• https://spdx.org/licenses/index.html
• https://spdx.org/licenses/exceptions-index.html

Complex Expressions

Not every source code is licensed under just one license. For example, you might want to state that a file can be used under the terms for the BSD-2-Clause license or under the terms of the GNU Public License version 2 or later. For these cases, the SPDX workgroup also provides a specification how state complex license statements (which we call "SPDX expressions"). The SPDX expression language also allows tooling based syntax checks, which enables us to use tools to check the correctness of license statements.

• https://spdx.org/specifications

For SPDX expressions that do not only consist of one SPDX identifier, the following keywords can be used (for details, see SPDX specification):

1. OR
2. AND
3. WITH

The preference order of these operators is as stated above (cf. SPDX Specification, Appendix IV), where a lower order operator is applied before a higher order operator. For example, for GPL-3.0-only OR LGPL-2.1-only_WITH_Qt-LGPL-exception-1.1 the Qt-LGPL-exception-1.1 applies only when using the code under the LGPL-2.1 license.

SPDX Expression Examples

A REUSE compliant license statement always has the form to first state the copyright holders and then to specify the license or licenses under which the source code can be used. The following example states that both Jane Doe and John Doe hold copyrights of the source code and that it can be used under the Lesser GNU Public License version 2.1 or any later version of this license:

/*
    SPDX-FileCopyrightText: 2019 Jane Doe <[email protected]>
    SPDX-FileCopyrightText: 2019-2020 John Doe <[email protected]>

    SPDX-License-Identifier: LGPL-2.1-or-later
*/

License Statements

We follow the recommendations from reuse.software how to state license and copyright information. You can use the following template and fill it with the missing information:

/*
    SPDX-FileCopyrightText: <year> <name> <contact-address>
    SPDX-FileCopyrightText: <year> <name> <contact-address>
    ...

    SPDX-License-Identifier: <SPDX-expression>
*/

SPDX-FileCopyrightText or Copyright Statement

A copyright statement shall always contain the name of the copyright holder, the year of publication and a contact address. According to the REUSE specification, there are several ways to state it correct. In KDE we prefer, for simplicity the following kind of statement:

1. SPDX-FileCopyrightText: 2019 Jane Doe <[email protected]>

For copyright statements, please ensure:

• Prefer "Copyright" or "SPDX-FileCopyrightText:" to state the copyright holders.
• State the copyright information in the order: year, name, contact address.
• Any contact address should be stated in angle brackets.
• The year of publication can be a single year, multiple years, or a span of years.

SPDX-License-Identifier Statement

The SPDX-License-Identifier tag must be followed by a valid SPDX License Expression.

Here are several example statements from the KDE project. For the list of all allowed licenses in the KDE project, please see the KDE Licensing Policy:

• SPDX-License-Identifier: LGPL-2.1-or-later
• SPDX-License-Identifier: LGPL-2.1-only OR LGPL-3.0-only OR LicenseRef-KDE-Accepted-LGPL
• SPDX-License-Identifier: LGPL-2.1-only WITH Qt-LGPL-exception-1.1
• SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
• SPDX-License-Identifier: GPL-2.0-or-later
• SPDX-License-Identifier: GPL-3.0-or-later
• SPDX-License-Identifier: MIT
• SPDX-License-Identifier: BSD-2-Clause

License Texts

Each repository shall contain a folder LICENSES/ in the root of the repository. In this folder, there shall be a license file for all (and only for those!) SPDX Identifiers that are used inside the project. The license file must be in plain text and state the license text.

For all SPDX identifiers and exception identifiers that are listed in the SPDX registry, use the https://github.com/fsfe/reuse-tool to download the correct license test with:

• reuse download <IDENTIFIER>

For example, in order to download the "LGPL-2.1-or-later" license file use the command reuse download LGPL-2.1-or-later, which places the file into the LICENSES/ folder of your project.

All SPDX identifiers that start with "LicenseRef-" are custom identifiers (cf. SPDX Specification, Section 6), which are not listed in the SPDX registry. The correct license file contents for

• LicenseRef-KDE-Accepted-LGPL
• LicenseRef-KDE-Accepted-GPL

are listed in the KDE Licensing Policy.

For details, check REUSE.software specification, Section "License Files".

License Compatibility

Unfortunately not every license can be combined with every other license. This is due to the fact that licenses may contain contradicting requirements that a licensee cannot fulfill at the same time. Thus, it is important to choose licenses that are compatible to each other.

This topic is discussed in depth e.g. by the Free Software Foundation. For the scope of this howto it is usually enough to remember:

• All source code files that are compiled into a binary artifact must be compatible with each other.
• A binary artifact is a (shared) library, a plugin or an executable.
• If you link an application with any GPL license dynamically to a library that has any LGPL, BSD or MIT license, then everything will be fine.
• For combination of differently licensed files see an Essay by David Wheeler, which is forms the base of the license compatibility matrix in the outbound license check generator.

License Tooling

REUSE Compliance Checking

As we follow the reuse.software specification, we can use their compliance tool to check the correctness of license statements. The tool is available via https://github.com/fsfe/reuse-tool or can simply be installed via pip:

pip3 install reuse

For details, see the README.md file. The most important options are:

• download : Download the specified license into the LICENSES/ directory.
• lint : Verify the project for REUSE compliance.

Please note that a positive result from this tool only tells that license statements are added in a reasonable way and not that the licenses that were chosen are reasonable (see license compatibility).

Outbound License Checking

The outbound license in this context describes the license a specific binary artifact has (contrary to the inbound license, which is the license of the source code files). In order to check that the individual file licenses are compatible with the desired outbound license, the compatibility of licenses has to be checked. A way to do this easily is to use the Outbound-License-Check Generator in Extra-Cmake-Modules (not yet released, probably part of KF5 5.75).

Conversion from Traditional License Headers to SPDX Expressions

In KDE, we have a tool called license-digger, which is prepared specifically for the license headers typically used in KDE projects. You can simply run it over a repository that you want to convert, review the changes it did and create a merge request.

For details about usage and extending it for not detected headers, see its README.md.

Frequently Asked Questions

Shall I add a COPYING or COPYING.LIB file to my repository?

No. Those files shall be replaced completely by files with a standardized naming and canonical license texts in the LICENSES/ subfolder of your repository. All files in that folder shall follow the REUSE specification. Discussion took place here.