Nach einer im Juni 2026 gestarteten öffentlichen Vorschau hat GitHub am 16. Oktober die allgemeine Verfügbarkeit der Open-Source-Lizenzkonformität angekündigt, vorbehalten GitHub-Enterprise-Cloud-Kunden mit GitHub Code Security. Die Funktion erlaubt es, eine Lizenzrichtlinie unternehmensweit festzulegen und sie automatisch auf jeden Pull Request anzuwenden, der eine Abhängigkeit hinzufügt oder ändert.
Das Prinzip: eine Lizenzrichtlinie, durchgesetzt beim Merge
Eine Lizenzrichtlinie legt fest, welche Open-Source-Lizenzen erlaubt sind, welche verboten sind und welche eine Einzelfallprüfung erfordern. Sobald ein Pull Request eine nicht konforme Abhängigkeit einführt, fügt GitHub eine Anmerkung hinzu. Am Prinzip ist nichts neu, doch die allgemeine Verfügbarkeit eröffnet die Möglichkeit, aus dieser Prüfung eine blockierende zu machen.
Eine neue Bedingung innerhalb von Rulesets
Die Richtlinie wird über ein Repository-Ruleset durchgesetzt, nach demselben Muster wie die bereits bestehenden Code-Scanning-Bedingungen. Eine Organisation kann nun verlangen, dass die Lizenzkonformitätsprüfung vor jedem Merge besteht, gleichrangig mit einer Code-Review oder einer grünen Testsuite.
| Vorher (Vorschau, Juni 2026) | Nachher (allgemeine Verfügbarkeit, Oktober 2026) |
|---|---|
| Keine Lizenzdaten für Data-Residency-Kunden | Daten verfügbar, eingespeist in Dependency Graph und SBOM-Exporte |
| Keine eigene Ruleset-Bedingung | Bedingung „Require license compliance results before merging“ |
| Keine eigene Governance-Rolle | Vordefinierte Rolle „Enterprise Open-Source License Manager“ |
| Richtlinienänderungen nicht nachverfolgt | Jede Richtlinienänderung erzeugt ein Audit-Log-Ereignis |
| Keine API zur Richtlinienverwaltung | REST-Endpunkte zum Lesen, Ändern und Prüfen der Konformität eines Pakets |
Eine Anmerkung auflösen: drei mögliche Wege
Wird eine Abhängigkeit als nicht konform markiert, hat ein Team drei Optionen: die Abhängigkeit entfernen oder ersetzen, die Lizenzrichtlinie von der berechtigten Person ändern lassen, oder eine gezielte Ausnahme für genau dieses Paket anlegen. Die neue Rolle „Enterprise Open-Source License Manager“ bündelt genau die Prüfung solcher Ausnahmeanträge, mit E-Mail-Benachrichtigung und Bearbeitung über die Enterprise-Konsole – ein Ablauf, der sich zu den Kommandozeilenwerkzeugen gesellt, die Teams bereits zur Prüfung ihrer Abhängigkeiten nutzen.
# Konformität eines Pakets über die Dependency-Graph-REST-API prüfen
gh api \
-H "Accept: application/vnd.github+json" \
/enterprises/ORG/dependency-graph/license-policy/check \
-f ecosystem=npm \
-f name=some-package \
-f version=2.4.1Die Lizenzrichtlinie verhält sich jetzt wie jede andere Ruleset-Bedingung: Sie kann das Mergen eines Pull Requests verhindern, gleichrangig mit einer Code-Scanning-Prüfung oder einer vorgeschriebenen Review.
GitHub hebt zudem einen Anwendungsfall jenseits menschlicher Governance hervor: Die neuen API-Endpunkte erlauben es automatisierten Coding-Agenten, die Konformität eines Pakets zu prüfen, bevor es einem Projekt hinzugefügt wird. Eine Organisation, die ihre Deployment-Pipeline bereits um automatisierte Regeln herum aufgebaut hat, etwa über ein standardisiertes Self-Hosting-Setup, gewinnt hier einen weiteren Hebel, um Sicherheit, Konformität und Liefergeschwindigkeit zusammenzuführen.
Was sich für Teams mit vielen Abhängigkeiten ändert
Für eine Organisation mit Dutzenden Repositories liegt der Unterschied zur Vorschau vor allem im Governance-Tooling: Audit-Log, eigene Rolle, API für Agenten. Dieser Aufwand für Nachverfolgung im großen Maßstab erklärt, warum die Funktion auf dem Enterprise-Cloud-Angebot verbleibt statt auf einzelnen Repositories.
Was man sich merken sollte
Open-Source-Lizenzkonformität wird bei GitHub zu einer vollwertigen Merge-Hürde, gleichrangig mit Code Scanning. Der wesentliche Gewinn der allgemeinen Verfügbarkeit liegt im Governance-Tooling: eigene Rolle, Audit-Log, eine von Agenten nutzbare API. Die Funktion bleibt aber auf GitHub Enterprise Cloud beschränkt und lässt einzelne Repositories und kleine Teams ohne natives Äquivalent zurück.
Das ist eine jener Funktionen, die unterhalb einer bestimmten Größe kaum eine Rolle spielen und darüber unverzichtbar werden. Bei Projekten, in denen ich eine Lizenzprüfung erst im Nachhinein erlebt habe, meist ausgelöst durch ein Kundenaudit oder eine Übernahme, zeigt sich immer dasselbe Muster: Niemand weiß mehr genau, welche Lizenzen im Lockfile stecken, und die nachträgliche Korrektur kostet weit mehr, als den Merge im richtigen Moment blockiert zu haben. Die Öffnung der API für Coding-Agenten ist das interessanteste Signal hier: Konformität wird bald kein menschlicher Review-Schritt mehr sein, sondern eine Bedingung, die geprüft wird, bevor der Code überhaupt vorgeschlagen wird. — Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung im GitHub Changelog.
