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

Attachment: signature.asc
Description: PGP signature

Reply via email to