Lizenz-Compliance-Checkliste: Was Sie prüfen, bevor Sie Nachweis teilen

Eine überzeugende Seite identifiziert das ausgelieferte Produkt, listet Drittanbieter-Komponenten mit geprüften Lizenzen auf, enthält vollständigen Lizenztext oder zuverlässige Links, und zeigt Namensnennung, wo Lizenzen sie verlangen. Beschaffung und Auditoren erwarten mehr als eine Liste von npm-Paketen.

Wenn Ihre Seite nur sagt „wir nutzen Open Source“, ohne Bestand, Lizenztext oder klaren Geltungsbereich, erfüllt sie keine Anfrage nach Drittanbieter-Lizenz-Offenlegung. Das gilt selbst dann, wenn Engineering eine interne Sicherheitsprüfung bestanden hat.

Der Bedarf ist breit gestreut: Black Ducks Open Source Security and Risk Analysis 2025 fand, dass 97 % der geprüften Codebasen Open Source enthielten, sodass fast jedes Produkt Drittanbieter-Pflichten trägt, unabhängig davon, ob sie dokumentiert sind.

• Produktname und Version (oder Release-Kanal), die die Seite abdeckt.
• Bestand an Drittanbieter- und Open-Source-Komponenten, direkt und transitiv, wo Ihr Prozess es verlangt.
• Lizenzkennungen im SPDX-Stil oder gleichwertig, nach menschlicher Prüfung, nicht nur aus Registry-Vermutungen.
• Vollständiger Lizenztext für jede Komponente, oder stabile Links, die zum vollständigen Text führen.
• Namensnennungs- und Hinweisblöcke, wo MIT, Apache, BSD, GPL oder individuelle Lizenzen sie verlangen.
• Klare Kennzeichnung, falls die Seite Beispiel, Beta oder Produktion ist, wo relevant.

Lizenz-Compliance beginnt mit dem Bestand: Jede Komponente auf Ihrer Compliance-Seite sollte mit dem aktuell ausgelieferten Build übereinstimmen, nicht mit einem Dev-Branch, nicht mit Staging, nicht mit einer Produktlinie, die Sie noch nicht verkaufen.

Teams übersehen oft Schriftarten, Icon-Pakete, Analytics-SDKs, eingebettetes JavaScript auf Marketing-Websites und transitive Abhängigkeiten, die durch einen einzigen direkten Import mitgezogen werden. Compliance scheitert leise, wenn der Bestand unvollständig ist. Black Ducks OSSRA-Bericht 2025 zeigt, dass transitive Abhängigkeiten fast 30 % der gefundenen Lizenzkonflikte verursachten, sodass eine Checkliste, die bei direkten Imports aufhört, einen großen Teil des Risikos übersieht.

• Jede Komponente auf der Seite stimmt mit dem Build überein, den Kunden heute erhalten.
• Transitive npm-, pnpm-, yarn-, Go-, Rust-, Python-, Java-, .NET-, PHP- oder Ruby-Abhängigkeiten sind gemäß Ihrer Richtlinie enthalten.
• Schriftarten, Icons, Bilder mit Lizenzbedingungen und kommerzielle SDKs werden nicht übersprungen.
• Container-Basis-Layer und gebündelte native Bibliotheken sind im Geltungsbereich, wenn Sie sie verbreiten.
• Als unbekannt oder prüfungsbedürftig markierte Einträge werden geklärt oder mit dokumentiertem Grund ausdrücklich ausgeschlossen.
• Die Bestandsquelle (Lockfile, CycloneDX-SBOM, manueller Eintrag) ist bis zum Release rückverfolgbar.

Sie verlangt, dass Prüfer die tatsächliche Lizenz lesen können, keine Zusammenfassung: Drittanbieter-Lizenz-Offenlegung bedeutet vollständigen Lizenztext pro Komponente. Beschaffung und Recht vergleichen Ihre Seite mit den Pflichten in GPL, LGPL, Apache, MIT und proprietären SDK-Vereinbarungen.

Namensnennung ist getrennt vom Hinweis und getrennt vom vollständigen Lizenztext. Eine Seite, die „MIT“ auflistet, ohne den MIT-Lizenztext oder den erforderlichen Copyright-Hinweis, ist für die meisten Enterprise-Prüfungen unvollständig.

• Jede Komponente hat eine identifizierte Lizenz, geprüft von einem Menschen, nicht blind aus Paket-Metadaten kopiert.
• Vollständiger Lizenztext ist auf der Seite vorhanden oder verlinkt, ohne Login-Sperren oder ablaufende URLs.
• Copyleft-Komponenten (GPL, AGPL, LGPL usw.) haben Ihre internen Prüf-Gates durchlaufen.
• Die Namensnennungsformulierung entspricht dem, was jede Lizenz verlangt, nicht ein generischer „Open-Source-Lizenzen“-Footer.
• Bei doppellizenzierten oder individuellen Komponenten ist eine ausdrückliche Entscheidung dokumentiert.
• Keine Komponente wird als freigegeben veröffentlicht, bevor der Lizenztext beigefügt oder verlinkt ist.

Eine Lizenz-Compliance-Seite ist ein lebendiger Nachweis. Die URL, die die Beschaffung in ihrer Anbieterakte gespeichert hat, sollte auch nach Ihrem nächsten Release noch korrekt sein. Compliance bricht, wenn die Seite von dem abweicht, was ausgeliefert wird.

Publish-Gates (Prüfung vor Veröffentlichung) verhindern, dass Teams Compliance behaupten, die sie nicht verifiziert haben. Exporte (JSON, Namensnennungsdateien, Offenlegungspakete) sollten mit demselben geprüften Bestand übereinstimmen wie die öffentliche URL.

• Ein namentlich benannter Verantwortlicher hat die Veröffentlichung für dieses Produkt und Release freigegeben.
• Die URL der Compliance-Seite ist stabil, öffentlich und ohne Authentifizierung erreichbar.
• Exporte und Release-Pakete stimmen mit dem veröffentlichten Bestand überein.
• Drift-Prüfungen oder Pipeline-Checks markieren neue Pakete vor dem nächsten Kunden-Audit.
• Sie haben einen dokumentierten Prozess, um die Lizenzseite zu aktualisieren, wenn sich Abhängigkeiten ändern.
• Sie suggerieren keine rechtliche Freigabe, es sei denn, Ihr Rechtsbeistand hat geprüft. Die Seite ist ein operativer Nachweis.

Öffnen Sie die Lizenz-Compliance-Seite in einem Inkognito-Fenster. Bestätigen Sie, dass sie lädt, identifizieren Sie das Produkt, und prüfen Sie stichprobenartig fünf zufällige Komponenten gegen Ihren internen Bestand. Wenn die Beschaffung nach einem Nachweis fragt, ist genau das, was sie tun wird.

Wenn die Checkliste besteht, schicken Sie das angeforderte Format (URL, Export oder Anhang) aus demselben geprüften Veröffentlichungs-Snapshot. Nennen Sie das Produkt und das Release oder Datum, das es widerspiegelt. Der Dateityp zählt weniger als die Frage, ob der Bestand geprüft und freigegeben wurde, bevor Sie ihn verschickt haben.

Nein. Eine SBOM-Checkliste bestätigt die Komponentenidentität in einem maschinenlesbaren Format. Eine Lizenz-Compliance-Checkliste bestätigt geprüfte Lizenzen, Volltext, Attribution und einen Publish-Stand, den Sie teilen wollen. Oft brauchen Sie beides, in dieser Reihenfolge.

Vor jeder externen Freigabe, und erneut, wenn sich Abhängigkeiten auf einem beobachteten Release-Branch ändern. Drift zwischen dem letzten freigegebenen Publish und dem aktuellen Lockfile ist der typische Fehlerfall.

Benennen Sie einen verantwortlichen Owner pro Produkt, üblicherweise Engineering mit rechtlicher Prüfung bei Hochrisiko-Lizenzen. Geteilte Ownership ohne Publish-Gate führt dazu, dass veraltete URLs in Vendor-Dateien landen.