GitHubs Lizenz-Compliance für Open Source ist allgemein verfügbar

GitHub hat die Lizenz-Compliance für Open Source am 16. Oktober 2026 allgemein verfügbar gemacht, für Repositories in GitHub Enterprise Cloud, in denen GitHub Code Security eingeschaltet ist. Die Funktion prüft die Lizenz jeder Abhängigkeit, die ein Pull Request hinzufügt, und kann den Merge blockieren, wenn diese Lizenz gegen die Firmenrichtlinie verstößt. Das ist wichtig, weil die Lizenzprüfung meist spät und von Hand erfolgt, wenn der Code schon geschrieben ist.

Was die Lizenz-Compliance leistet

Jedes Open-Source-Paket hat eine Lizenz, also die rechtlichen Bedingungen für seine Nutzung. Manche Lizenzen, etwa MIT oder Apache 2.0, verlangen wenig von den Nutzern. Andere stellen Bedingungen, die die Juristen eines Unternehmens womöglich nicht akzeptieren. "Fast jede Software unterliegt irgendeiner Art von Lizenzvereinbarung", schrieben die GitHub-Produktmanager Jeff Luszcz und Eric Sorenson, wie Help Net Security zitiert.

Laut GitHubs Changelog erweitert die Funktion die Dependency Review Action um eine einheitliche Lizenzrichtlinie für das ganze Enterprise. Ein Enterprise ist GitHubs oberste Kontoebene, die viele Organisationen umfasst. Die Prüfungen laufen automatisch bei jedem Pull Request, der eine Abhängigkeit hinzufügt oder ändert. Jede Abhängigkeit, deren Lizenz nicht erlaubt ist, bekommt eine Annotation, also einen Hinweis, der am Pull Request hängt.

Laut Changelog hat ein Entwickler dann drei Auswege. Er kann das Paket entfernen oder ersetzen, die Lizenzrichtlinie ändern oder eine Ausnahme für genau dieses Paket beantragen.

Was sich seit der Vorschau im Juni geändert hat

GitHub hat die Funktion am 30. Juni 2026 als öffentliche Vorschau gestartet. Laut Changelog bringt die allgemeine Verfügbarkeit vier Neuerungen.

Neu bei allgemeiner Verfügbarkeit	Was es leistet
Unterstützung für Data Residency	Lizenzdaten füllen jetzt den Abhängigkeitsgraphen und SBOM-Exporte für Enterprise Cloud mit Data Residency
Audit-Log-Ereignisse	Änderungen an der Lizenzrichtlinie werden protokolliert, sodass externe Systeme sie verfolgen können
REST-API für die Richtlinie	Neue Endpunkte laden die Lizenzrichtlinie des Enterprise herunter, aktualisieren und ersetzen sie
Endpunkt zur Paketprüfung	Sagt einem Werkzeug, ob Pakete konform sind, damit Coding-Agenten nicht konforme Pakete meiden können

Eine SBOM (Software Bill of Materials, also eine Software-Stückliste) ist eine Liste aller Komponenten in einer Software. Die letzte Zeile ist für KI-Coding-Werkzeuge am wichtigsten. Ein Agent kann GitHub jetzt fragen, ob ein Paket erlaubt ist, bevor er es hinzufügt.

Wie die Durchsetzung funktioniert

Die Richtlinie listet die erlaubten Lizenzen auf. Laut GitHubs Dokumentation wählen Admins aus einer eingebauten Liste oder ergänzen weitere über den SPDX-Bezeichner, das standardisierte Kürzel für eine Lizenz. Die Prüfung erfasst auch transitive Abhängigkeiten, also die Pakete, die Ihre Pakete selbst nachladen.

Rulesets wenden die Richtlinie auf Ebene des Enterprise, der Organisation oder des Repositorys an. Ein Ruleset ist GitHubs Weg, Regeln für viele Repositories auf einmal festzulegen. Die Dokumentation beschreibt zwei Modi:

• Active: Ein Ruleset mit der Bedingung "Requires license compliance results before merging" blockiert den Merge, bis das Problem behoben ist.
• Evaluate: Dieselbe Prüfung läuft und annotiert den Pull Request, blockiert ihn aber nicht.

Anträge auf Ausnahmen gehen an eine neue vordefinierte Enterprise-Rolle. Der Changelog nennt sie Enterprise Open-Source License Manager. Diese Prüfer bekommen Benachrichtigungen per E-Mail und genehmigen Anträge in der Enterprise-Konsole.

GitHubs Dokumentation empfiehlt eine breite zentrale Richtlinie plus Ausnahmen pro Repository. Teams können eine benutzerdefinierte Repository-Eigenschaft mit den Werten inactive, evaluate und active anlegen. Rulesets zielen dann auf diese Werte, um die Durchsetzung Repository für Repository festzulegen.

Wie GitHub es intern nutzt

GitHubs eigenes Open Source Program Office nutzt das Werkzeug, berichtete Help Net Security im Juli. Dieses Büro war etwa zwei Monate vor dem Artikel von internen Werkzeugen umgestiegen. Es ließ Repositories etwa einen Monat lang im Modus Evaluate laufen, bevor es die Durchsetzung einschaltete. Die meisten Lizenzanträge wurden "innerhalb weniger Stunden" geprüft, hieß es im Bericht. Die anfängliche Allowlist umfasste MIT, Apache 2.0 und BSD-3-Clause.

Derselbe Bericht erwähnt ein Sicherheitsventil. Ein Team kann ein Repository für eine kritische Korrektur von Active zurück auf Evaluate stellen und es danach wieder umschalten.

GitHub hat die Kontrollen rund um den Pull Request in diesem Monat verschärft. Am 15. Oktober machte es AI Scan für Pull Requests allgemein verfügbar. Einen Tag später startete die öffentliche Vorschau von Workflow-Lockfiles für GitHub Actions.

Was das für Entwickler bedeutet

Wenn Ihr Unternehmen GitHub Enterprise Cloud mit Code Security nutzt, können Sie die Funktion heute einschalten. Keine der Quellen nennt einen separaten Preis. Prüfen Sie, was Ihr aktueller Code-Security-Vertrag abdeckt, bevor Sie eine Einführung planen.

Beginnen Sie im Modus Evaluate, wie es GitHubs eigenes Team getan hat. Ein Monat mit Annotationen zeigt, von welchen Lizenzen Ihre Codebasis schon abhängt, bevor irgendetwas einen Merge blockiert. Stellen Sie Repositories dann Gruppe für Gruppe mit der benutzerdefinierten Eigenschaft auf Active um.

Einigen Sie sich zuerst auf die Allowlist. MIT, Apache 2.0 und BSD-3-Clause sind ein üblicher Anfang. Legen Sie fest, wer die Rolle des License Managers übernimmt, denn ohne benannte Prüfer bleiben Anträge auf Ausnahmen liegen.

Wenn Sie interne Werkzeuge oder Coding-Agenten bauen, sehen Sie sich den neuen Endpunkt zur Paketprüfung an. Ein Agent, der ein Paket vor der Installation prüft, erspart später einen blockierten Pull Request.

Keine der Quellen nennt, welche Paket-Ökosysteme abgedeckt sind. Testen Sie ein Repository aus jeder Sprache, die Ihr Unternehmen nutzt, bevor Sie sich auf eine vollständige Abdeckung verlassen.