Das Feld License wiederverwenden

Nach erster Diskussion schlugen frühere Versionen von PEP 639 die Wiederverwendung des bestehenden License Feldes vor, das von Werkzeugen als SPDX-Lizenz-Ausdruck mit einem Fallback auf Freitext versucht werden sollte zu parsen. Anfangs würde dies eine Warnung verursachen und schließlich als Fehler behandelt werden.

Dies wäre rückwärtskompatibler, würde eine reibungslose Einführung von SPDX-Lizenz-Ausdrücken in der Community ermöglichen und das Hinzufügen eines weiteren lizenzbezogenen Feldes vermeiden.

Schließlich wurde Konsens darüber erzielt, dass ein dediziertes License-Expression Feld ein besserer Ansatz ist. Die Anwesenheit dieses Feldes signalisiert eindeutig die Unterstützung für die SPDX-Identifikatoren, ohne die Notwendigkeit komplexer Heuristiken, und ermöglicht Werkzeugen, ungültige Inhalte leicht zu erkennen.

Darüber hinaus ermöglicht es, sowohl das bestehende License Feld als auch die Lizenz-Klassifikatoren leicht zu deprecaten, wobei Werkzeuge zwischen Paketen unterscheiden können, die PEP 639 entsprechen oder nicht, und ihr Verhalten entsprechend anpassen können.

Schließlich vermeidet es, das Verhalten eines bestehenden Metadatenfeldes zu ändern und vermeidet, dass Werkzeuge die Metadata-Version und das Feldverhalten basierend auf seinem Wert und nicht nur auf seiner Anwesenheit erraten müssen.

Distributionen, die bereits gültige SPDX-Lizenz-Ausdrücke im License Feld enthalten, werden nicht automatisch als solche erkannt. Die Migration ist jedoch einfach, und PEP 639 bietet Anleitungen, wie dies automatisch durch Werkzeuge erfolgen kann.

Das Feld License mit einem Wertepräfix wiederverwenden

Als Alternative zum vorherigen wurde vorgeschlagen, SPDX-Lizenz-Ausdrücke z.B. mit spdx: zu präfixieren, um die Mehrdeutigkeit der Wiederverwendung des License Feldes zu reduzieren. Dies lief jedoch effektiv darauf hinaus, ein Feld innerhalb eines Feldes zu erstellen, und adressiert nicht die Nachteile der Beibehaltung des License Feldes. Nämlich ändert es immer noch das Verhalten eines bestehenden Metadatenfeldes, erfordert, dass Werkzeuge seinen Wert parsen, um zu bestimmen, wie sein Inhalt behandelt werden soll, und macht den Spezifikations- und Deprekationsprozess komplexer und weniger sauber.

Projekte, die derzeit gültige SPDX-Identifikatoren im License Feld verwenden, werden nicht automatisch erkannt und erfordern ungefähr den gleichen Aufwand zur Behebung wie bei der Einführung eines neuen Feldes, nämlich das Ändern einer Zeile in den Quellmetadaten des Projekts. Daher wurde es zugunsten eines neuen Feldes abgelehnt.

License-Expression nicht gegenseitig ausschließend machen

Aus Gründen der Abwärtskompatibilität könnten das License Feld und/oder die Lizenz-Klassifikatoren zusammen mit dem neuen License-Expression Feld weiterhin erlaubt sein, vermutlich mit einer Warnung. Dies könnte jedoch leicht zu inkonsistenten Lizenzmetadaten in nicht weniger als *drei* verschiedenen Feldern führen, was dem Ziel von PEP 639 widerspricht, die Lizenzierung unmissverständlich zu machen. Daher wurde diese Idee mit Konsens der Community abgelehnt.

Bestehendes License Feld und Klassifikatoren nicht deprecaten

Mehrere Community-Mitglieder äußerten Bedenken, dass die Deprekation des bestehenden License Feldes und der Klassifikatoren zu viel Aufwand für Paketautoren bedeuten und die Einstiegshürde für neue Autoren erhöhen würde, insbesondere für Entwickler, die ihre persönlichen Projekte verpacken möchten, ohne sich zu sehr um die rechtlichen technischen Details zu kümmern. Tatsächlich sollte jede Deprekation sorgfältig im Verhältnis zum langfristigen Nettonutzen abgewogen werden. Zumindest sollte diese Änderung es für einen Python-Entwickler nicht schwieriger machen, seine Arbeit unter einer Lizenz seiner Wahl zu teilen, und idealerweise die Situation verbessern.

Nach vielen Diskussionsrunden war der allgemeine Konsens zugunsten der Deprekation der alten Mittel zur Angabe einer Lizenz und zugunsten von „einem offensichtlichen Weg, dies zu tun“. Andernfalls würden drei verschiedene nicht-deprecatede Wege zur Angabe einer Lizenz für ein Paket verbleiben, zwei davon mehrdeutig, inkonsistent dokumentiert und veraltet. Dies ist für Werkzeuge schwieriger auf Dauer zu unterstützen und führt zu nicht unerheblichen Wartungskosten.

Schließlich ist für nicht gewartete Pakete, für solche, die Werkzeuge verwenden, die ältere Metadatenversionen unterstützen, oder für diejenigen, die keine Lizenzmetadaten bereitstellen möchten, keine Änderung erforderlich, unabhängig von der Deprekation.

Neue Felder auf PyPI nicht validieren

Zuvor gab PEP 639 keine spezifischen Anleitungen für PyPI (oder andere Paketindizes), ob und wie sie die Felder License-Expression oder License-File validieren sollten, noch wie sie deren Verwendung in Kombination mit dem deprecateden License Feld oder den Lizenz-Klassifikatoren handhaben sollten. Dies vereinfacht die Spezifikation und verschiebt die Implementierung auf PyPI auf eine spätere PEP, um Störungen für Paketautoren zu minimieren.

Dies war in einem früheren Entwurf von PEP 639 der Fall, der License-Expression nicht vom License Feld trennte. Die Validierung wäre schwierig und abwärtsinkompatibel gewesen und hätte bestehende Pakete zerstört. Mit dem aktuellen Vorschlag gab es einen klaren Konsens, dass das neue Feld von Anfang an validiert werden sollte, um zu garantieren, dass alle Distributionen, die auf PyPI hochgeladen werden, die Core Metadata Version 2.4 oder höher deklarieren und das Feld License-Expression haben, einen gültigen Ausdruck haben werden, so dass PyPI und Konsumenten seiner Pakete und Metadaten darauf vertrauen können, die hier angegebene Spezifikation zu befolgen.

Das Gleiche kann auch auf das neue Feld License-File ausgedehnt werden, um sicherzustellen, dass es gültig ist und die rechtlich erforderlichen Lizenzdateien vorhanden sind. Um es klarzustellen, dies würde nicht erfordern, dass jede hochgeladene Distribution solche Metadaten hat, sondern nur, dass wenn sie sich entscheiden, diese gemäß der Spezifikation in PEP 639 zu deklarieren, sie garantiert gültig ist.

Neue Unter-Schlüssel zur Tabelle hinzufügen

Es gab Vorschläge, verschiedene Unter-Schlüssel zur Tabelle hinzuzufügen. Die Kombination verschiedener Arten von Metadaten, die unterschiedliche Handhabung erfordern, das Hinzufügen neuer Anleitungen bezüglich der gegenseitigen Ausschließung von Unter-Schlüsseln und die Möglichkeit, einige davon als dynamisch zu definieren, würde den Übergang erschweren und mehr Verwirrung als Klarheit für die Benutzer schaffen. Dieser Ansatz wurde zugunsten eines flacheren pyproject.toml Designs, einer klaren Zuordnung zwischen pyproject.toml Schlüsseln und Core Metadata Feldern sowie einer erhöhten Lesbarkeit der separaten Schlüssel abgelehnt.

Abgelehnte Vorschläge

• Unter-Schlüssel expression und files zur Tabelle hinzufügen
• Einen Unter-Schlüssel expression anstelle eines String-Wertes hinzufügen
• Einen type Schlüssel hinzufügen, um text als Ausdruck zu behandeln

Einen neuen Top-Level-Schlüssel license-expression definieren

Eine frühere Version von PEP 639 definierte eine neue, Top-Level license-expression unter der [project] Tabelle, anstatt den String-Wert des license Schlüssels zu verwenden. Dies wurde als klarer für Leser und Schreiber angesehen, im Einklang mit den Zielen von PEP 639.

Während Unterschiede zu bestehenden Werkzeugformaten (und Core Metadata Feldnamen) in PEP 621 Präzedenzfälle haben, gibt es für die Wiederverwendung eines bestehenden Schlüssels für eine andere Bedeutung (und Zuordnung zu einem anderen Core Metadata Feld) mit unterschiedlicher und inkompatibler Syntax keinen Präzedenzfall und könnte zu Mehrdeutigkeiten für Leser und Autoren führen.

Auch gemäß der Spezifikation der Projekt-Source-Metadaten würde dies erlauben, die [project] Schlüssel, die den License und License-Expression Metadatenfeldern entsprechen, separat als dynamic zu kennzeichnen, was eine potenzielle Sorge bei der Rückfüllung des License Feldes aus dem License-Expression Feld vermeidet, wie PEP 639 dies derzeit ohne license als dynamisch erlaubt (was nicht möglich wäre, da beide demselben Top-Level-Schlüssel zugeordnet sind).

Der Community-Konsens bevorzugte jedoch die Verwendung des Top-Level-String-Wertes des bestehenden license Schlüssels, da dieser von PEP 621 für diesen Zweck reserviert wurde.

Ein praktischer String-Wert für den Lizenzschlüssel wurde absichtlich weggelassen, um eine zukünftige PEP zu ermöglichen, die die Unterstützung für SPDX-Ausdrücke spezifiziert (die gleiche Logik gilt für jede Art von „Typ“-Feld, das angibt, welche Lizenz die Datei oder der Text repräsentiert).

Dies ist für Benutzer einfacher zu merken und einzugeben, vermeidet das Hinzufügen eines neuen Top-Level-Schlüssels und nutzt gleichzeitig einen bestehenden, leitet Benutzer zur Verwendung eines Lizenz-Ausdrucks als Standard an und folgt dem, was im ursprünglichen PEP 621 vorgesehen war.

Zusätzlich ermöglicht dies die saubere Deprekation der Tabellenwerte, ohne den Schlüssel selbst zu deprecaten, und macht sie gegenseitig ausschließend, ohne dass Benutzer sich daran erinnern und Werkzeuge sie erzwingen müssen.

Schließlich war die Konsistenz mit anderen Werkzeugformaten und der zugrundeliegenden Core Metadata keine ausreichende Priorität, um die Vorteile der Verwendung des bestehenden Schlüssels zu überwiegen, und die dynamic Bedenken wurden größtenteils durch die Nicht-Spezifikation der Legacy-Lizenz-zu-Lizenz-Ausdruckskonvertierung zur Build-Zeit, die explizite Angabe der Rückfüllung des License Feldes, wenn nicht dynamic, und die Tatsache, dass beide Felder gegenseitig ausschließend sind, so dass es wenig praktischen Bedarf gibt, zu unterscheiden, welches dynamisch ist, gemildert.

Daher wurde für PEP 639 ein Top-Level-String-Wert für license übernommen, wie ein früherer Arbeitsentwurf vorübergehend spezifiziert hatte.

Gegenseitig ausschließende Unter-Schlüssel paths und globs für license-files definieren

Ein früherer Entwurf der PEP spezifizierte gegenseitig ausschließende Unter-Schlüssel paths und globs des license-files [project] Tabellenschlüssels. Dies wurde vorgeschlagen, um die maximale Klarheit der definierten Werte sowohl für Benutzer als auch für Werkzeuge zu erreichen. Das Zulassen der Angabe von Lizenzdateien als Literalpfade würde Randfälle vermeiden, wie z.B. solche, die Glob-Zeichen enthalten (oder solche, die ihnen verwirrenderweise ähneln, wie in PEP 672 beschrieben).

Dieser Ansatz führt jedoch zu einer zusätzlichen Verschachtelungsebene – auf die gleiche Weise, wie PEP 639 den license Schlüssel reduziert. Dies belastet Projektmanager stärker, die eine der beiden Ansätze zur Angabe des Speicherorts ihrer Lizenzdateien disambiguieren und auswählen müssen. Es wurde darauf hingewiesen, dass man leicht fälschlicherweise annehmen kann, dass Pfade auch Globs unterstützen.

Daher wurde zugunsten eines flachen Array-Wertes, der die Spezifikation und Implementierung vereinfacht und dem Konfigurationsformat bestehender Werkzeuge stärker entspricht, von diesem Ansatz abgewichen. Die PEP empfiehlt, keine anderen als alphanumerische Symbole und Punkte (.) in den Dateinamen zu verwenden, um keine Verwirrung bei der Interpretation von Glob-Mustern zu erzeugen.

Nur verbatim Pfade akzeptieren

Globs könnten als Werte für den license-files Schlüssel in pyproject.toml nicht zugelassen und nur verbatim Pfade erlaubt werden. Dies würde sicherstellen, dass alle Lizenzdateien explizit angegeben, gefunden und eingeschlossen werden, und die Quellmetadaten sind im strengsten Sinne des Begriffs vollständig statisch, ohne dass Werkzeuge den Rest der Projektquellendateien untersuchen müssen, um genau zu bestimmen, welche Lizenzdateien enthalten sein werden und was die Werte von License-File sein werden. Dies würde auch die Spezifikation und Tool-Implementierung vereinfachen.

Hier schlägt jedoch die Praktikabilität die Reinheit. Globs werden bereits von vielen bestehenden Werkzeugen unterstützt, und die explizite Angabe des vollständigen Pfads zu jeder Lizenzdatei wäre für komplexe Projekte mit gebündelten Abhängigkeiten unnötig mühsam. Kritischer wäre, dass es viel einfacher wäre, versehentlich eine erforderliche rechtliche Datei zu übersehen, was das Paket illegal zu vertreiben macht.

Werkzeuge können die einzuschließenden Dateien immer noch bestimmen, basierend nur auf den vom Benutzer angegebenen Glob-Mustern und den Dateinamen im Paket, ohne es zu installieren, seinen Code auszuführen oder sogar seine Dateien zu untersuchen. Und natürlich werden sdists, wheels und andere die vollständige statische Liste der Dateien haben, die in ihren Distributionsmetadaten angegeben sind.

Einen Standardwert für license-files verwenden, wenn nicht angegeben

Ein früherer Entwurf der PEP schlug einen Standardwert für die Erkennung von Lizenzdateien vor, falls die Benutzer keine deklariert und den Schlüssel nicht als dynamisch markiert haben. Dieser Wert wurde als Array von Globs definiert: ["LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"]

Dies würde jedoch eine Ausnahme unter den bestehenden Metadaten darstellen, da kein anderer Schlüssel implizite Standardwerte hat. Implizite Werte in pyproject.toml Schlüsseln werden der dynamic Liste zugewiesen, die als berechnet spezifiziert ist. Außerdem wurden die Werte willkürlich gewählt, ohne starke Begründung, warum sie einen Standard darstellen sollten.

Muss als dynamisch markiert werden, um Standardwerte zu verwenden

Mit einer restriktiven Interpretation der PEP 621 Beschreibung der dynamic Liste mag es sinnvoll erscheinen, zu verlangen, dass der license-files Schlüssel als dynamic markiert wird, damit die Standard-Glob-Muster verwendet werden können, oder alternativ, damit Lizenzdateien abgeglichen und eingeschlossen werden.

Dies ist jedoch nur die Deklaration eines statischen, streng spezifizierten Standardwerts, der von allen konformen Werkzeugen genau verwendet werden muss, ähnlich wie jeder andere Satz von Glob-Mustern, die der Benutzer selbst angeben kann. Die resultierenden License-File Core Metadata Werte können durch Inspektion einer Liste von Dateien in der Quelle ermittelt werden, ohne Code auszuführen oder sogar den Dateiinhalt zu untersuchen.

Darüber hinaus wäre diese Interpretation, selbst wenn dies nicht der Fall wäre, abwärtsinkompatibel mit dem bestehenden Format und inkonsistent mit dem Verhalten bestehender Werkzeuge. Weiterhin würde dies ein ernsthaftes Risiko eines großen Teils von Projekten bergen, die unwissentlich keine rechtlich vorgeschriebenen Lizenzdateien mehr enthalten, und ist daher kein sinnvoller Standard.

Schließlich ermöglicht die Nicht-Deklaration des Standards als dynamisch den Autoren, eindeutig anzuzeigen, wann ihre Build-/Paketierungs-Tools für die Einbeziehung von Lizenzdateien selbst zuständig sind; alles andere würde den Zweck der dynamic Liste verfehlen.

Lizenzdateien in Unterverzeichnissen abflachen

Frühere Entwürfe von PEP 639 spezifizierten nicht, wie mit Lizenzdateien in Unterverzeichnissen umzugehen ist. Derzeit flachen die Projekte Wheel und Setuptools alle Lizenzdateien in das Verzeichnis .dist-info ab, ohne die Unterverzeichnishierarchie des Quellcodes beizubehalten.

Während dieser Ansatz der bestehenden Ad-hoc-Praxis entspricht, kann er zu Namenskonflikten und dem Überschreiben von Lizenzdateien führen, ohne dass ein definiertes Verhalten für deren Auflösung besteht, und das Paket rechtlich nicht vertreibbar machen, ohne klare Angabe, dass die angegebenen Lizenzdateien nicht enthalten waren.

Darüber hinaus führt dies zu inkonsistenten relativen Dateipfaden für Nicht-Root-Lizenzdateien zwischen Quelle, sdist und Wheel und verhindert, dass die in den „statischen“ [project] Tabellenmetadaten angegebenen Pfade wirklich statisch sind. Schließlich hält die Verzeichnisstruktur des Quellcodes oft wertvolle Informationen darüber, wofür die Lizenzen gelten, was beim Abflachen verloren geht und nur mit erheblichem Aufwand rekonstruiert werden kann.

Um dies zu lösen, schlägt die PEP nun vor, die Verzeichnisstruktur des Quellcodes der ursprünglichen Lizenzdateien im Verzeichnis .dist-info zu reproduzieren. Der einzige Nachteil dieses Ansatzes ist ein verschachtelteres Verzeichnis .dist-info. Der folgende Vorschlag, die Lizenzdateien unter einem Unterverzeichnis licenses zu wurzeln, eliminiert sowohl Namenskollisionen als auch das Durcheinanderproblem vollständig.

Namenskonflikte anders auflösen

Anstatt die Verzeichnisstruktur des Quellcodes für Lizenzdateien im Verzeichnis .dist-info beizubehalten, könnten wir einen anderen Mechanismus zur Konfliktlösung spezifizieren, wie z.B. das Vor- oder Anhängen des Elternverzeichnisnamens an den Lizenzdateinamen, das Durchlaufen des Baums, bis der Name eindeutig war, um übermäßig verschachtelte Verzeichnisse zu vermeiden.

Dies würde jedoch die Probleme mit der Pfadkonsistenz nicht beheben, würde viel mehr Diskussion erfordern und die Spezifikation weiter verkomplizieren. Daher wurde es zugunsten der offensichtlicheren Lösung, einfach das Unterverzeichnislayout des Quellcodes beizubehalten, abgelehnt, wie es von vielen Stakeholdern befürwortet wurde.

Direkt in .dist-info ablegen

Zuvor wurden die eingeschlossenen Lizenzdateien direkt im Top-Level-Verzeichnis .dist-info von gebauten Wheels und installierten Projekten gespeichert.

Dies führt jedoch zu einem unübersichtlicheren .dist-info Verzeichnis, im Gegensatz zur Trennung von Lizenzen in einen eigenen Namespace. Es besteht weiterhin die Gefahr von Kollisionen mit benutzerdefinierten Lizenzdateinamen (z.B. RECORD, METADATA) im .dist-info Verzeichnis, was die Beschränkung der potenziellen Dateinamen erfordern würde. Schließlich würde das Platzieren von Lizenzen in einem eigenen spezifizierten Unterverzeichnis es Menschen und Werkzeugen ermöglichen, alle gleichzeitig korrekt zu manipulieren (z.B. bei Distribution-Packaging, rechtlichen Prüfungen usw.), ohne ihre Pfade aus den Core Metadata referenzieren zu müssen.

Daher ist die einfachste und offensichtlichste Lösung, wie von mehreren auf den Wheel- und Setuptools-Implementierungsseiten vorgeschlagen, die Lizenzdateien relativ zu einem Unterverzeichnis licenses von .dist-info zu wurzeln. Dies ist einfach zu implementieren und löst alle hier genannten Probleme, ohne wesentliche Nachteile im Vergleich zu anderen komplexeren Optionen.

Es macht die Spezifikation zwar etwas komplexer, die Implementierung sollte jedoch ebenso einfach bleiben. Es bedeutet, dass Wheels, die nach dieser Änderung produziert werden, anders lokalisierte Lizenzen haben werden als zuvor, aber da dies bereits für die in Unterverzeichnissen befindlichen galt und bis PEP 639 kein programmatischer Zugriff auf diese Dateien möglich war, sollte dies in der Praxis keine signifikanten Probleme verursachen.

Füge eine neue licenses Kategorie zu Wheel hinzu

Anstatt ein Root-Lizenzverzeichnis (licenses) innerhalb des Core Metadata Verzeichnisses (.dist-info) für Wheels zu definieren, könnten wir stattdessen eine neue Kategorie (und vermutlich ein entsprechendes Installationsschema) definieren, ähnlich den anderen, die derzeit unter .data im Wheel-Archiv enthalten sind, speziell für Lizenzdateien, genannt (z.B.) licenses. Dies wurde vom Wheel-Ersteller erwähnt und würde die Installation von Lizenzen an einem plattformgerechteren und flexibleren Ort als nur im Verzeichnis .dist-info im Site-Pfad ermöglichen.

Derzeit implementiert PEP 639 diese Idee jedoch nicht, und sie wird auf eine zukünftige PEP verschoben. Sie würde PEP 639 erhebliche Komplexität und Reibung hinzufügen, da sie sich hauptsächlich mit der Standardisierung der bestehenden Praxis und der Aktualisierung der Core Metadata Spezifikation befasst. Darüber hinaus könnte dies die Änderung von sysconfig und den dort spezifizierten Installationsschemata sowie von Wheel, Installer und anderen Werkzeugen erfordern, was eine nicht unerhebliche Aufgabe wäre. Obwohl potenziell geringfügig komplexer für Repacker, stellt der aktuelle Vorschlag immer noch sicher, dass alle Lizenzdateien in einem einzigen dedizierten Verzeichnis enthalten sind, und sollte somit den Status quo in dieser Hinsicht erheblich verbessern.

Zusätzlich ist dieser Ansatz nicht vollständig abwärtskompatibel (da er für Werkzeuge, die das Wheel einfach extrahieren, nicht transparent ist), stellt eine größere Abweichung von der bestehenden Praxis dar und würde zu inkonsistenteren Lizenzinstallationsorten von Wheels unterschiedlicher Versionen führen. Schließlich würden Lizenzen nicht mehr so nah an ihrem zugehörigen Code installiert werden, es gäbe mehr Variabilität im Lizenz-Root-Pfad über Plattformen hinweg und zwischen gebauten Distributionen und installierten Projekten, der programmatische Zugriff auf installierte Lizenzen wäre schwieriger, und ein geeigneter Installationsort und -methode müssten geschaffen werden, um Namenskonflikte zu vermeiden.

Daher wurde der aktuelle Ansatz beibehalten, um PEP 639 im Umfang zu halten.

Benenne das Unterverzeichnis license_files

Sowohl licenses als auch license_files wurden als potenzielle Namen für das Root-Lizenzverzeichnis innerhalb von .dist-info von Wheels und installierten Projekten vorgeschlagen. Ein erster Entwurf der PEP spezifizierte letzteres, da es etwas klarer und konsistenter mit dem Namen des Core Metadata Feldes (License-File) und dem [project] Tabellenschlüssel (license-files) war. Die aktuelle Version der PEP übernimmt jedoch den Namen licenses, aufgrund einer allgemeinen Präferenz der Community für dessen kürzere Länge und das Fehlen eines Trennzeichens.

Identifikatoren Lizenzdateien zuordnen

Dies würde die Verwendung einer Zuordnung erfordern, die die Dokumentation von Lizenzen zusätzlich erschwert und eine weitere Verschachtelungsebene hinzufügt.

Eine Zuordnung wäre notwendig, da nicht garantiert werden kann, dass alle Ausdrücke (Schlüssel) eine einzelne zugeordnete Lizenzdatei haben (z.B. GPL mit einer Ausnahme kann in einer einzigen Datei sein) und dass ein Ausdruck nicht mehr als eine hat. (z.B. eine Apache-Lizenz LICENSE und ihre NOTICE Datei sind zwei verschiedene Dateien). Für die häufigsten Fälle wäre ein einzelner Lizenzausdruck und ein oder mehrere Lizenzdateien völlig ausreichend. In den selteneren und komplexeren Fällen, in denen viele Lizenzen beteiligt sind, können Autoren die hier spezifizierten Felder immer noch sicher verwenden, nur mit einem leichten Klarheitsverlust, da sie nicht angeben, welche Textdatei(en) welcher Lizenz-ID zugeordnet sind (obwohl jede Lizenz-ID eine entsprechende SPDX-registrierte vollständige Lizenztext hat), während die komplexere Zuordnung nicht der großen Mehrheit der Benutzer aufgedrängt wird, die sie nicht benötigen oder wollen.

Wir könnten natürlich ein Datenfeld mit mehreren möglichen Wertetypen haben, aber dies könnte eine Quelle der Verwirrung sein. Dies ist, was beispielsweise in npm (historisch) und in Rubygems (immer noch heute) getan wurde, und infolgedessen müssen Werkzeuge den Typ des Metadatenfeldes testen, bevor sie es im Code verwenden, während Benutzer verwirrt sind, wann sie eine Liste oder eine Zeichenkette verwenden sollen. Daher wird dieser Ansatz abgelehnt.

Identifikatoren Quellcode-Dateien zuordnen

Wie bereits besprochen, sind Dateiebene-Notizen außerhalb des Umfangs von PEP 639, und die bestehende SPDX-License-Identifier Konvention kann bereits verwendet werden, wenn dies ohne weitere Spezifikation hier benötigt wird.

Kompatibilität mit einer bestimmten SPDX-Version nicht einfrieren

PEP 639 könnte die Angabe einer spezifischen SPDX-Spezifikationsversion oder einer für die Liste gültiger Lizenz-Identifikatoren weglassen, was flexiblere Updates ermöglichen würde, wenn sich die Spezifikation weiterentwickelt.

Es gab jedoch ernsthafte Bedenken hinsichtlich einer zukünftigen SPDX-Aktualisierung, die die Kompatibilität mit bestehenden Ausdrücken und Identifikatoren brechen und aktuelle Pakete mit ungültigen Metadaten gemäß der Definition in PEP 639 hinterlassen würde. Die Anforderung der Kompatibilität mit einer bestimmten Version dieser Spezifikationen hier und einer PEP oder einem ähnlichen Prozess, sie zu aktualisieren, vermeidet diese Eventualität und folgt der Praxis anderer Verpackungs-Ökosysteme.

Daher wurde entschieden, eine Mindestversion anzugeben und von Werkzeugen zu verlangen, mit ihr kompatibel zu sein, während Updates weiterhin zulässig sind, solange sie die Rückwärtskompatibilität nicht brechen. Dies ermöglicht es Werkzeugen, Verbesserungen sofort zu nutzen und neue Lizenzen zu akzeptieren, wobei Flexibilität und Kompatibilität abgewogen werden.

Keine benutzerdefinierten Lizenz-Identifikatoren zulassen

Ein früherer Entwurf dieses PEP sah die Möglichkeit vor, nur zwei benutzerdefinierte Kennungen zu verwenden: LicenseRef-Public-Domain und LicenseRef-Proprietary, um Fälle zu behandeln, in denen Projekte eine Lizenz haben, für die jedoch keine anerkannte SPDX-Lizenzkennung existiert. Die benutzerdefinierten Kennungen können nicht auf Korrektheit geprüft werden, und Benutzer könnten denken, dass sie Kennungen immer mit LicenseRef präfixen müssen. Dies würde dazu führen, dass Tools ungültige Metadaten erzeugen.

Python-Pakete werden jedoch in vielen offenen und geschlossenen Umgebungen erstellt, in denen es möglicherweise unmöglich ist, die Lizenz nur mit der kleinen Teilmenge der zulässigen benutzerdefinierten Kennungen anzugeben, und in denen es aus verschiedenen Gründen nicht möglich ist, die Lizenz zur SPDX-Lizenzliste hinzuzufügen.

Die benutzerdefinierten Lizenzkennungen sind in der offiziellen SPDX-Spezifikation ausdrücklich zulässig und beschrieben, und sie können syntaktisch validiert werden, wenn auch nicht case-normalisiert.

Daher wurde unter Anerkennung der Tatsache, dass die benutzerdefinierten Kennungen nicht vollständig validiert werden können und Fehler enthalten können, beschlossen, sie im Einklang mit der offiziellen SPDX-Spezifikation zuzulassen.

Unterschiedliche Lizenzen für Quell- und Binärdistributionen

Als zusätzlicher Anwendungsfall wurde gefragt, ob PEP 639 Fälle behandeln soll, in denen sich der Lizenz-Ausdruck für eine Binärdistribution (Wheel) von dem für eine Quellcode-Distribution (sdist) unterscheidet, wie z. B. bei Nicht-Pure-Python-Paketen, die Binärdateien unter anderen Lizenzen als das Projekt selbst kompilieren und bündeln. Als Beispiel wurde PyTorch angeführt, das CUDA von Nvidia enthält, welches frei verteilbar, aber nicht Open Source ist.

Angesichts der inhärenten Komplexität, eines fehlenden offensichtlichen Mechanismus zur Umsetzung, der Tatsache, dass jedes Wheel eigene Lizenzinformationen benötigen würde, des Mangels an Unterstützung auf PyPI für die Offenlegung von Lizenzinformationen pro Distributionsarchiv und des relativ Nischen-Anwendungsfalls wurde dies als außerhalb des Geltungsbereichs von PEP 639 erachtet und einer zukünftigen PEP zur Lösung überlassen, falls ausreichender Bedarf und Interesse besteht und ein geeigneter Mechanismus gefunden werden kann.