Zusammenfassung

Diese PEP definiert eine Spezifikation, wie Lizenzen in Python-Projekten dokumentiert werden.

Zu diesem Zweck

• Nimmt die SPDX-Lizenz-Ausdruck-Syntax als Mittel zur Angabe der Lizenz eines Python-Projekts an.
• Definiert, wie Lizenzdateien in Projekte, Quell- und Build-Distributionen einzubinden sind.
• Gibt die notwendigen Änderungen an den Kernmetadaten und den entsprechenden Pyproject-Metadaten-Schlüsseln an
• Beschreibt die notwendigen Änderungen an den Standards für die Quellverteilung (sdist), die erstellte Verteilung (Wheel) und das installierte Projekt.

Dies wird die Lizenzdeklaration für Paketautoren einfacher und weniger mehrdeutig machen, für Endbenutzer verständlicher und für Werkzeuge programmatisch verarbeitbar.

Die Änderungen aktualisieren die Spezifikation der Kernmetadaten auf Version 2.4.

Ziele

Der Umfang dieser PEP beschränkt sich auf die Abdeckung neuer Mechanismen zur Dokumentation der Lizenz eines Distributionspakets, insbesondere durch die Definition von

• einem Mittel zur Angabe eines SPDX Lizenz-Ausdrucks.
• einer Methode zur Einbindung von Lizenztexten in Distributionspakete und installierte Projekte.

Die von dieser PEP geforderten Änderungen wurden entwickelt, um die Auswirkungen zu minimieren und die Abwärtskompatibilität zu maximieren.

Nicht-Ziele

Diese PEP empfiehlt keinen bestimmten Lizenztyp, der von einem bestimmten Paketautor gewählt werden sollte.

Wenn Projekte sich entscheiden, die neuen Felder nicht zu verwenden, werden durch diese PEP keine zusätzlichen Einschränkungen beim Hochladen auf PyPI auferlegt.

Diese PEP befasst sich auch nicht mit der Lizenzdokumentation einzelner Dateien, obwohl dies ein untersuchter Bereich in einem Anhang ist, noch beabsichtigt sie, Fälle abzudecken, in denen die Quellverteilung und die Binärverteilung keine gleichen Lizenzen haben.

Motivation

Software muss lizenziert sein, damit andere als ihr Ersteller sie herunterladen, verwenden, teilen und ändern können. Heute gibt es mehrere Felder, in denen Lizenzen in Kernmetadaten dokumentiert werden, und es gibt Einschränkungen, was in jedem von ihnen ausgedrückt werden kann. Dies führt oft zu Verwirrung sowohl bei Paketautoren als auch bei Endbenutzern, einschließlich der für die Distribution zuständigen Wiederverpacker.

Dies hat eine Reihe von Lizenzdiskussionen und Problemen ausgelöst, unter anderem zu veralteten und mehrdeutigen PyPI-Klassifikatoren, Lizenzinteroperabilität mit anderen Ökosystemen, zu viele verwirrende Lizenzmetadatenoptionen, begrenzte Unterstützung für Lizenzdateien im Wheel-Projekt und dem Mangel an präzisen Lizenzmetadaten.

Infolgedessen weisen Python-Pakete im Durchschnitt tendenziell mehr mehrdeutige und fehlende Lizenzinformationen auf als andere gängige Ökosysteme. Dies wird durch die Statistikseite des ClearlyDefined-Projekts unterstützt, eine Initiative der Open Source Initiative zur Verbesserung der Lizenzklarheit anderer FOSS-Projekte, die alle Pakete von PyPI, Maven, npm und Rubygems abdeckt.

Die aktuellen Lizenzklassifikatoren könnten erweitert werden, um die gesamte Bandbreite der SPDX-Bezeichner abzudecken, während die mehrdeutigen Klassifikatoren (wie z.B. License :: OSI Approved :: BSD License) als veraltet markiert werden.

Es gibt jedoch mehrere Argumente gegen einen solchen Ansatz

• Es erfordert einen erheblichen Aufwand, die SPDX-Lizenzliste zu duplizieren und synchron zu halten.
• Es ist ein harter Bruch der Abwärtskompatibilität, der Paketautoren zwingt, auf neue Klassifikatoren zu aktualisieren, sobald PyPI die alten als veraltet markiert.
• Es deckt nur Pakete unter einer einzelnen Lizenz ab; es behandelt keine Projekte, die Abhängigkeiten bündeln (z.B. Setuptools), eine Lizenzauswahl anbieten (z.B. Packaging) oder neu lizenziert wurden, Code aus anderen Projekten adaptieren oder Schriften, Bilder, Beispiele, Binärdateien oder andere Inhalte unter anderen Lizenzen enthalten.
• Es erfordert, dass sowohl Autoren als auch Werkzeuge das PyPI-spezifische Klassifikatoren-System verstehen und implementieren.
• Es gibt keinen so klaren Hinweis darauf, dass ein Paket das neue System übernommen hat und entsprechend behandelt werden sollte.

Begründung

Eine Umfrage wurde durchgeführt, um die bestehenden Lizenzmetadatendefinitionen im Python-Ökosystem und in einer Vielzahl von anderen Paketsystemen, Linux-Distributionen, Sprachökosystemen und Anwendungen abzubilden.

Die Ergebnisse der Umfrage haben die Empfehlungen dieser PEP geleitet

• SPDX- und SPDX-ähnliche Syntaxen sind die beliebtesten Lizenz-Ausdrücke in vielen modernen Paketsystemen.
• Die meisten Free- and Open-Source-Software-Lizenzen verlangen von Paketautoren, ihren vollständigen Text in einem Distributionspaket einzufügen.

Daher führt diese PEP zwei neue Kernmetadatenfelder ein

• License-Expression, das eine eindeutige Möglichkeit bietet, die Lizenz eines Pakets mithilfe von SPDX-Lizenz-Ausdrücken anzugeben.
• License-File, das eine standardisierte Methode bietet, den vollständigen Text der Lizenz(en) mit dem Paket bei der Verteilung einzufügen und anderen Werkzeugen, die die Kernmetadaten konsumieren, das Auffinden der Lizenzdateien eines Distributionsarchivs ermöglicht.

Darüber hinaus baut diese Spezifikation auf bestehenden Praktiken in den Projekten Setuptools und Wheel auf. Eine aktuelle Version des Entwurfs dieser PEP ist im Packagging-Tool Hatch implementiert, und ein früherer Entwurf des Teils über Lizenzdateien ist in Setuptools implementiert.

Terminologie

Die Schlüsselwörter „MUST“, „MUST NOT“, „REQUIRED“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „MAY“ und „OPTIONAL“ in diesem Dokument sind wie in RFC 2119 beschrieben zu interpretieren.

Spezifikation

Die notwendigen Änderungen zur Implementierung dieser PEP umfassen

• Hinzufügungen zu den Kernmetadaten, wie in der Spezifikation definiert.
• Hinzufügungen zu den vom Autor bereitgestellten Projektquellmetadaten, wie in der Spezifikation definiert.
• Hinzufügungen zu den Standards für Quellverteilung (sdist), erstellte Verteilung (Wheel) und installierte Projekte.
• Leitfaden für Werkzeuge, die Legacy-Lizenzmetadaten behandeln und konvertieren, um sicherzustellen, dass die Ergebnisse konsistent und korrekt sind.

Beachten Sie, dass die Anleitung zu Fehlern und Warnungen für das Standardverhalten von Werkzeugen gilt; sie KÖNNEN strenger agieren, wenn Benutzer sie explizit dazu konfigurieren, z.B. über ein CLI-Flag oder eine Konfigurationsoption.

MIT
BSD-3-Clause
MIT AND (Apache-2.0 OR BSD-2-Clause)
MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
LicenseRef-Special-License OR CC0-1.0 OR Unlicense
LicenseRef-Proprietary

Use-it-after-midnight
Apache-2.0 OR 2-BSD-Clause
LicenseRef-License with spaces
LicenseRef-License_with_underscores

[project]
license = "MIT"

[project]
license = "MIT AND (Apache-2.0 OR BSD-2-clause)"

[project]
license = "MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)"

[project]
license = "LicenseRef-Proprietary"

[project]
license-files = ["LICEN[CS]E*", "AUTHORS*"]

[project]
license-files = ["licenses/LICENSE.MIT", "licenses/LICENSE.CC0"]

[project]
license-files = ["LICENSE.txt", "licenses/*"]

[project]
license-files = []

[project]
license-files = ["..\LICENSE.MIT"]

[project]
license-files = ["LICEN{CSE*"]

Abwärtskompatibilität

Das Hinzufügen eines neuen Feldes License-Expression in den Core Metadata und eines Top-Level-String-Werts für den Schlüssel license in der [project] Tabelle der pyproject.toml bedeutet eindeutig Unterstützung für die Spezifikation in diesem PEP. Dies vermeidet das Risiko, dass neue Werkzeuge einen Lizenz-Ausdruck als freiformatige Lizenzbeschreibung oder umgekehrt falsch interpretieren.

Das veraltete und abgelaufene Feld License in den Core Metadata, die Unter-Schlüssel der Tabelle license ( text und file) in der [project] Tabelle der pyproject.toml und Lizenzklassifikatoren behalten die Abwärtskompatibilität. Eine Entfernung wird einem zukünftigen PEP und einer neuen Version der Core Metadata-Spezifikation überlassen.

Die Spezifikation des neuen Feldes License-File in den Core Metadata und die Aufnahme der Dateien in die Distribution ist weitgehend abwärtskompatibel mit der bestehenden Verwendung dieses Feldes in vielen Packaging-Tools. Der neue Schlüssel license-files in der Tabelle [project] der pyproject.toml wird erst wirksam, wenn Benutzer und Tools ihn übernehmen.

Dieser PEP spezifiziert, dass Lizenzdateien in einem dedizierten licenses Unterverzeichnis des Verzeichnisses .dist-info platziert werden sollten. Dies ist neu und stellt sicher, dass Wheels, die diesem PEP folgen, anders lokalisierte Lizenzen im Vergleich zu denen haben, die über das frühere, Installer-spezifische Verhalten erstellt wurden. Dies wird durch eine neue Metadatenversion unterstützt.

Dies löst auch aktuelle Probleme, bei denen Lizenzdateien versehentlich überschrieben werden, wenn sie an verschiedenen Orten den gleichen Namen haben, was Wheels unverteilbar macht, ohne dass es bemerkt wird. Es verhindert auch Konflikte mit anderen Metadaten-Dateien im selben Verzeichnis.

Die Ergänzungen werden zu den Spezifikationen für Quellcode-Distribution (sdist), eingebaute Distribution (Wheel) und installierte Projekte hinzugefügt. Sie dokumentieren Verhaltensweisen, die unter ihren aktuellen Spezifikationen erlaubt sind, und koppeln sie an die neue Metadatenversion.

Dieser PEP schlägt vor, dass PyPI die Validierung der neuen Felder License-Expression und License-File implementiert, was keine Auswirkungen auf neue und bestehende Pakete hat, die hochgeladen werden, es sei denn, sie entscheiden sich ausdrücklich für die Verwendung dieser neuen Felder und halten sich nicht korrekt an die Spezifikation. Daher hat dies keine Auswirkungen auf die Abwärtskompatibilität und garantiert die Vorwärtskompatibilität, indem sichergestellt wird, dass alle Distributionen, die mit den neuen Feldern auf PyPI hochgeladen werden, der Spezifikation entsprechen.

Sicherheitsimplikationen

Dieser PEP hat keine absehbaren Sicherheitsauswirkungen: Das Feld License-Expression ist ein einfacher String und die Felder License-File sind Dateipfade. Keiner von beiden führt zu bekannten neuen Sicherheitsbedenken.

Wie man das lehrt

Die Mehrheit der Pakete verwendet eine einzelne Lizenz, was den Fall einfach macht: ein einzelner Lizenzidentifikator ist ein gültiger Lizenz-Ausdruck.

Benutzer von Packaging-Tools lernen den gültigen Lizenz-Ausdruck ihres Pakets durch die Nachrichten der Tools, wenn diese ungültige erkennen oder wenn das veraltete Feld License oder Lizenzklassifikatoren verwendet werden.

Wenn ein ungültiger License-Expression verwendet wird, können Benutzer ihr Paket nicht auf PyPI veröffentlichen, und eine Fehlermeldung hilft ihnen zu verstehen, dass sie SPDX-Identifikatoren verwenden müssen. Es wird möglich sein, eine Distribution mit falschen Lizenzmetadaten zu generieren, aber nicht, eine auf PyPI oder einem anderen Indexserver zu veröffentlichen, der die Gültigkeit von License-Expression erzwingt. Für Autoren, die das nun veraltete Feld License oder Lizenzklassifikatoren verwenden, können Packaging-Tools sie warnen und über den Ersatz, License-Expression, informieren.

Tools können auch bei der Konvertierung helfen und in vielen gängigen Fällen einen Lizenz-Ausdruck vorschlagen.

• Der Anhang Anhang: Mapping von Lizenzklassifikatoren zu SPDX-Identifikatoren bietet Tool-Autoren Empfehlungen, wie ein Lizenz-Ausdruck, der aus Legacy-Klassifikatoren generiert wird, vorgeschlagen werden kann.
• Tools können möglicherweise vorschlagen, wie ein bestehender License Wert in den Projekt-Quellmetadaten aktualisiert und in einen Lizenz-Ausdruck konvertiert wird, wie auch in diesem PEP spezifiziert.

Referenzimplementierung

Tools müssen die Unterstützung für das Parsen und Validieren von Lizenz-Ausdrücken im Feld License-Expression bereitstellen, wenn sie sich entscheiden, diesen Teil der Spezifikation zu implementieren. Es obliegt den Tools, ob sie die Validierung auf ihrer Seite implementieren möchten (z. B. wie hatch) oder eine der verfügbaren Python-Bibliotheken verwenden möchten (z. B. license-expression). Dieser PEP schreibt die Verwendung einer bestimmten Bibliothek nicht vor und überlässt es den Tool-Autoren, die beste Implementierung für ihre Projekte zu wählen.

Abgelehnte Ideen

Viele alternative Ideen wurden vorgeschlagen und nach sorgfältiger Prüfung abgelehnt. Die vollständige Liste einschließlich der Gründe für die Ablehnung finden Sie auf einer separaten Seite.

Anhänge

Eine Liste von Hilfsdokumenten wird bereitgestellt.

• Detaillierte Lizenzierungsbeispiele,
• Benutzerszenarien,
• Lizenzdokumentation in Python und anderen Projekten,
• Mapping von Lizenzklassifikatoren zu SPDX-Identifikatoren,
• Abgelehnte Ideen im Detail.

Danksagungen

• Alyssa Coghlan
• Kevin P. Fleming
• Pradyun Gedam
• Oleg Grenrus
• Dustin Ingram
• Chris Jerdonek
• Cyril Roelandt
• Luis Villa
• Seth M. Larson
• Ofek Lev

Urheberrecht

Dieses Dokument wird gemeinfrei oder unter der CC0-1.0-Universal-Lizenz, je nachdem, was zulässiger ist, veröffentlicht.