GitHub prüft Open-Source-Lizenzen vor dem Merge: Was die neue Compliance-Funktion bringt

Neue GitHub-Funktion: Lizenzen werden Teil des Merge-Prozesses

Open-Source-Bibliotheken stecken in fast jeder modernen Website, App und Unternehmenssoftware. Ihre Nutzung spart Entwicklungszeit, bringt aber auch Verpflichtungen mit sich: Manche Lizenzen verlangen Hinweise und die Beibehaltung von Copyright-Vermerken, andere können bei bestimmten Formen der Weitergabe zusätzliche Pflichten auslösen. Wer Abhängigkeiten nur auf Sicherheitslücken prüft, übersieht daher einen zweiten wichtigen Teil des Software-Risikos.

Am 16. Oktober 2026 hat GitHub die allgemeine Verfügbarkeit seiner Open Source License Compliance angekündigt. Die Funktion erlaubt Unternehmen, Lizenzrichtlinien zentral festzulegen und bei Änderungen an Abhängigkeiten direkt in Pull Requests zu prüfen. Das Ziel ist nicht, Open Source einzuschränken, sondern frühzeitig sichtbar zu machen, ob ein neues Paket zur vorgesehenen Verwendung und zur internen Richtlinie passt.

Was GitHub am 16. Oktober tatsächlich freigegeben hat

Die Neuerung ist kein universeller Lizenzscanner für jedes kostenlose GitHub-Konto. Laut GitHub steht die zentrale Lizenz-Compliance für GitHub Enterprise Cloud einschließlich der Variante mit Datenresidenz zur Verfügung. Damit ein Repository die Richtlinie durchsetzen kann, muss dort GitHub Code Security aktiviert sein. Diese Voraussetzung ist für Budgetplanung und technische Einführung entscheidend.

GitHub baut auf dem vorhandenen Dependency Graph und dem Prinzip der Dependency Review auf. Eine Unternehmensrichtlinie definiert zulässige Lizenzen; sogenannte Rulesets entscheiden, welche Repositories und Branches geprüft werden. Ändert ein Pull Request Paketmanifeste, werden neu hinzugekommene oder veränderte Abhängigkeiten anhand dieser Regeln bewertet. Verstöße erscheinen als Hinweise im Pull Request und können das Zusammenführen verhindern.

Warum transitive Abhängigkeiten die eigentliche Herausforderung sind

Ein Team fügt vielleicht nur eine einzige Bibliothek hinzu, bekommt darüber aber mehrere Dutzend weitere Pakete ins Projekt. Diese indirekten, transitiven Abhängigkeiten sind im Alltag leicht zu übersehen. GitHub erklärt ausdrücklich, dass seine Lizenzbewertung auch entsprechende Daten aus dem Dependency Graph berücksichtigt. Damit wird der Blick breiter als die bloße Liste direkt installierter Komponenten.

Das bedeutet allerdings nicht, dass jedes denkbare Lizenzproblem automatisch erkannt wird. Die Qualität der Ergebnisse hängt davon ab, welche Abhängigkeiten und Lizenzinformationen der Dependency Graph erfassen kann. Eigenständig eingebundene Dateien, Sondervereinbarungen oder ungewöhnliche Vertriebsmodelle können zusätzliche Prüfung erfordern. Eine automatisierte Kontrolle ist deshalb ein früher Filter, kein Ersatz für eine vollständige rechtliche Bewertung.

Evaluate oder Active: So unterscheiden sich die Prüfmodi

Für die Einführung sind zwei Modi besonders wichtig. Im Evaluate-Modus laufen die Prüfungen zunächst beobachtend: Das Team erhält Hinweise, ohne dass die Lizenzbedingung selbst einen Merge blockiert. So lässt sich feststellen, welche Pakete betroffen wären, ob Metadaten fehlen und wie viele Ausnahmen realistisch nötig sind. Das ist für gewachsene Anwendungen häufig der sinnvollere Einstieg.

Im Active-Modus wird aus der Kontrolle eine verbindliche Merge-Bedingung. Führt ein Pull Request eine Abhängigkeit ein, die gegen die Richtlinie verstößt, bleibt er blockiert, bis das Problem gelöst ist. Zu beachten ist eine Feinheit der GitHub-Dokumentation: Eine separate Branch-Protection-Regel zur Auflösung von Kommentaren kann auch Hinweise aus Evaluate-Prüfungen relevant für den Merge machen. Die Gesamtkonfiguration muss daher getestet werden.

Welche Lizenzen dürfen hinein? Die Richtlinie ist keine Schwarz-Weiß-Liste

Eine Unternehmensrichtlinie lässt sich aus vorgegebenen Lizenzen zusammenstellen oder über SPDX-Kennungen definieren. SPDX bietet standardisierte Bezeichnungen wie MIT, Apache-2.0 oder GPL-3.0-only und unterstützt auch komplexere Ausdrücke. Diese Kennungen erleichtern maschinelle Vergleiche. Sie beantworten aber nicht automatisch, ob eine Lizenz im konkreten Geschäftsmodell zulässig oder sinnvoll ist.

Beispielsweise können die Anforderungen bei einer intern betriebenen Anwendung anders ausfallen als bei Software, die an Kunden verteilt wird. Auch die Art der Einbindung und mögliche Ausnahmen spielen eine Rolle. GitHub weist selbst darauf hin, dass die angezeigten allgemeinen Risikokategorien keine Rechtsberatung darstellen. Die fachliche Freigabe sollte deshalb mit zuständigen Lizenz- oder Rechtsexperten abgestimmt werden.

Ausnahmen kontrollieren statt Prüfungen abschalten

Nicht jede Abweichung muss bedeuten, dass ein Paket grundsätzlich verboten ist. Ein Entwickler kann die betroffene Bibliothek ersetzen, eine Anpassung der Richtlinie anregen oder eine begründete Ausnahme beantragen. GitHub sieht dafür einen definierten Freigabeprozess vor. So muss das Team nicht zwischen unkontrollierter Nutzung und einem pauschalen Verbot entscheiden.

Neu ist dafür die Unternehmensrolle Enterprise Open-Source License Manager. Berechtigte Personen können Anträge prüfen und freigeben; ausstehende Anfragen erscheinen in den entsprechenden Unternehmensansichten, zusätzlich sind Benachrichtigungen vorgesehen. Ausnahmen lassen sich je nach Entscheidung auf passende Bereiche begrenzen. Entscheidend ist eine nachvollziehbare Begründung: Ein Freigabeprozess verliert seinen Wert, wenn jede Warnung ohne Prüfung bestätigt wird.

Was sich seit der Preview im Juni verbessert hat

Die allgemeine Verfügbarkeit folgt auf eine öffentliche Vorschau im Juni 2026. Laut Ankündigung vom 16. Oktober wurden seither mehrere Funktionen ergänzt. So erhalten nun auch GitHub-Enterprise-Cloud-Kunden mit Datenresidenz Lizenzinformationen, die sowohl für Compliance-Prüfungen als auch für Dependency Graph und SBOM-Exporte genutzt werden können. Eine Software Bill of Materials dokumentiert dabei die bekannten Bestandteile einer Anwendung.

Außerdem protokolliert GitHub Änderungen an Lizenzrichtlinien im Audit Log. Neue API-Endpunkte erlauben es, Richtlinien herunterzuladen, zu aktualisieren oder zu ersetzen und Pakete gegen eine bestehende Policy zu prüfen. Gerade für größere Organisationen ist das relevant: Eine Richtlinie kann versioniert, kontrolliert ausgerollt und bei Bedarf in bestehende Governance- und Berichtssysteme eingebunden werden.

Auch KI-Coding-Agenten müssen die Lizenzregeln kennen

Ein besonders aktueller Aspekt betrifft KI-gestützte Entwicklung. Coding-Agenten können Bibliotheken vorschlagen oder direkt in Projekte aufnehmen, ohne dass dabei zwangsläufig jede Lizenzbedingung bewusst berücksichtigt wird. GitHub verweist auf einen API-Endpunkt, mit dem sich Pakete vorab gegen die Richtlinie eines Repositories prüfen lassen. Dadurch kann ein Agent schon bei der Auswahl erkennen, ob eine Abhängigkeit problematisch wäre.

Das ist eine Möglichkeit, keine automatische Garantie. Die Integration muss tatsächlich in den jeweiligen Agenten-Workflow eingebaut werden, und die Ergebnisse müssen berücksichtigt werden. Für Teams bietet sich eine klare Regel an: Neue Abhängigkeiten, gleich ob von Menschen oder KI vorgeschlagen, durchlaufen dieselben Prüfungen. Verantwortung für Architektur, Sicherheit und rechtliche Freigaben bleibt beim Unternehmen.

Praxisbeispiel: Ein neues Paket in einer Kundenanwendung

Angenommen, eine Agentur entwickelt eine Webanwendung für einen Kunden und ergänzt eine Bibliothek zur Dokumentenverarbeitung. Der Pull Request verändert die Paketdatei; der Dependency Graph erfasst die neue direkte und gegebenenfalls indirekte Abhängigkeit. Die Lizenzprüfung meldet, dass eine der erkannten Lizenzen nicht in der Unternehmensrichtlinie freigegeben ist. Im Active-Modus kann dieser Pull Request zunächst nicht zusammengeführt werden.

Das Team hat nun mehrere saubere Optionen: Es wählt eine alternative Bibliothek, klärt die konkrete Nutzung mit einer zuständigen Stelle oder beantragt eine begründete Ausnahme. Erst danach geht die Änderung weiter. Der praktische Vorteil liegt im Zeitpunkt: Die Frage wird während der Entwicklung gestellt und nicht erst, wenn ein Kunde Unterlagen zur eingesetzten Open-Source-Software anfordert.

Einführung in fünf Schritten ohne unnötige Blockaden

Für berechtigte Enterprise-Teams empfiehlt sich ein gestufter Ablauf. Zuerst werden Dependency Graph und Lizenzdaten geprüft. Anschließend definieren Technik, Compliance und gegebenenfalls Rechtsabteilung gemeinsam eine erste Policy mit SPDX-Kennungen. Danach werden Verantwortliche für Ausnahmeentscheidungen benannt. Ein Ruleset im Evaluate-Modus sammelt reale Ergebnisse, bevor ausgewählte Repositories auf Active umgestellt werden.

GitHub beschreibt für größere Umgebungen zusätzlich den Einsatz von Repository Custom Properties, um Repositories als inactive, evaluate oder active zu klassifizieren. Das ermöglicht eine kontrollierte Einführung nach Projekttyp oder Risikoprofil. Sinnvoll sind außerdem Tests mit bewusst unzulässigen Test-Abhängigkeiten, dokumentierte Eskalationswege und regelmäßige Kontrollen der Ausnahmen. Eine technische Sperre ohne funktionierenden Entscheidungsprozess wird sonst schnell zum Hindernis.

Was kleinere Teams ohne Enterprise-Lizenz tun können

Nicht jedes Projekt kann die neue Funktion unmittelbar nutzen. Kleinere Teams sollten daraus aber nicht schließen, dass Lizenzmanagement nur für Konzerne relevant ist. Schon eine gepflegte Liste der verwendeten Pakete, eine nachvollziehbare Freigabe neuer Abhängigkeiten und ein Blick auf Lizenzangaben im Dependency Graph schaffen mehr Transparenz. Auch die bestehende Dependency Review Action bietet eigene Möglichkeiten, Lizenzkennungen bei Pull Requests zu prüfen.

Der Unterschied liegt vor allem in der zentralen Steuerung: Eine einzelne Workflow-Konfiguration ist nicht dasselbe wie eine unternehmensweit verwaltete, auditierbare Richtlinie mit Rollen und Ausnahmen. Wer heute mit einfacheren Prüfungen beginnt, sollte deshalb Zuständigkeiten und Dokumentation von Anfang an sauber festhalten. Das erleichtert später den Wechsel zu einer umfassenderen Lösung.

Einordnung: Lizenz-Compliance ergänzt Security, ersetzt sie aber nicht

Eine erlaubte Lizenz macht eine Bibliothek nicht automatisch sicher; umgekehrt ist eine sichere Bibliothek nicht zwingend mit jeder Lizenzrichtlinie vereinbar. Schwachstellenanalyse, Versionspflege, Herkunftsnachweise und Lizenzprüfung lösen unterschiedliche Aufgaben. Erst im Zusammenspiel entsteht ein belastbarer Prozess für die Software-Lieferkette. Die neue GitHub-Funktion ergänzt bestehende Sicherheitsprüfungen um eine organisatorisch und rechtlich wichtige Dimension.

Für Webagenturen, SaaS-Anbieter und interne Entwicklungsteams lautet die zentrale Lehre daher: Open-Source-Nutzung braucht nachvollziehbare Entscheidungen, nicht nur schnelle Installationsbefehle. GitHubs Freigabe vom 16. Oktober 2026 macht es berechtigten Enterprise-Kunden leichter, diese Entscheidungen direkt im Pull-Request-Prozess zu verankern. Ob das im Alltag funktioniert, hängt weiterhin von realistischen Richtlinien, gepflegten Abhängigkeitsdaten und verantwortlichen Menschen ab.