Open-Source-Lizenzen: GPL, MIT, Apache erklärt für Entscheider
Open-Source-Lizenzen bestimmen, was Sie mit fremdem Code dürfen. Und was auf keinen Fall. GPL, MIT, Apache, LGPL: Die Namen klingen technisch. Die Konsequenzen bei Missachtung sind es nicht.
Dieser Artikel erklärt die wichtigsten Open-Source-Lizenzen verständlich. Ohne Jura-Studium. Dafür mit konkreten Beispielen aus dem Unternehmensalltag.
Was ist eine Open-Source-Lizenz?
Open-Source-Software ist keine Software ohne Regeln. Sie hat immer eine Lizenz. Diese Lizenz legt fest, was erlaubt ist und was nicht.
"Frei" bedeutet bei Open Source nicht "rechtsfrei". Es bedeutet, dass der Quellcode einsehbar ist. Und dass Sie ihn nutzen, verändern und weitergeben dürfen. Aber unter bestimmten Bedingungen.
Diese Bedingungen variieren erheblich. Ein MIT-lizenziertes Paket können Sie in ein kommerzielles Produkt einbetten. Niemand wird Sie danach fragen. Ein GPL-lizenziertes Paket zieht Pflichten nach sich, die Ihr gesamtes Produkt betreffen können.
Wer mehr über die Grundlagen erfahren möchte, findet eine klare Einführung in unserem Artikel zur Open-Source-Definition und Bedeutung.
Die zwei großen Lager: Permissiv und Copyleft
Open-Source-Lizenzen lassen sich in zwei Kategorien einteilen.
Permissive Lizenzen: Wenige Auflagen
Permissive Lizenzen erlauben fast alles. Sie dürfen den Code nutzen, verändern und in eigenen Produkten einbetten. Auch in proprietären, also nicht quelloffenen Produkten.
Sie müssen nur eines tun: Den Urheber nennen. Ein Copyright-Hinweis reicht in der Regel aus.
Bekannte permissive Lizenzen sind MIT, Apache 2.0 und BSD.
Copyleft-Lizenzen: Weitergabe erzwingt Offenheit
Copyleft-Lizenzen funktionieren anders. Wer Software unter einer Copyleft-Lizenz nutzt und weitergibt, muss das Ergebnis unter denselben Bedingungen veröffentlichen.
Das bedeutet: Wenn Sie GPL-Code in Ihre Software einbauen und diese Software weitergeben, müssen Sie Ihren eigenen Quellcode offenlegen.
Für viele Unternehmen ist das ein Problem. Für andere ist es ein Modell, das bewusst gewählt wird.
Die bekannteste Copyleft-Lizenz ist die GPL (GNU General Public License).
Die wichtigsten Lizenzen im Überblick
MIT: Unkompliziert und weitverbreitet
Die MIT-Lizenz ist die beliebteste Open-Source-Lizenz weltweit. Sie ist kurz, verständlich und stellt kaum Anforderungen.
Was Sie dürfen: Alles. Nutzen, verändern, verkaufen, in eigene Produkte einbetten.
Was Sie müssen: Den Lizenztext und den Copyright-Hinweis beibehalten.
Für Unternehmen ist MIT die unkomplizierteste Variante. Kein Risiko, keine Überraschungen. Viele JavaScript-Bibliotheken und Node.js-Pakete nutzen MIT.
Apache 2.0: MIT mit Patentschutz
Die Apache-2.0-Lizenz ähnelt MIT stark. Sie ist ebenfalls permissiv. Sie fügt jedoch einen wichtigen Punkt hinzu: eine explizite Patenterteilung.
Das bedeutet: Wer Software unter Apache 2.0 veröffentlicht, gewährt Nutzern auch eine Lizenz auf enthaltene Patente. Das schützt Sie als Nutzer vor späteren Patentklagen.
Apache 2.0 ist besonders im Java-Umfeld verbreitet. Das Spring Framework und Kubernetes nutzen diese Lizenz.
Unternehmen mit Patentrisiko bevorzugen Apache 2.0 gegenüber MIT. Für kleine Unternehmen ohne Patentportfolio ist der praktische Unterschied gering.
GPL: Starkes Copyleft mit weitreichenden Folgen
Die GPL (GNU General Public License) ist die bekannteste Copyleft-Lizenz. Sie wurde entwickelt, um Offenheit zu erzwingen.
Was Sie dürfen: Den Code nutzen, verändern und weitergeben.
Was Sie müssen: Wenn Sie veränderten Code weitergeben, müssen Sie ihn ebenfalls unter GPL veröffentlichen. Inklusive Ihres eigenen Quellcodes.
Das ist der kritische Punkt für Unternehmen. Wer ein proprietäres Produkt verkaufen möchte, kann darin keine GPL-lizenzierten Komponenten verwenden. Oder er muss das Produkt selbst unter GPL stellen.
Der GPL-Effekt gilt nur bei Weitergabe. Interne Nutzung ist frei. Aber sobald Sie Software ausliefern, die GPL-Code enthält, greifen die Regeln.
Bekannte GPL-Software: Linux-Kernel, MySQL (Community Edition), WordPress (das CMS selbst).
LGPL: Schwächeres Copyleft für Bibliotheken
Die LGPL (GNU Lesser General Public License) ist ein Kompromiss. Sie wurde speziell für Bibliotheken entwickelt.
Der Unterschied zur GPL: Sie dürfen LGPL-Bibliotheken in proprietärer Software verwenden, ohne Ihren eigenen Quellcode offenlegen zu müssen. Veränderungen an der LGPL-Bibliothek selbst müssen jedoch offen bleiben.
Für Unternehmen bedeutet LGPL: Sie können die Bibliothek nutzen, solange Sie sie nicht grundlegend verändern. Das ist für viele Anwendungsfälle akzeptabel.
AGPL: Die strengste Variante
Die AGPL (Affero GPL) verdient besondere Aufmerksamkeit. Sie schließt eine Lücke der normalen GPL.
Bei der GPL gelten die Copyleft-Regeln nur bei Weitergabe der Software. Wer Software nur über ein Netzwerk anbietet (als Web-App), gab die Software technisch nicht weiter. Die AGPL schließt genau diese Lücke.
Wenn Sie AGPL-Software in einem Web-Dienst einsetzen, müssen Sie Ihren Quellcode offenlegen. Auch ohne direkte Weitergabe.
Was passiert bei falscher Lizenznutzung?
Open-Source-Lizenzen sind keine Empfehlungen. Sie sind Verträge. Wer die Bedingungen nicht einhält, riskiert Abmahnungen und Klagen.
In Deutschland gibt es eine aktive Community, die Lizenzverletzungen verfolgt. Die Initiative gpl-violations.org hat zahlreiche Hersteller abgemahnt. Auch bekannte Unternehmen wurden bereits zur Rechenschaft gezogen.
Die Konsequenzen sind handfest: Unterlassungserklärung, Anwaltskosten, im schlimmsten Fall Schadensersatz.
Das Risiko ist besonders hoch bei:
- Software, die an Kunden weitergegeben wird (nicht nur intern genutzt)
- Produkten, die GPL-Komponenten enthalten, ohne Quelloffenlegung
- Anwendungen ohne korrekte Copyright-Hinweise
Was Entscheider konkret tun sollten
Schritt 1: Bestand aufnehmen
Wissen Sie, welche Open-Source-Pakete in Ihrer Software stecken? In modernen Projekten sind es oft Dutzende, manchmal Hunderte. Jedes hat seine eigene Lizenz.
Ein License-Audit schafft Klarheit. Werkzeuge wie FOSSA oder Black Duck helfen dabei, den Bestand zu erfassen. Auch einfachere Lösungen wie der npm-Befehl license-checker geben schnell einen Überblick.
Schritt 2: Kritische Lizenzen identifizieren
Nicht jede Lizenz ist gleich riskant. Permissive Lizenzen wie MIT und Apache 2.0 sind für die meisten Unternehmensanwendungen unbedenklich.
GPL und AGPL verlangen besondere Aufmerksamkeit. Identifizieren Sie diese Pakete und prüfen Sie, ob Alternativen verfügbar sind.
Schritt 3: Unklare Fälle klären lassen
Lizenzrecht ist komplex. Im Zweifelsfall lohnt sich ein kurzes Gespräch mit einem Anwalt für IT-Recht. Die Kosten sind überschaubar. Ein Rechtsstreit wegen Lizenzverletzung ist es nicht.
Was Sie außerdem tun können: den regelmäßigen Lizenz-Check als festen Teil Ihrer Software-Wartung etablieren. So sammeln sich keine unbekannten Verbindlichkeiten an. Mehr dazu in unserem Artikel zu Open Source im Unternehmen: Chancen, Pflichten und versteckte Kosten.
Warum das Thema bei Legacy-Software besonders wichtig ist
Bei älteren Projekten ist das Lizenzthema besonders heikel. Niemand hat bei der ursprünglichen Entwicklung konsequent dokumentiert, welche Bibliotheken unter welchen Bedingungen eingebunden wurden.
Im Laufe der Jahre kommen Pakete hinzu. Andere werden vergessen. Die Lizenzkette wird unübersichtlich.
Wer ein Altsystem übernimmt oder modernisiert, sollte den Lizenzbestand früh prüfen. Sonst erbt man nicht nur den Code, sondern auch die offenen Verpflichtungen. Das ist eine technische Schuld, die Entscheider selten auf dem Radar haben.
Was ein formeller Lizenz-Audit konkret bedeutet und wann er sich lohnt, erklärt unser Artikel: Software-Lizenz-Audit: Wenn der Hersteller nachprüft was Sie nutzen.
Und wer noch unsicher ist, ob Open Source oder proprietäre Software die bessere Wahl ist, findet eine ehrliche Gegenüberstellung in: Open Source vs. proprietäre Software: Was ist besser für den Mittelstand?.
Fazit: Open-Source-Lizenzen sind kein Entwicklerthema
Open-Source-Lizenzen betreffen jeden, der Software einsetzt, vertreibt oder verkauft. Die wichtigste Unterscheidung ist einfach: Permissive Lizenzen (MIT, Apache 2.0) erlauben fast alles. Copyleft-Lizenzen (GPL, LGPL, AGPL) stellen Bedingungen, die Sie kennen sollten, bevor Sie fremden Code einbauen.
Ein License-Audit ist kein großes Projekt. Aber er gibt Ihnen Klarheit. Und er schützt Sie vor Überraschungen, die deutlich teurer werden.
Sprechen Sie uns an. Wir helfen Ihnen, den Lizenzbestand Ihrer Software zu verstehen und Risiken einzugrenzen. Das Erstgespräch ist kostenlos.
