Was die Beschaffung tatsächlich verlangt

Weil Produkte nicht bei einer Version eingefroren sind: Engineers mergen Abhängigkeits-Updates, fügen SDKs hinzu, tauschen Schriftarten aus und aktualisieren transitive Pakete, oft ohne dass eine Person das vollständige Pflichtenbild verfolgt. Sie können aus einer vor Monaten erstellten Tabelle nicht zuverlässig sagen: „Das ist alles, was gerade in Produktion läuft.“

Ein PDF, eine ZIP-Datei oder ein SBOM-Anhang ist ein Snapshot. In dem Moment, in dem jemand ein Release mit neuen Paketen ausliefert, ist dieser Snapshot Geschichte. Nicht böswillig falsch, nur veraltet. Die Beschaffung legt ihn ab, geht von Aktualität aus, und entdeckt die Lücke Monate später bei einem Audit oder einer Vertragsverlängerung.

Die eigentliche Anforderung lautet nicht „schicken Sie eine URL statt eines PDFs“. Sie brauchen einen geprüften Bestand, gebunden an das, was Sie ausliefern, aktualisiert bei Abhängigkeitsänderungen, und nur geteilt, nachdem Publish-Gates bestanden wurden. Eine öffentliche Compliance-Seite ist eine Möglichkeit, diesen Nachweis zu hosten, sodass beide Seiten dieselbe Version sehen. Links sind keine Magie; der Nachweis dahinter soll aktualisiert werden.

Sie wollen Nachweise, dass Sie operative Kontrolle über Drittanbieter-Lizenzpflichten haben, nicht dass Sie einmal npm list auf einem Laptop ausgeführt haben. Unterschiedliche Fragebögen verwenden unterschiedliche Begriffe (Open-Source-Lizenzseite, Drittanbieter-Softwareliste, OSS-Offenlegung, Software-Stückliste plus Lizenztext), aber die Absicht ist ähnlich.

Eine Software-Stückliste allein erfüllt die Anfrage oft nicht. Die von der US-amerikanischen NTIA definierten Mindestelemente eines SBOM drehen sich um Komponentenidentität für Schwachstellen- und Bestandszwecke, nicht um geprüfte Lizenz-Offenlegung. Beschaffungs- und Rechtsprüfer wollen weiterhin vollständigen Lizenztext und eine Bestätigung, dass die Liste mit den Releases übereinstimmt.

• Geprüfter Bestand an Drittanbieter- und Open-Source-Komponenten für das geprüfte Produkt.
• Vollständiger Lizenztext oder zuverlässige Links, nicht SPDX-Kennungen ohne Text.
• Namensnennung und Hinweis, wo Lizenzen sie verlangen.
• Klarheit darüber, welches Produkt, Release oder Datum die Offenlegung widerspiegelt.
• Oft eine URL, ein Export oder Anhang, je nachdem, was ihr Prozess vorgibt.
• Zunehmend: wie Sie den Nachweis aktuell halten, wenn sich Abhängigkeiten ändern.

Schicken Sie nicht den Lizenz-Footer Ihrer Unternehmens-Marketing-Website, wenn der Käufer Ihr API-Produkt, Ihre mobile App oder Ihren On-Premises-Installer bewertet. Jedes ausgelieferte Produkt braucht möglicherweise seinen eigenen Offenlegungs-Nachweis oder einen klar abgegrenzten Abschnitt.

Fragen Sie, welche SKU, welchen Produktnamen, welche Version oder welches Release-Datum die Prüfung abdeckt. Lizenz-Compliance ist produktspezifisch. Die Dokumentation für das falsche Produkt zu schicken, verursacht mehr Nacharbeit als gar nichts zu schicken.

• Welches Produkt oder welche SKU wird geprüft?
• Welche Version, welches Release-Tag oder Datum soll die Offenlegung widerspiegeln?
• Wollen sie eine URL, eine Exportdatei oder beides?
• Gilt die Prüfung für SaaS, installierbare Software, eingebettete Systeme oder alle Auslieferungsmodelle?
• Wer ist die Zielgruppe: Beschaffung, Recht, Security, oder alle drei?

Bevor Sie antworten, bestätigen Sie, dass der Nachweis mit dem Build übereinstimmt, den Kunden erhalten. Nicht der main-Branch, nicht der lokale Rechner eines Entwicklers, nicht ein Bestand, den seit letztem Quartal niemand geprüft hat.

In einem mehrköpfigen Team verschieben sich Abhängigkeiten ohne zentrale Benachrichtigung. Ein Engineer aktualisiert eine Patch-Version, ein anderer fügt ein Analytics-SDK hinzu, ein transitives Paket ändert Lizenz-Metadaten in der Registry. Ohne Import, Prüfung und Publish-Gates weiß niemand, dass die Offenlegung veraltet ist, bis ein Käufer nachfragt.

Vergleichen Sie Ihre Offenlegung mit dem Lockfile, SBOM oder Export aus dem geprüften Release. Prüfen Sie stichprobenartig Copyleft-Komponenten, kommerzielle SDKs und alles, was als prüfungsbedürftig markiert ist. Wenn Sie nicht jede Zeile verifizieren können, schließen Sie die Lücke oder seien Sie ehrlich zum Zeitplan.

• Aus dem Release-Branch oder CI-Artefakt importieren, nicht aus einer veralteten manuellen Liste.
• Bestätigen, dass jede relevante Komponente freigegebenen Lizenztext hat.
• Ungeprüfte Zeilen klären, bevor Sie den Nachweis extern vertreten.
• Prüfen, ob der Produktname in der Offenlegung mit dem übereinstimmt, was der Käufer erwirbt.
• Das Release-Tag oder Datum notieren, das der Bestand widerspiegelt, und dies in Ihrer Antwort angeben.

Schicken Sie das Angeforderte (URL, PDF-Export, JSON-Paket) aus demselben freigegebenen Veröffentlichungs-Snapshot. Geben Sie an, welches Produkt und Release es abdeckt. Beschreiben Sie kurz, wie Sie den Nachweis aktualisieren, wenn sich Abhängigkeiten ändern: erneuter Import, erneute Prüfung, erneute Veröffentlichung.

Suggerieren Sie keine rechtliche Freigabe, es sei denn, Ihr Rechtsbeistand hat sie erteilt. Sagen Sie nicht „das ist für immer alles in unserem Stack“. Sagen Sie, was geprüft wurde, für welches Produkt, zu welchem Release, und dass Sie den Nachweis pflegen, während sich die Codebasis ändert.

Wenn der Nachweis noch nicht bereit ist, nennen Sie ein realistisches Datum. Die Beschaffung bevorzugt Ehrlichkeit gegenüber einem Snapshot, der bei der Prüfung durchfällt, weil seit seiner Erstellung jemand fünf Abhängigkeits-Updates gemerged hat.

• Beginnen Sie mit dem Produktnamen und „Drittanbieter-Lizenz-Offenlegung“ oder „Open-Source-Lizenz-Compliance“.
• Geben Sie das Release, Tag oder Datum an, das der Bestand widerspiegelt.
• Stellen Sie die angeforderte URL oder den Anhang bereit, aus denselben geprüften Daten.
• Ein Satz zur Pflege: wie Sie erneut veröffentlichen, wenn sich Abhängigkeiten ändern.
• Bieten Sie Exporte an, falls der Fragebogen sie verlangt, erzeugt aus demselben Snapshot.

Eine Liste einmal exportieren und über mehrere Releases hinweg wiederverwenden. Annehmen, dass seit der letzten Ausschreibung niemand Pakete hinzugefügt hat. Ein rohes SBOM ohne geprüften Lizenztext schicken. Ein Trust-Center-PDF zur Sicherheit schicken, das nie Drittanbieter-Lizenzen auflistet.

Behaupten, SOC 2 oder ISO 27001 decke Open-Source-Lizenzpflichten ab (meist tut es das nicht). „Wir nutzen Open Source“ als Offenlegung behandeln. Jedes davon scheitert, wenn der Käufer Ihre Antwort mit dem vergleicht, was tatsächlich ausgeliefert wird, oder was zwei Sprints nach Ihrer Antwort ausgeliefert wurde.

Die Lösung ist operativ: Bestand aus Build-Inputs, menschliche Prüfung vor externer Weitergabe, Aktualisierung bei Abhängigkeitsänderungen. Kein besseres Dateiformat.