Hi all! With RFC0016 [1] we have worked out a way to reason about SPDX license identifiers [2] in the context of PKGBUILDs and packages. Over the past months I have worked on the licenses package [3], as well as namcap [4] to create the integration for all packagers. This mail serves as a refresher and general overview of what this means for packagers. TL;DR: Namcap now emits more specific error messages and there are probably a few things in this mail that you will want to learn about! :) To be able to be more specific in the below text, I will use this mini-glossary to explain what some words refer to: * *known* licenses and exceptions - Licenses and license exceptions *known* to SPDX (i.e. they are in the lists [2][5]). * *unknown* licenses and exceptions - Licenses and license exceptions *not known* to SPDX (i.e. they are *not* in the lists [2][5]). License identifiers prefixed with "LicenseRef-" are not considered. * *common* licenses and exceptions - Licenses and license exceptions that are packaged in the context of the licenses package [3] and can be shared *commonly*. * *uncommon* licenses and exceptions - Licenses and license exceptions that are *known*, but are *not common* (i.e. they are in the lists [2][5] but not in the licenses package [3]). License identifiers prefixed with "LicenseRef-" are always considered *uncommon*. For packagers a few things change when it comes to handling license information for packages. * It is encouraged to have a look at the list of *known* license identifiers [2] and exceptions [5] to familiarize yourself with how identifiers look like. The *common* licenses can be found in /usr/share/licenses/spdx/ and the *common* license exceptions in /usr/share/licenses/spdx/exceptions/. * The `license` array in PKGBUILDs should now start to contain valid SPDX license identifiers [2][5] or custom license identifiers, that are prefixed with "LicenseRef-" (e.g. "LicenseRef-Custom-License-1.0"). To keep complex scenarios maintainable and readable, each entry in the `license` array may be interpreted as being concatenated by the `AND` license expression [6]. * We now distinguish between various versions of some identifiers (e.g. previously we were okay with simple identifiers such as "GPL3" but now we have "GPL-3.0-only" and "GPL-3.0-or-later", which are separate from one another). If you are unsure about what applies, either contact upstream or reach out over mail, IRC, Matrix to ask other packagers. * If in doubt, rather be more specific than less specific! * To aide in documenting copyright and attribution, many upstreams rely on SPDX License IDs [7], which are added as comments at the top of each source file. These often help a great deal in figuring out which specific licenses apply and help in finding out whether there are any license files missing. To help you with figuring things out, namcap gained a few more features with > 3.5.0 (although some issues had to be ironed out up until 3.5.2 and I seriously hope I didn't introduce even more bugs ;-)). Please remember that namcap does not take away the work of investigating and providing the correct license identifiers for you! * Namcap now emits errors on all *unknown* license identifiers [2] and license exceptions [5]. * Namcap now lists all *uncommon* licenses and license exceptions while providing an overview about how many license files it found for the amount of *uncommon* identifiers (each *uncommon* identifier requires a separate file). * Namcap now emits errors with suggestions on formatting issues of license expressions (e.g. `MIT and Apache-2.0` -> `MIT AND Apache-2.0`). * Namcap now emits errors on license strings that can not be parsed. * Namcap now emits errors when the license directory is a symlink to a location in another package, that is not in `depends`. * Namcap now emits errors when the license directory is a symlink to a location in another package and license files are missing for *uncommon* identifiers. * Namcap now emits warnings if it detects symlinks for the license directory or single license files to another package. This is done because it is *very* cumbersome and error-prone to detect files in other packages reliably (e.g. those could in turn be symlinks to non-existent files, etc.). It is encouraged to package license files per package! Symlinks in the same package are fine! I hope this summary was not too overwhelming and will help you to get through the licensing jungle! Please do note, that the Arch Wiki section on license identifiers in the PKGBUILD article [8] still needs to be adapted. If there are any questions, please reach out! Many thanks to everyone who worked on the RFC and helped with testing the implementation! Best, David [1] https://rfc.archlinux.page/0016-spdx-license-identifiers/ [2] https://spdx.org/licenses/ [3] https://archlinux.org/packages/core/any/licenses/ [4] https://gitlab.archlinux.org/pacman/namcap/ [5] https://spdx.org/licenses/exceptions-index.html [6] https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ [7] https://spdx.dev/learn/handling-license-info/ [8] https://wiki.archlinux.org/title/PKGBUILD#license -- https://sleepmap.de