Open Source Lizenz-Compliance bei Legacy-Projekten: Was oft übersehen wird
Ihre Anwendung läuft seit 2014. Sie nutzt ein paar hundert Open-Source-Pakete. Wer diese Pakete damals ausgewählt hat, arbeitet längst woanders. Und niemand im Haus kann sagen, unter welchen Lizenzen diese Pakete stehen. Genau so sieht Open Source Lizenz Compliance in den meisten Legacy-Projekten aus: Sie existiert nicht.
Das fällt lange nicht auf. Bis ein Investor eine Due Diligence startet. Bis ein Großkunde eine Lizenzliste verlangt. Oder bis jemand fragt, warum eine Bibliothek unter der AGPL in einem geschlossenen Produkt steckt. Dann wird aus einem vergessenen Thema plötzlich ein Verhandlungspunkt.
Dieser Artikel erklärt, was Lizenz-Compliance bei Open Source bedeutet. Er zeigt, welche Lizenzen wirklich Ärger machen können. Und er beschreibt, wie Sie einen Lizenz-Audit in einem gewachsenen Projekt durchführen, ohne den Betrieb zu stören.
Was Open Source Lizenz Compliance eigentlich verlangt
Open Source bedeutet nicht "kostenlos und ohne Bedingungen". Jede Bibliothek steht unter einer Lizenz. Diese Lizenz erlaubt die Nutzung, knüpft sie aber an Pflichten. Compliance heißt schlicht: Sie halten diese Pflichten ein.
Bei den meisten Lizenzen ist das einfach. MIT, BSD und Apache 2.0 verlangen im Kern nur eines. Sie nennen den Urheber und liefern den Lizenztext mit. Wer eine Datei mit Hinweisen zu allen verwendeten Paketen ausliefert, ist hier auf der sicheren Seite.
Schwieriger wird es bei sogenannten Copyleft-Lizenzen. Copyleft bedeutet: Wer die Software verändert und weitergibt, muss den eigenen Code unter derselben Lizenz offenlegen. Die bekannteste Lizenz dieser Art ist die GPL (GNU General Public License). Was die einzelnen Lizenzen im Detail erlauben, haben wir in unserem Überblick zu Open-Source-Lizenzen erklärt.
Der Punkt, den viele übersehen: Diese Pflichten gelten auch dann, wenn niemand sie kennt. Unwissenheit ist kein Verstoß weniger.
Warum Legacy-Projekte besonders betroffen sind
Ein neues Projekt startet heute meist mit einem Lizenz-Scanner in der Build-Pipeline. Ein Projekt aus 2012 kennt so etwas nicht. Dort haben sich die Abhängigkeiten über Jahre angesammelt. Jeder Entwickler hat hinzugefügt, was gerade praktisch war.
Drei Dinge machen die Lage bei alten Systemen schwieriger als bei neuen. Erstens fehlt die Dokumentation. Es gibt keine Liste, welche Pakete warum im Projekt sind. Zweitens stecken viele Abhängigkeiten nicht im Paketmanager, sondern als kopierte Dateien im Repository. Eine jQuery-Erweiterung von 2013 im Ordner vendor/js taucht in keinem Scan auf. Drittens haben manche Pakete im Laufe der Jahre ihre Lizenz gewechselt. Was 2015 unter MIT stand, kann heute unter einer restriktiveren Lizenz erscheinen.
Dazu kommt ein organisatorisches Problem. Das Wissen über die Software liegt oft bei einer einzigen Person. Wenn diese Person geht, geht auch die Antwort auf die Frage: "Warum nutzen wir diese Bibliothek überhaupt?"
Welche Lizenzen Sie zuerst prüfen sollten
Nicht jede Lizenz braucht die gleiche Aufmerksamkeit. Für einen ersten Audit reicht es, die Pakete nach Risiko zu sortieren.
AGPL: der Sonderfall für Webanwendungen
Die AGPL (GNU Affero General Public License) ist die schärfste der gängigen Lizenzen. Bei der normalen GPL greift das Copyleft erst, wenn Sie Software weitergeben. Eine interne Webanwendung, die nur auf Ihrem Server läuft, fällt oft nicht darunter. Die AGPL schließt genau diese Lücke. Sobald Nutzer über das Netzwerk mit der Software arbeiten, gilt die Offenlegungspflicht.
Für ein SaaS-Produkt oder ein Kundenportal ist das ein echtes Thema. Eine einzige AGPL-Bibliothek kann bedeuten, dass Sie den Quellcode Ihres gesamten Produkts herausgeben müssen. Bekannte Beispiele sind Grafana ab Version 8 und die PDF-Bibliothek iText. Auch ältere MongoDB-Versionen standen unter AGPL.
GPL: Vorsicht bei ausgelieferter Software
Die GPL in Version 2 oder 3 wird relevant, sobald Sie Software an Kunden ausliefern. Das betrifft Desktop-Anwendungen, Apps und Systeme, die beim Kunden installiert werden. Wer GPL-Code statisch in ein eigenes Produkt einbindet, muss das Produkt unter GPL stellen. Bei dynamischer Einbindung ist die Rechtslage umstritten. Eine belastbare Antwort gibt hier nur ein Anwalt.
LGPL: meist unproblematisch, aber mit Pflichten
Die LGPL (Lesser GPL) erlaubt die Nutzung in geschlossener Software. Bedingung: Die Bibliothek bleibt austauschbar. Änderungen an der Bibliothek selbst müssen Sie offenlegen. In der Praxis ist das für die meisten Projekte gut handhabbar.
Lizenzen ohne Text und "custom" Lizenzen
Ein oft übersehenes Risiko sind Pakete ohne Lizenzangabe. Ohne Lizenz haben Sie rechtlich gesehen kein Nutzungsrecht. Der Urheber hat es Ihnen nie eingeräumt. Dasselbe gilt für selbst geschriebene Lizenztexte, die niemand geprüft hat. Solche Pakete finden sich in alten Projekten erstaunlich häufig, meist als kopierte Snippets von Foren oder Blogs.
Was passiert, wenn Sie nichts tun
Die direkten Folgen eines Lizenzverstoßes sind Unterlassungsansprüche und Schadensersatz. In Deutschland gibt es dazu seit Jahren Urteile, unter anderem zu GPL-Verstößen bei Router-Herstellern. Die Beträge sind selten existenzbedrohend. Der eigentliche Schaden entsteht woanders.
Bei einem Unternehmensverkauf oder einer Finanzierungsrunde gehört die Lizenzprüfung inzwischen zum Standard. Wer dort keine saubere Liste vorlegen kann, verhandelt aus einer schwachen Position. Käufer preisen das Risiko ein oder verlangen eine Bereinigung vor dem Abschluss. Wie ein solcher Audit aus Sicht des Prüfers abläuft, beschreibt unser Artikel zum Software-Lizenz-Audit durch Hersteller.
Auch Großkunden fragen häufiger nach. Ausschreibungen verlangen eine SBOM, eine Software Bill of Materials. Das ist eine maschinenlesbare Stückliste aller Komponenten inklusive Lizenz. Mit dem Cyber Resilience Act der EU wird diese Stückliste für viele Produkte zur Pflicht. Wer sie nicht liefern kann, fliegt aus dem Verfahren.
So läuft ein Lizenz-Audit in vier Schritten
Ein Lizenz-Audit klingt nach Anwaltskanzlei. Der größte Teil ist aber technische Fleißarbeit. Sie brauchen erst am Ende juristische Hilfe, und auch nur für die Fälle, die Werkzeuge nicht auflösen können.
Schritt 1: Alle Abhängigkeiten finden
Beginnen Sie beim Paketmanager. Für PHP liefert composer licenses eine Liste aller Pakete mit Lizenz. Für Node.js gibt es license-checker oder npx license-report. Für Python pip-licenses. Für Java lesen Maven-Plugins die Lizenzen aus den POM-Dateien.
Danach kommt der schwierigere Teil: alles, was nicht im Paketmanager steht. Durchsuchen Sie das Repository nach Ordnern wie vendor, lib, assets/js oder third_party. Prüfen Sie Dateien mit fremden Copyright-Headern. Werkzeuge wie ScanCode Toolkit oder das OSS Review Toolkit scannen den Quelltext direkt. Sie erkennen Lizenztexte auch in einzelnen Dateien.
Schritt 2: Lizenzen zuordnen und normalisieren
Die Ergebnisse sind selten sauber. Ein Paket meldet "MIT", das nächste "MIT License", ein drittes "SEE LICENSE IN LICENSE.txt". Bringen Sie alles auf SPDX-Kennungen. SPDX ist ein Standard mit eindeutigen Kürzeln wie MIT, GPL-3.0-only oder Apache-2.0. So lässt sich die Liste später filtern und mit Ausschreibungen abgleichen.
Schritt 3: Risiko bewerten
Sortieren Sie die Liste in drei Gruppen. Unkritisch sind permissive Lizenzen wie MIT, BSD und Apache. Prüfen müssen Sie Copyleft-Lizenzen, also GPL, AGPL, LGPL und ähnliche. Sofort klären müssen Sie Pakete ohne Lizenz oder mit unbekanntem Lizenztext. Für jede Datei in den letzten beiden Gruppen beantworten Sie zwei Fragen: Wie wird das Paket eingebunden? Und wie wird die Software ausgeliefert oder betrieben?
Schritt 4: Bereinigen und dokumentieren
Für problematische Pakete gibt es fast immer eine Alternative unter permissiver Lizenz. Ein Austausch ist oft weniger Aufwand als befürchtet, weil viele dieser Pakete ohnehin veraltet sind. Das passt gut zu einem ohnehin fälligen Update-Lauf, den wir im Artikel zu Dependencies aktuell halten beschrieben haben.
Am Ende steht ein Dokument, das Sie vorzeigen können. Eine Lizenzliste, eine SBOM und eine Datei mit allen Pflichthinweisen, die Sie mit der Software ausliefern. Und ein Scanner in der Build-Pipeline, der neue Pakete mit unerwünschten Lizenzen ablehnt. Welche Pflichten damit im Alltag verbunden sind, lesen Sie in unserem Beitrag zu Open Source im Unternehmen.
Was das kostet und wie lange es dauert
Eine typische Legacy-Anwendung hat 300 bis 800 Abhängigkeiten. Der technische Teil des Audits dauert dort zwei bis fünf Arbeitstage. Der größte Zeitfresser sind kopierte Dateien ohne Paketmanager. Die juristische Bewertung der offenen Fälle kommt hinzu, betrifft aber meist nur eine Handvoll Pakete.
Das ist überschaubar, verglichen mit einer Due Diligence, die wegen fehlender Unterlagen ins Stocken gerät. Oder mit einem Produkt, das wegen einer AGPL-Bibliothek nachträglich umgebaut werden muss.
Fazit: Lizenzschulden sind auch technische Schulden
Unbekannte Lizenzen sind eine Form von technischen Schulden. Sie kosten im Alltag nichts. Sie werden fällig, wenn es gerade am wenigsten passt. Ein Lizenz-Audit räumt diesen Posten auf. Danach ist Open Source Lizenz Compliance kein Thema mehr, das Sie bei jeder Ausschreibung nervös macht.
Wir übernehmen solche Audits als Teil unserer Software-Wartung oder als einzelnes Projekt. Wir scannen, ordnen zu, ersetzen problematische Pakete und liefern die Dokumentation. Für die juristische Bewertung arbeiten wir mit spezialisierten Kanzleien zusammen.
Sie wissen nicht, was in Ihrer Anwendung steckt? Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
