Core Metadata

Es gibt zwei überlappende Core Metadata-Felder zur Dokumentation einer Lizenz: die Lizenz- Classifier Strings, die mit License :: beginnen, und das License Feld als Freitext.

Die Dokumentation des Core Metadata License Feldes ist derzeit

License
=======

.. versionadded:: 1.0

Text indicating the license covering the distribution where the license
is not a selection from the "License" Trove classifiers. See
:ref:`"Classifier" <metadata-classifier>` below.
This field may also be used to specify a
particular version of a license which is named via the ``Classifier``
field, or to indicate a variation or exception to such a license.

Examples::

    License: This software may only be obtained by sending the
            author a postcard, and then the user promises not
            to redistribute it.

    License: GPL version 3, excluding DRM provisions

Obwohl es zwei Felder gibt, ist es manchmal schwierig, etwas anderes als einfachere Lizenzierung zu vermitteln. Zum Beispiel fehlt einigen Klassifizierern die Präzision (GPL ohne Version), und wenn mehrere Lizenzklassifizierer aufgeführt sind, ist nicht klar, ob beide Lizenzen gelten müssen oder ob der Benutzer zwischen ihnen wählen kann. Darüber hinaus ist die Liste der verfügbaren Lizenzklassifizierer eher begrenzt und veraltet.

Setuptools und Wheel

Über einen Lizenzcode oder -qualifikator hinaus werden Lizenztextdateien entweder implizit oder explizit dokumentiert und in ein gebautes Paket aufgenommen, was eine weitere mögliche Quelle der Verwirrung darstellt.

• In den Projekten Setuptools und Wheel werden Lizenzdateien automatisch zur Distribution hinzugefügt (an ihrem Quellort in einer Quellcode-Distribution/sdist und im Verzeichnis .dist-info eines gebauten Wheels), wenn sie einem von mehreren gängigen Mustern für Lizenzdateinamen entsprechen (LICEN[CS]E*, COPYING*, NOTICE* und AUTHORS*). Alternativ kann ein Paketautor eine Liste von Pfaden zu Lizenzdateien angeben, die in das gebaute Wheel aufgenommen werden sollen, unter dem Schlüssel license_files im Abschnitt [metadata] der setup.cfg des Projekts oder als Argument für die Funktion setuptools.setup(). Derzeit, dem Beispiel des Wheel-Projekts folgend, flacht Setuptools die gesammelten Lizenzdateien in das Metadatenverzeichnis ab, überschreibt Dateien mit demselben Namen und speichert Lizenzdateien direkt im Stammverzeichnis .dist-info, aber es gibt einen Wunsch, beide Probleme zu lösen, abhängig von der Annahme von PEP 639.
• Beide Werkzeuge unterstützen auch einen älteren, einzelnen Parameter license_file, der nur die Angabe einer einzigen Lizenzdatei erlaubt, die der Distribution hinzugefügt werden soll. Dieser ist seit einiger Zeit veraltet, wird aber immer noch etwas verwendet.
• Nach der Veröffentlichung eines früheren Entwurfs von PEP 639 hat Setuptools Unterstützung für License-File in den Distributionsmetadaten gemäß dieser Spezifikation hinzugefügt. Dies ermöglicht es anderen Tools, die die resultierenden Metadaten verbrauchen, die Lizenzdatei(en) für ein gegebenes Paket eindeutig zu lokalisieren.

PyPA Packaging Guide und Beispielprojekt

Sowohl das Einsteiger-Tutorial von PyPA zur Paketierung als auch der umfassendere Packaging Guide besagen, dass es wichtig ist, dass jedes Paket eine Lizenzdatei enthält. Sie verweisen auf die LICENSE.txt im offiziellen Beispielprojekt von PyPA als Beispiel, die explizit unter dem Schlüssel license_files in seiner setup.cfg aufgeführt ist, entsprechend der durch PEP 639 formell spezifizierten Praxis.

Sowohl das Einsteiger-Tutorial zur Paketierung als auch das Beispielprojekt verwenden nur Klassifizierer, um die Lizenz eines Pakets zu deklarieren, und beinhalten oder erwähnen nicht das Feld License. Der vollständige Packaging Guide erwähnt dieses Feld zwar, erklärt jedoch, dass Autoren stattdessen Lizenzklassifizierer verwenden sollten, es sei denn, das Projekt verwendet eine nicht standardmäßige Lizenz (was der Guide nicht empfiehlt).

Python-Quellcodedateien

Hinweis: Die Dokumentation von Lizenzen im Quellcode liegt außerhalb des Umfangs von PEP 639.

Neben der Verwendung von Kommentaren und/oder SPDX-License-Identifier-Konventionen wird die Lizenz manchmal in Python-Code-Dateien mit einer Modul-weiten Konstante vom Typ „dunder“ dokumentiert, typischerweise benannt als __license__.

Diese Konvention, obwohl vielleicht etwas antiquiert, wird von der eingebauten Funktion help() und dem Standardmodul pydoc erkannt. Die Dunder-Variable erscheint im DATA-Abschnitt der help()-Ausgabe für ein Modul.

Linux-Distribution-Pakete

Hinweis: In den meisten Fällen sind die Texte der gängigsten Lizenzen global in einem gemeinsamen Dokumentationsverzeichnis enthalten (z.B. /usr/share/doc).

• Debian dokumentiert Paketlizenzen mit maschinell lesbaren Copyright-Dateien. Es definiert seine eigene Lizenzexpressionssyntax und Liste von Identifikatoren für gängige Lizenzen, die beide eng mit denen von SPDX verwandt sind.
• Fedora-Pakete geben an, wie Lizenztexte einzufügen sind und verwenden ein Lizenzfeld, das mit entsprechenden kurzen Lizenzidentifikatoren aus einer umfangreichen Liste von „Guten Lizenzen“ gefüllt werden muss. Fedora verwendet die SPDX-Lizenzexpressionssyntax.
• OpenSUSE-Pakete verwenden SPDX-Lizenzexpressionen mit SPDX-Lizenz-IDs und einer Liste zusätzlicher Lizenzidentifikatoren.
• Gentoo ebuilds verwenden eine LICENSE Variable. Dieses Feld ist in GLEP-0023 und im Gentoo-Entwicklerhandbuch spezifiziert. Gentoo definiert außerdem eine Liste erlaubter Lizenzen und eine Lizenzexpressionssyntax, die sich deutlich von SPDX unterscheidet.
• Das FreeBSD-Paket-Makefile bietet die Felder LICENSE und LICENSE_FILE mit einer Liste benutzerdefinierter Lizenzsymbole. Für nicht standardmäßige Lizenzen empfiehlt FreeBSD die Verwendung von LICENSE=UNKNOWN und das Hinzufügen der Felder LICENSE_NAME und LICENSE_TEXT sowie ausgefeilte Felder LICENSE_PERMS zur Qualifizierung der Lizenzberechtigungen und LICENSE_GROUPS zur Dokumentation einer Lizenzgruppierung. LICENSE_COMB ermöglicht die Dokumentation von mehr als einer Lizenz und deren Zusammenspiel, was eine benutzerdefinierte Lizenzexpressionssyntax bildet. FreeBSD empfiehlt auch die Verwendung von SPDX-License-Identifier in Quellcodedateien.
• Arch Linux PKGBUILD definiert seine eigenen Lizenzidentifikatoren. Der Wert 'unknown' kann verwendet werden, wenn die Lizenz nicht definiert ist.
• OpenWRT ipk-Pakete verwenden die Variablen PKG_LICENSE und PKG_LICENSE_FILES und empfehlen die Verwendung von SPDX-Lizenzidentifikatoren.
• NixOS verwendet SPDX-Identifikatoren und einige zusätzliche Lizenz-IDs in seinem Lizenzfeld.
• GNU Guix (basiert auf NixOS) hat ein einzelnes Lizenzfeld, verwendet seine eigene Liste von Lizenzsymbolen und gibt an, wie eine Lizenz oder eine Liste davon verwendet wird.
• Alpine Linux-Pakete empfehlen die Verwendung von SPDX-Identifikatoren im Lizenzfeld.

Sprach- und Anwendungspakete

• In Java definiert Maven POM ein licenses XML-Tag mit einer Liste von Lizenzen, jede mit einem Namen, einer URL, Kommentaren und einem „distribution“-Typ. Dies ist nicht obligatorisch und der Inhalt jedes Feldes ist nicht spezifiziert.
• Das JavaScript NPM package.json verwendet ein einzelnes Lizenzfeld mit einem SPDX-Lizenzexpression oder der ID UNLICENSED, falls keine angegeben ist. Eine Lizenzdatei kann alternativ über SEE LICENSE IN <filename> im einzelnen Feld license referenziert werden.
• Rubygems gemspec gibt entweder eine einzelne oder eine Liste von Lizenzstrings an. Die Beziehung zwischen mehreren Lizenzen in einer Liste ist nicht spezifiziert. Sie empfehlen die Verwendung von SPDX-Lizenzidentifikatoren.
• CPAN Perl-Module verwenden ein einzelnes Lizenzfeld, das entweder ein einzelner String oder eine Liste von Strings ist. Die Beziehung zwischen den Lizenzen in einer Liste ist nicht spezifiziert. Es gibt eine Liste benutzerdefinierter Lizenzidentifikatoren plus diese generischen Identifikatoren: open_source, restricted, unrestricted, unknown.
• Rust Cargo spezifiziert die Verwendung eines SPDX-Lizenzexpressions (v2.1) im Feld license. Es unterstützt auch eine alternative Ausdruckssyntax mit schrägstrichgetrennten SPDX-Lizenzidentifikatoren, und es gibt auch ein Feld license_file. Die crates.io Paketregistry verlangt, dass entweder die Felder license oder license_file beim Hochladen eines Pakets gesetzt sind.
• PHP composer.json verwendet ein Feld license mit einer SPDX-Lizenz-ID oder proprietary. Das Feld license ist entweder ein einzelner String, der der SPDX-Lizenzexpressionssyntax mit den Schlüsselwörtern and und or ähnelt; oder eine Liste von Strings, wenn es eine (disjunktive) Auswahl von Lizenzen gibt.
• NuGet-Pakete verwendeten früher nur eine einfache Lizenz-URL, spezifizieren aber jetzt die Verwendung eines SPDX-Lizenzexpressions und/oder des Pfads zu einer Lizenzdatei innerhalb des Pakets. Das NuGet.org-Repository gibt an, dass sie nur Lizenzexpressionen akzeptieren, die „von der Open Source Initiative oder der Free Software Foundation genehmigt wurden“.
• Go-Sprachmodule go.mod bieten keine Bestimmungen für Metadaten über Abhängigkeiten hinaus. Lizenzinformationen werden den Codeautoren und anderen Community-Paketmanagern zur Dokumentation überlassen.
• Die Dart/Flutter-Spezifikation empfiehlt die Verwendung einer einzelnen LICENSE-Datei, die alle Lizenztexte enthalten sollte, jeweils getrennt durch eine Zeile mit 80 Bindestrichen.
• Das JavaScript Bower license Feld ist entweder ein einzelner String oder eine Liste von Strings, die entweder SPDX-Lizenzidentifikatoren oder einen Pfad/URL zu einer Lizenzdatei verwenden.
• Das Cocoapods podspec license Feld ist entweder ein einzelner String oder eine Zuordnung mit den Schlüsseln type, file und text. Dies ist obligatorisch, es sei denn, es ist eine Datei LICENSE/LICENCE vorhanden.
• Haskell Cabal akzeptiert ab Version 2.2 einen SPDX-Lizenzexpression. Die verwendete Version der SPDX-Lizenzliste ist eine Funktion der Cabal-Version. Die Spezifikation bietet auch eine Zuordnung zwischen Legacy- (vor-SPDX) und SPDX-Lizenzidentifikatoren. Cabal spezifiziert auch ein Feld license-file(s), das Lizenzdateien auflistet, die mit dem Paket installiert werden sollen.
• Erlang/Elixir mix/hex package spezifiziert ein Feld licenses als eine erforderliche Liste von Lizenzstrings und empfiehlt die Verwendung von SPDX-Lizenzidentifikatoren.
• D Language dub packages definieren ihre eigene Liste von Lizenzidentifikatoren und eine Lizenzexpressionssyntax, ähnlich dem SPDX-Standard.
• Das R Package DESCRIPTION definiert seine eigene ausgefeilte Lizenzexpressionssyntax und Liste von Lizenzidentifikatoren. R hat eine einzigartige Methode zur Unterstützung von Spezifizierern für Lizenzversionen (wie z.B. LGPL (>= 2.0, < 3)) in seiner Lizenzexpressionssyntax.

Andere Ökosysteme

• Der SPDX-License-Identifier Header ist eine einfache Konvention zur Dokumentation der Lizenz innerhalb einer Datei.
• Die Free Software Foundation (FSF) fördert die Verwendung von SPDX-Lizenzidentifikatoren zur Klarheit in der GPL und anderen versionierten freien Softwarelizenzen.
• Die Free Software Foundation Europe (FSFE) fördert mit dem REUSE-Projekt die Verwendung von SPDX-License-Identifier.
• Der Linux-Kernel verwendet SPDX-License-Identifier und Teile der FSFE REUSE-Konventionen zur Dokumentation seiner Lizenzen.
• U-Boot war federführend bei der Verwendung von SPDX-License-Identifier im Code und folgt nun dem Linux-Ansatz.
• Die Projekte der Apache Software Foundation verwenden RDF DOAP mit einem einzelnen Lizenzfeld, das auf SPDX-Lizenzidentifikatoren verweist.
• Die Eclipse Foundation fördert die Verwendung von SPDX-license-Identifiers.
• Das ClearlyDefined-Projekt fördert die Verwendung von SPDX-Lizenzidentifikatoren und -expressionen zur Verbesserung der Lizenzklarheit.
• Das Android Open Source Project verwendet leere Tag-Dateien vom Typ MODULE_LICENSE_XXX, wobei XXX ein Lizenzcode wie BSD, APACHE, GPL usw. ist. Es wird auch eine Datei NOTICE verwendet, die Lizenz- und Benachrichtigungstexte enthält.