Open-Source-Lizenzen: MIT, GPL und Co. erklärt

Fast jede moderne Anwendung besteht zu großen Teilen aus Open-Source-Komponenten. Bibliotheken, Frameworks, Werkzeuge. Oft ohne dass jemand im Haus genau weiß, welche Lizenzen dabei sind.

Das geht meistens gut. Bis es nicht mehr gut geht. Etwa, wenn ein Kunde nachfragt, wenn ein Code-Audit ansteht oder wenn Sie Ihre Anwendung als SaaS anbieten wollen.

Dieser Artikel erklärt die wichtigsten Open-Source-Lizenzen, was permissiv und Copyleft im Alltag bedeuten und wo in Ihrem Abhängigkeitsbaum Risiken lauern.

Was ist eine Open-Source-Lizenz überhaupt?

Open Source bedeutet nicht "frei nutzbar ohne Regeln". Open Source bedeutet, dass der Quellcode öffentlich einsehbar ist und unter klar definierten Bedingungen weiterverwendet werden darf.

Diese Bedingungen stehen in der Lizenz. Sie regeln, was Sie mit dem Code tun dürfen, was Sie weitergeben müssen und wie Sie den Urheber zu nennen haben. Mehr Hintergrund finden Sie im Glossar unter Open Source.

Es gibt grob zwei Familien: permissive Lizenzen und Copyleft-Lizenzen. Die Unterscheidung entscheidet im Alltag fast alles.

Permissive Lizenzen: viel Freiheit, wenig Pflicht

Permissive Lizenzen erlauben fast alles. Sie dürfen den Code in eigene Produkte einbauen, verändern, kommerziell vertreiben und schließen. Sie müssen den Urheber nennen, und das war es im Kern.

MIT

Die wohl bekannteste permissive Lizenz. Sehr kurz, sehr klar. Sie dürfen den Code in nahezu jeder Form nutzen, solange der Lizenztext und der Urheberhinweis erhalten bleiben. Geeignet für kommerzielle Produkte ohne weitere Verpflichtungen.

Apache 2.0

Ähnlich permissiv wie MIT, aber mit zusätzlichen Klauseln zum Patentschutz. Wer Code unter Apache 2.0 beisteuert, gewährt automatisch Patentrechte. Für Unternehmen, die Patente halten, ist das wichtig zu wissen.

BSD (2-Clause und 3-Clause)

Eine alte permissive Lizenzfamilie. Inhaltlich nah an MIT. Die 3-Clause-Variante verbietet zusätzlich, dass Sie den Namen des Originalprojekts für Werbung Ihres Produkts nutzen.

Für die meisten kommerziellen Anwendungen sind diese drei Lizenzen unproblematisch.

Copyleft-Lizenzen: Freiheit mit Verpflichtung

Copyleft-Lizenzen drehen die Logik um. Sie dürfen den Code nutzen und ändern, aber wenn Sie ihn weitergeben, müssen Sie auch Ihre Änderungen unter derselben Lizenz veröffentlichen. Der Code soll frei bleiben.

GPL (GNU General Public License)

Die klassische Copyleft-Lizenz. Wenn Sie GPL-Code in Ihrer Software verwenden und diese weitergeben, muss Ihre gesamte Anwendung unter GPL stehen. Das schließt den Quellcode ein.

Für reine Inhouse-Nutzung kein Problem. Für ein kommerzielles Produkt, das Sie als Lizenz verkaufen, oft ein Ausschlusskriterium.

LGPL (Lesser GPL)

Die abgeschwächte Variante. Sie dürfen LGPL-Bibliotheken als externe Komponenten in proprietären Anwendungen nutzen, ohne Ihren eigenen Code offenlegen zu müssen. Voraussetzung ist, dass die Bibliothek dynamisch eingebunden wird und ausgetauscht werden kann.

AGPL (Affero GPL)

Die strengste Variante. AGPL schließt die "SaaS-Lücke" der klassischen GPL. Sobald Sie eine AGPL-Anwendung über das Netz anbieten, etwa als Webdienst, müssen Sie Ihren angepassten Quellcode öffentlich machen. Auch ohne Weitergabe der Software selbst.

Wer eine SaaS plant, sollte AGPL-Komponenten sehr bewusst prüfen.

MPL (Mozilla Public License)

Ein Mittelweg. MPL gilt auf Datei-Ebene. Geänderte MPL-Dateien müssen offen bleiben, eigene Dateien im selben Projekt nicht. Das macht die Lizenz für gemischte Produkte praxistauglich.

Praktische Konsequenzen im Alltag

Kommerzielle Nutzung

Permissive Lizenzen (MIT, Apache, BSD) sind unkritisch. Sie können den Code einbauen, verkaufen, anpassen.

GPL ist heikel. Wer eine GPL-Bibliothek tief in ein proprietäres Produkt einbaut, kann gezwungen sein, das ganze Produkt unter GPL zu stellen.

Weitergabe von Software

Wer Software an Kunden ausliefert, löst die Pflichten der Lizenz aus. Bei MIT reicht der Urheberhinweis. Bei GPL muss der vollständige Quellcode beigelegt oder zugänglich gemacht werden.

SaaS-Betrieb

Hier zeigt sich der Unterschied zwischen GPL und AGPL. GPL gilt nur bei Weitergabe. Wer eine GPL-Anwendung nur intern betreibt oder über das Netz bereitstellt, muss nichts offenlegen.

Bei AGPL ist genau das anders. Schon der Betrieb als Dienst löst die Offenlegungspflicht aus.

Kombination mehrerer Lizenzen

Probleme entstehen oft erst durch Kombinationen. AGPL plus proprietärer Code in einem Produkt: Konflikt. GPL plus Apache 2.0 im selben Modul: kompatibel, aber mit Auflagen. MIT plus alles: in der Regel unproblematisch.

Das Risiko im Abhängigkeitsbaum

Eine moderne Anwendung hat selten zehn Abhängigkeiten. Eher hundert oder tausend, sobald man indirekte Abhängigkeiten mitzählt.

Jede dieser Komponenten bringt eine eigene Lizenz mit. Sie ist mit anderen Lizenzen kompatibel oder eben nicht. Niemand prüft das im Alltag.

Werkzeuge wie license-checker (npm), Composer-Plugins oder Software Composition Analysis machen den Lizenzwald sichtbar. Eine Software-Bill-of-Materials, kurz SBOM, listet alle Komponenten samt Lizenz auf.

Wer eine solche Liste hat, kennt seine Position. Wer keine hat, ratet.

Typische Fallstricke

Code aus Stack Overflow. Antworten dort stehen unter einer Creative-Commons-Lizenz, die in vielen Fällen nicht zu Produktcode passt. Direktes Kopieren ist juristisch heikel.

Bilder und Fonts. Open Source betrifft nicht nur Code. Schriften und Icons haben eigene Lizenzen, die oft Namensnennung oder Sharealike fordern.

Inkompatibilität entdecken. Eine GPL-Bibliothek wird per Update neu aufgenommen, ein zweites Projekt nutzt eine inkompatible Lizenz. Bei der nächsten Auslieferung steht plötzlich ein Konflikt im Raum.

Dual Licensing. Manche Projekte bieten zwei Lizenzen an: GPL für Open-Source-Nutzung, eine kommerzielle Lizenz für proprietäre Produkte. Wer das nicht beachtet, zahlt nicht und verletzt zugleich die GPL.

Was Sie konkret tun sollten

1. SBOM erstellen. Listen Sie auf, welche Open-Source-Komponenten in Ihrer Anwendung stecken. Mit Lizenz und Version.

2. Lizenzen kategorisieren. Permissive Lizenzen rot, gelb oder grün markieren. Copyleft-Lizenzen gesondert prüfen.

3. Regeln festlegen. Welche Lizenzen sind im Unternehmen erlaubt? Welche brauchen eine Freigabe? Das spart später Diskussionen.

4. Automatisieren. Lizenz-Checks in den Build-Prozess einbauen. Neue Abhängigkeiten mit verbotener Lizenz scheitern dann, bevor sie produktiv werden.

5. Bei Unsicherheit prüfen lassen. Ein Sicherheits-Audit deckt nicht nur Schwachstellen auf, sondern oft auch Lizenzkonflikte im Abhängigkeitsbaum.

Fazit

Open-Source-Lizenzen sind kein Hexenwerk. Aber sie sind auch nicht egal. Wer den Unterschied zwischen MIT und AGPL kennt und einmal Klarheit über den eigenen Abhängigkeitsbaum schafft, vermeidet die meisten unangenehmen Überraschungen.

Wenn Sie nicht wissen, welche Lizenzen in Ihrer Software stecken, sprechen Sie uns an. Wir prüfen Ihre Abhängigkeiten und sagen Ihnen, wo Sie stehen. Kontakt aufnehmen.