Wie Sie einen Drittanbieter-Bestand vor der Veröffentlichung prüfen

Weil der Import nur zeigt, was da ist, nicht ob die Lizenz-Metadaten vertrauenswürdig sind: Paket-Registries beschriften Lizenzen falsch, Anbieter ändern Bedingungen, und transitive Abhängigkeiten bringen unerwartetes Copyleft mit. Eine Drittanbieter-Bestandsdatei ist ein Input, keine fertige Compliance-Seite.

Das Ausmaß ist dokumentiert, und es sind genau die Fälle, die ein automatisierter Import allein nicht lösen kann.

Prüf-Gates existieren, damit Sie keine Lizenz-Compliance-URL veröffentlichen können, die mehr behauptet, als Ihr Team verifiziert hat. Beschaffung und Auditoren behandeln die öffentliche Seite als Ihre Erklärung zu Drittanbieter-Lizenzpflichten.

Beginnen Sie mit Artefakten, die an den ausgelieferten Build gebunden sind: package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, ein CycloneDX-SBOM aus der CI, oder Exporte aus Ihrem bestehenden SBOM-Tool. Markieren Sie jede Zeile als prüfungsbedürftig, bis jemand die Lizenz bestätigt.

Grenzen Sie den Import auf ein Produkt ein. Unternehmen mit mehreren Produkten brauchen separate Lizenz-Compliance-Seiten oder klar getrennte Abschnitte pro ausgeliefertem Produkt. Das Vermischen von Beständen erzeugt Offenlegungsfehler.

• Lockfiles oder SBOMs aus dem Release-Branch importieren, nicht aus main, falls dieser abweicht.
• Schriftarten, Icons, SDKs und eingebettete Assets einbeziehen, die Ihre Richtlinie verlangt.
• Duplikate markieren und Einträge zusammenführen, die dieselbe Komponente betreffen.
• Import-Datum und Hash der Quelldatei für den Audit-Trail erfassen.
• Nicht automatisch veröffentlichen. Jeder Eintrag beginnt ungeprüft.

Bestätigen Sie für jede Zeile, dass die Lizenzkennung der tatsächlichen Nutzung entspricht, nicht nur den package.json-Metadaten. Lesen Sie die Copyleft-Auslöser. Fügen Sie vollständigen Lizenztext bei. Dokumentieren Sie Ausschlüsse ausdrücklich.

Prüfer konzentrieren sich auf GPL, LGPL, AGPL, proprietäre SDKs und Komponenten mit fehlenden oder widersprüchlichen Lizenzdaten. Diese Zeilen sperren die Veröffentlichung, bis sie geklärt sind.

• Lizenz mit der Quelle abgleichen: LICENSE-Datei im Repository, Anbietervereinbarung oder von einem Menschen bestätigte SPDX-Kennung.
• Vollständigen Lizenztext zum Nachweis hinzufügen, bevor als freigegeben markiert wird.
• Copyleft, Network-Copyleft (AGPL) und individuelle Lizenzen für die Prüfung durch Recht oder erfahrene Engineers markieren.
• Konflikte klären (Registry sagt MIT, Repository sagt Apache), bevor freigegeben wird.
• Vom ausgelieferten Produkt ausgeschlossene Komponenten und den Grund dokumentieren.
• Einen zweiten Freigebenden für risikoreiche Lizenzen verlangen, falls Ihre Richtlinie das vorsieht.

Veröffentlichen Sie erst, wenn die Gates bestanden sind: keine ungeprüften Zeilen, vollständiger Lizenztext beigefügt, klarer Produktumfang, stabile URL. Die öffentliche Lizenz-Compliance-Seite enthält dieselben Daten wie Ihre Exporte. Ein geprüfter Bestand, mehrere Ausgaben.

Drittanbieter-Lizenz-Offenlegungsseiten sollten ohne Authentifizierung laden, Komponenten klar auflisten und vollständigen Lizenztext enthalten, den die Beschaffung durchsuchen und kopieren kann. Genau danach suchen Enterprise-Prüfungen.

• Veröffentlichung sperren, wenn einer relevanten Komponente der freigegebene Lizenztext fehlt.
• Öffentliche URL erzeugen und im Inkognito-Modus verifizieren, bevor extern geteilt wird.
• JSON-, Namensnennungs- und Offenlegungspakete aus demselben freigegebenen Snapshot exportieren.
• Erfassen, wer die Veröffentlichung freigegeben hat und mit welchem Release-Tag sie übereinstimmt.

Lizenz-Compliance ist keine einmalige Sache. Neue Abhängigkeiten, Versions-Updates und Lizenzänderungen kommen mit jedem Sprint. Drift-Prüfungen vergleichen aktuelle Lockfiles oder SBOMs mit Ihrer letzten freigegebenen Veröffentlichung und markieren Unterschiede, bevor Kunden es bemerken.

Wenn sich der Bestand ändert, durchlaufen Sie die Prüf-Gates erneut. Aktualisieren Sie die Lizenz-Compliance-Seite. Schicken Sie aktualisierte URLs erst an die Beschaffung, wenn die neue Veröffentlichung freigegeben ist, nicht wenn der Import abgeschlossen ist.

• Pipeline- oder CI-Prüfungen bei Pull Request, Tag oder Release ausführen.
• Neue, ungeprüfte Pakete gemäß Ihrer Richtlinie vor dem Release markieren.
• Copyleft-Komponenten erneut freigeben, wenn sich Linking oder Verbreitungsmodell ändern.
• Audit-Trail führen: Import-, Prüf-, Veröffentlichungs- und Drift-Ereignisse.