GitHub liest Lizenzdaten jetzt direkt aus den Paketregistern

Vom Community-Projekt zur Registerabfrage

GitHub hat einer der zentralen Datenquellen im eigenen Ökosystem eine neue Grundlage verschafft: Statt Lizenzinformationen aus Quellcode-Scans zu rekonstruieren, liest der Dependency Graph sie künftig direkt aus den Metadaten der Paketregister. Das betrifft praktisch jedes Repository, das npm, PyPI, crates.io oder eine der anderen sieben unterstützten Registries nutzt – also einen erheblichen Teil der Software-Lieferkette, die GitHub täglich analysiert.

Fast zwei Jahre lang war die Lizenzspalte im Dependency Graph eine Blackbox mit gutem Willen, aber wackliger Grundlage. Laut dem Changelog-Eintrag von GitHub vom 13. August 2026 kam die Lizenzinformation bislang primär aus dem Community-Projekt ClearlyDefined, das Quellcode-Dateien tief durchsucht, um Lizenztexte, Header und Copyright-Zeilen einzeln zu erkennen.

Das ist technisch beeindruckend, aber teuer: Depth-First-File-Scanning bedeutet, dass ein Tool jede Datei eines Pakets einzeln öffnet, Muster gegen bekannte Lizenztexte abgleicht und daraus eine Aussage ableitet. Bei einem npm-Paket mit tausend Dateien und diversen Bundlern, Testfixtures und Vendor-Ordnern produziert das schnell widersprüchliche Treffer. GitHub schreibt selbst, dass die Ergebnisse für Nutzer oft zu komplex und verwirrend wurden – ein ehrliches Eingeständnis, das man von einem Konzern dieser Größe nicht jeden Tag liest.

Wer selbst schon einmal versucht hat, aus einem automatisiert generierten SBOM eine einzelne verlässliche Lizenzzeile pro Paket herauszulesen, kennt das Gefühl: Drei verschiedene Tools, drei verschiedene Antworten, und am Ende landet die Entscheidung doch wieder beim Menschen, der die package.json manuell aufmacht. Genau dieses Muster wollte GitHub offenbar durchbrechen, indem es die Quelle der Wahrheit näher an den Publish-Vorgang selbst verschiebt.

Warum ClearlyDefined an seine Grenzen kam

Das eigentliche Problem war nie böser Wille, sondern ein Zielkonflikt. ClearlyDefined optimiert auf forensische Genauigkeit pro Datei, während Entwickler im Dependency Graph nur eine Antwort auf eine simple Frage wollen: Welche Lizenz gilt für dieses Paket, jetzt, in dieser Version? Wenn ein Scanner zehn unterschiedliche Lizenzhinweise in zehn Unterordnern findet, ist das fachlich korrekt und praktisch unbrauchbar.

GitHub bleibt ClearlyDefined nicht komplett fern – die Daten fließen weiterhin als Fallback ein, und GitHub trägt laut eigener Aussage auch weiter zum Projekt bei. Nur die Priorität hat sich gedreht: Was früher die Hauptquelle war, ist jetzt das Netz unter dem Trapez. Genau diese Art von Rückzug ohne Bruch ist selten in Produktankündigungen, aber technisch die vernünftigere Lösung, als ein bewährtes Fallback einfach zu kappen.

Für Maintainer, die ClearlyDefined-Daten für eigene Auswertungen nutzen, ändert sich vorerst nichts an der Verfügbarkeit; nur die Gewichtung innerhalb von GitHubs eigenem Stack verschiebt sich. Das ist ein feiner, aber wichtiger Unterschied, den man in der Ankündigung leicht überlesen kann, wenn man nur die Überschrift liest.

Neun Ökosysteme, neun kanonische Register

Was stattdessen an erster Stelle steht: die Registry selbst. Für jedes unterstützte Paket-Ökosystem fragt der Dependency-Graph-Dienst nun direkt beim kanonischen Register nach Metadaten, statt sie aus dem Quellcode zu rekonstruieren. Die Zuordnung ist keine Geheimwissenschaft, sondern eine feste Tabelle:

• npm → npmjs.org
• NuGet → nuget.org
• Python → pypi.org
• Rubygems → rubygems.org
• Rust → crates.io
• Go → pkg.go.dev
• Maven → deps.dev
• Dart → pub.dev
• PHP → packagist.org

Das klingt banal, ist aber ein handfester Architekturwechsel: Statt eine Lizenz aus verstreuten Textfragmenten zu erraten, liest GitHub die Angabe, die der Paket-Publisher selbst beim Veröffentlichen in die Registry-Metadaten geschrieben hat. Wer selbst schon einmal ein npm-Paket publiziert hat, weiß, dass das license-Feld in der package.json meist die erste ehrliche Quelle ist – nicht die zwanzigste Kopie einer MIT-Lizenzdatei irgendwo im Vendor-Verzeichnis.

Bemerkenswert ist auch, dass Maven hier über deps.dev abgefragt wird und nicht direkt über Maven Central – ein pragmatischer Umweg, weil deps.dev bereits normalisierte, maschinenlesbare Metadaten für das Java-Ökosystem bereithält. Wer selbst Erfahrung mit Maven-POMs hat, weiß, wie inkonsistent Lizenzangaben dort historisch gepflegt wurden; ein aggregierender Zwischenschritt ist da eher Vorteil als Umweg.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA developer hand traces one dependency thread from a sealed package capsule through a transparent registry prism into a carefully matched pair of blank legal puzzle pieces. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

SPDX-Ausdrücke brauchen saubere Zuordnung

Der eigentliche Hebel liegt in SPDX-Ausdrücken, also standardisierten Kurzformeln wie MIT, Apache-2.0 oder Kombinationen wie (MIT OR Apache-2.0). Registries verlangen diese Angaben inzwischen häufig direkt beim Publish-Vorgang, was sie zu einer strukturierten, maschinenlesbaren Quelle macht – im Gegensatz zu Freitext-Lizenzdateien, die jede Rechtsabteilung anders formuliert.

Der Haken: Nicht jedes Ökosystem erzwingt ein SPDX-Feld, und nicht jeder Maintainer trägt es korrekt ein. Ein leeres oder falsch geschriebenes Lizenzfeld bei PyPI oder crates.io bleibt ein leeres oder falsch geschriebenes Feld, egal wie kanonisch die Registry ist. GitHub tauscht damit eine Fehlerquelle gegen eine andere – vermutlich eine kleinere, aber SPDX-Zuordnung ist kein Selbstläufer, sondern nur so gut wie die Disziplin der Paket-Publisher.

Ein zusätzliches Detail, das in der Ankündigung nicht ausbuchstabiert wird, aber technisch naheliegt: Wenn ein Paket mehrere Lizenzausdrücke gleichzeitig deklariert, etwa Dual-Licensing-Modelle, muss der Parser entscheiden, welche Angabe im Dependency Graph als maßgeblich gilt. Genau an solchen Kanten – Dual-License, deprecated Felder, veraltete SPDX-Kürzel – zeigt sich, ob die neue Datenpipeline wirklich robuster ist oder nur häufiger falsch mit mehr Selbstvertrauen.

Versionsbereiche statt Fleißarbeit pro Release

Ein zweiter, unterschätzter Punkt der Umstellung: Der Dependency-Graph-Dienst führt Lizenzhistorie jetzt über Versionsbereiche statt über einen Datenbankeintrag pro einzelner Version. GitHub nennt als Beispiel Grafana, das von Apache auf AGPL relizenziert wurde und dafür zwei Einträge bekommt: Apache-2.0 für die Bereiche 1.0.0 bis 7.5.17 und AGPLv3 ab Version 8.0.0.

Praktisch bedeutet das: Statt für jede neue Patch-Version händisch einen Datenbankeintrag anzulegen, deckt ein Bereich automatisch alle künftigen Releases ab, solange sich an der Lizenz nichts ändert. Das reduziert nicht nur die Komplexität der internen Datenbank, sondern schließt auch eine typische Lücke – neue Versionen, die noch nicht explizit erfasst wurden, waren bisher schlicht ‚unbekannt‘. Wer selbst schon mal ein Lizenz-Datenbankschema gepflegt hat, kennt das Problem: Jede neue Version ist ein potenzieller blinder Fleck, wenn niemand sie händisch nachträgt.

Der Grafana-Fall ist auch deshalb ein gutes Lehrbeispiel, weil Relizenzierungen in der Praxis selten sind, aber wenn sie passieren, richtig teuer werden können, sofern ein Compliance-Tool die alte Lizenz für eine neue Version weiter annimmt. Ein Versionsbereich-Modell macht solche Übergänge explizit statt implizit – vorausgesetzt, jemand trägt den Bruchpunkt korrekt ein, sobald er bekannt wird.

Was das für SBOMs und Compliance-Tools bedeutet

Die neuen Daten sind kein isoliertes Feature, sondern fließen automatisch in mehrere GitHub-Werkzeuge: in die Dependency Insights, in generierte Software Bills of Materials, in die Open-Source-Lizenz-Compliance-Funktion von GitHub Advanced Security und in die Dependency-Review-Action, die Pull Requests gegen Lizenzregeln prüft. Wer Compliance-Gates in der CI-Pipeline auf diese Action stützt, bekommt die verbesserte Datenlage ohne eigenes Zutun.

Das ist relevant für Teams, die ohnehin schon mit Abhängigkeitsrisiken jonglieren – etwa nach einer Analyse zu einer dreitägigen Paket-Malware-Welle bei Dependabot, bei der es weniger um Lizenzen als um kompromittierte Pakete ging, aber um dieselbe Grundfrage: Wie vertrauenswürdig ist eigentlich das, was ich aus einer Registry ziehe? Genauere Lizenzdaten sind ein Baustein von vielen in dieser größeren Vertrauensfrage, kein Ersatz für Signaturprüfung oder Malware-Scanning.

Wer SBOMs für Kunden oder Auditoren exportiert, sollte den Zeitpunkt der Umstellung im eigenen Änderungsprotokoll vermerken: Ein SBOM, das vor dem 13. August 2026 gezogen wurde, kann für dasselbe Repository andere Lizenzangaben enthalten als eines von danach – nicht weil sich der Code geändert hat, sondern weil sich die Datenquelle geändert hat. Für Audits ist das ein Unterschied, der erklärt werden muss, bevor jemand anders ihn als Inkonsistenz missdeutet.

Wo die Datenqualität noch wackelt

Jetzt zur ehrlichen Bilanz, denn GitHub liefert selbst Zahlen dazu: Der Anteil fehlender Lizenzangaben im Dependency Graph sank laut eigenen frühen Ergebnissen von 45 Prozent auf 24 Prozent bei rund 170 Millionen erfassten Paketen. Das ist eine spürbare Verbesserung – und zugleich der Beweis, dass fast jedes vierte Paket weiterhin ohne verlässliche Lizenzangabe im Graphen steht. Wer daraus automatisierte Compliance-Entscheidungen ableitet, sollte diese Lücke im Hinterkopf behalten.

Die 24 Prozent sind außerdem ein Zwischenstand, kein Endzustand: GitHub selbst erwartet, dass die tatsächliche Abdeckung durch die Versionsbereich-Logik weiter steigt, ohne dass jede einzelne Version explizit ergänzt werden muss. Ob das in der Praxis so eintritt, lässt sich erst nach mehreren Release-Zyklen der wichtigsten Ökosysteme seriös nachprüfen – und genau das ist der Punkt, an dem eine Ankündigung optimistischer klingen kann als die spätere Realität.

Für Server- und Infrastrukturteams, die Lizenz- und Sicherheitsfragen sowieso gemeinsam denken, lohnt sich der Blick über den Tellerrand, etwa in unserem Vergleich von rootless Docker- und Podman-Hardening gegen kritische CVEs: Auch dort zeigt sich, dass eine einzelne Datenquelle – ob Registry-Metadaten oder CVE-Feed – nie die komplette Wahrheit liefert, sondern nur einen verlässlicheren Ausschnitt. Wer rechtlich heikle Abhängigkeiten hat, prüft die SPDX-Angabe der Registry stichprobenhaft gegen die tatsächliche Lizenzdatei im Repository, statt der automatisierten Zuordnung blind zu vertrauen.

Updierte Lizenzinformationen sind laut GitHub ab sofort im gesamten Produkt aktiv – kein gestaffelter Rollout, kein Opt-in. Ein guter Zeitpunkt also, um eigene SBOM-Exporte einmal neu zu ziehen und mit dem alten Stand zu vergleichen, statt sich auf einen Cache-Stand von vor der Umstellung zu verlassen.

Am Ende bleibt ein nüchterner Befund: Die Umstellung ist technisch sinnvoll, die Zahlen belegen echten Fortschritt, und die Architektur – Registry vor Dateiscan, Versionsbereiche statt Einzeleinträge – ist konsequenter gedacht als der alte Ansatz. Trotzdem ersetzt keine automatisierte Lizenzzuordnung eine eigene rechtliche Prüfung, sobald tatsächlich Geld oder Haftung im Spiel ist. Für die tägliche Entwicklungsarbeit ist die neue Datenbasis aber klar der bessere Ausgangspunkt als das, was vorher im Dependency Graph stand.