Open-Source-Lizenzen im Unternehmen: Compliance-Risiken bei GPL, MIT & Co.

Ohne Open Source würde moderne Software nicht existieren. Fast jedes Produkt baut auf Bibliotheken auf, die andere kostenlos bereitstellen. Doch „kostenlos“ heißt nicht „ohne Bedingungen“. Wer Open-Source-Lizenzen ignoriert, riskiert Abmahnungen, Vertragsstrafen und im Extremfall die Pflicht, eigenen Quellcode offenzulegen. Dieser Beitrag ordnet die wichtigsten Lizenztypen ein und zeigt, wie Sie Compliance im Unternehmen strukturiert herstellen.

Die zentrale Unterscheidung verläuft zwischen permissiven und Copyleft-Lizenzen. Permissive Lizenzen wie MIT, BSD oder Apache 2.0 erlauben die Nutzung mit minimalen Pflichten — meist Nennung des Urhebers und Beifügung des Lizenztextes. Copyleft-Lizenzen wie die GPL verlangen mehr: Wer ein Werk auf ihrer Basis verbreitet, muss es unter denselben Bedingungen weitergeben, einschließlich des Quellcodes. Zwischen diesen Polen liegen abgestufte Lizenzen wie die LGPL oder die MPL.

Warum Copyleft das größte Risiko trägt

Das Risiko der GPL liegt im sogenannten Copyleft-Effekt: Bindet ein Unternehmen GPL-Code so in ein proprietäres, vertriebenes Produkt ein, dass ein abgeleitetes Werk entsteht, kann die Verpflichtung entstehen, den gesamten Quellcode dieses Produkts offenzulegen. Für ein Geschäftsmodell, das auf geschlossenem Code beruht, ist das existenzbedrohend. Ob ein solches abgeleitetes Werk vorliegt, ist eine anspruchsvolle juristisch-technische Frage — und genau deshalb Gegenstand eines Audits.

Ein besonderer Fall ist die AGPL, die den Copyleft-Effekt auch auf über das Netzwerk bereitgestellte Software ausdehnt — relevant für jeden SaaS-Anbieter. Wer eine AGPL-Komponente in seinem Dienst betreibt, kann verpflichtet sein, den Quellcode gegenüber den Nutzern offenzulegen, obwohl die Software nie „ausgeliefert“ wird. Solche Feinheiten übersieht, wer Lizenzen nur oberflächlich prüft.

So stellen Sie Open-Source-Compliance her

Der erste Schritt ist Transparenz: eine vollständige Software Bill of Materials, die jede Komponente mit Version und Lizenz erfasst. Der zweite Schritt ist die Bewertung: Welche Lizenzpflichten treffen zu, welche sind mit dem Geschäftsmodell vereinbar? Der dritte Schritt ist der Prozess: Neue Abhängigkeiten werden vor der Aufnahme geprüft, nicht erst beim Audit. So verhindern Sie, dass sich Risiken unbemerkt in die Codebasis schleichen.

Wie wir eine SBOM erstellen und Lizenzrisiken bewerten, beschreiben wir unter Software-Audits & Code-Prüfung. Wo eingebundene Komponenten personenbezogene Daten verarbeiten, verbinden wir die Lizenzbewertung mit der datenschutzrechtlichen Prüfung, damit beide Risikodimensionen in einem Bericht zusammenlaufen.

Compliance als Wettbewerbsvorteil

Saubere Open-Source-Compliance ist nicht nur Risikovermeidung. Sie ist ein Qualitätsmerkmal, das in Ausschreibungen und bei Investoren zunehmend abgefragt wird. Ein Unternehmen, das seine Komponenten kennt und deren Lizenzen beherrscht, wirkt professionell und verhandelt aus einer stärkeren Position. RA Dr. Henrik Vance empfiehlt, Lizenzprüfung in den Entwicklungsprozess zu integrieren — als kontinuierliche Praxis, nicht als einmaliges Feuerwehr-Projekt. Weitere Informationen finden Sie in unseren Leistungen.