Open-Source-Lizenzen kommerziell nutzen: MIT, GPL und AGPL einfach erklärt

Worum es geht: Fast jede Website, App oder interne Software besteht zum größten Teil aus fremden Open-Source-Bausteinen. Die dürfen Sie fast immer auch kommerziell nutzen. Jede Lizenz knüpft das aber an Bedingungen, und die greifen nicht beim Benutzen, sondern meist erst beim Weitergeben. Wer das eine Wort versteht, versteht den Großteil des Themas.

Kein Rechtsrat. Wir erklären die Lizenztexte, wie sie geschrieben sind. Für einen konkreten Vertrag oder Streitfall fragen Sie einen Anwalt.

Die zwei Familien

Freizügige Lizenzen (MIT, BSD, Apache 2.0): Sie dürfen den Code nehmen, ändern, verkaufen und in geschlossene Produkte einbauen. Die Pflichten sind klein.

Copyleft-Lizenzen (GPL, LGPL, AGPL): Auch hier dürfen Sie alles, inklusive Geld verdienen. Aber wer das Programm weitergibt, muss den Empfängern dieselben Freiheiten geben, also auch den Quellcode.

MIT: Hinweis mitliefern, fertig

Die MIT-Lizenz verlangt im Kern einen Satz: Der Copyright-Vermerk und der Lizenztext müssen in allen Kopien oder wesentlichen Teilen der Software enthalten sein^[1]. Mehr nicht. Die meisten Bausteine aus dem JavaScript-Umfeld stehen unter MIT oder ähnlich kurzen Lizenzen. (Einschätzung aus unserer Praxis.)

Apache 2.0: Hinweise plus Patentfrieden

Apache 2.0 ist ebenfalls freizügig, regelt aber zwei Dinge mehr. Erstens: Liegt dem Projekt eine Datei namens NOTICE bei, müssen Sie deren Hinweise bei der Weitergabe mitliefern, etwa in einer eigenen NOTICE-Datei oder dort, wo Ihre Software Drittanbieter-Hinweise anzeigt^[2]. Zweitens räumt jeder Mitwirkende Ihnen eine Patentlizenz für seinen Beitrag ein. Die erlischt, wenn Sie selbst jemanden verklagen, weil das Werk Ihr Patent verletze^[2].

GPL: Wer weitergibt, gibt den Quellcode mit

Die GPL v3 unterscheidet zwei Dinge sauber:

• Benutzen und intern ändern ist frei.
• Weitergeben heißt in der Lizenz „convey“: jede Verbreitung, die es anderen ermöglicht, Kopien zu erhalten. Und dann der wichtige Satz: Bloße Interaktion mit einem Nutzer über ein Netzwerk, ohne dass eine Kopie übertragen wird, ist keine Weitergabe^[3].

Geben Sie ein GPL-Programm als fertige Datei weiter, müssen Sie den „Corresponding Source“ mitliefern, also den vollständigen Quellcode in maschinenlesbarer Form^[3]. Bei Geräten, die Sie verkaufen, gehören auch die Informationen dazu, mit denen der Käufer eine geänderte Version installieren kann^[3].

Für Sie heißt das: Ein GPL-Programm auf Ihrem eigenen Server, das Kunden nur über den Browser benutzen, löst nach dem Text der GPL keine Quellcodepflicht aus^[3]. Bauen Sie es dagegen in eine Software ein, die Sie verkaufen oder herunterladen lassen, dann schon.

LGPL: GPL für Bibliotheken

Die LGPL ist eine abgeschwächte GPL für Programmbibliotheken. Sie hat einen eigenen Abschnitt für „Combined Works“, also für Programme, die die Bibliothek nur verwenden^[4]. Vereinfacht: Ihr eigenes Programm darf geschlossen bleiben, aber die Bibliothek selbst und Ihre Änderungen daran bleiben LGPL, und der Empfänger muss die Bibliothek austauschen können. Die Details stehen in Abschnitt 4 der Lizenz^[4]. (Vereinfachung von uns.)

AGPL: die GPL für das Netz

Die AGPL schließt genau die Lücke, die die GPL beim Server offen lässt. Ihr Abschnitt 13 sagt: Wenn Sie das Programm ändern, muss Ihre geänderte Version allen Nutzern, die über ein Netzwerk damit arbeiten, den Quellcode anbieten^[5].

Zwei Sätze aus der AGPL werden oft übersehen:

• Die Lizenz bestätigt ausdrücklich Ihre „unbegrenzte Erlaubnis, das unveränderte Programm auszuführen“^[5].
• Die Ausgabe eines Programms fällt nur dann unter die Lizenz, wenn sie selbst ein geschütztes Werk ist^[5]. Eine PDF, die ein AGPL-Programm erzeugt, wird also nicht AGPL.

Die Free Software Foundation, die die Lizenz geschrieben hat, sieht Programme, die über Kommandozeile, Dateien oder Sockets miteinander reden, in der Regel als getrennte Programme an^[6]. Wer ein AGPL-Werkzeug unverändert im Hintergrund aufruft, muss den eigenen Code danach nicht offenlegen. Das ist die Lesart der FSF, kein Urteil. (Einschätzung.)

Achtung: Schon ein kleiner Patch, etwa damit sich das Programm bauen lässt, ist eine Änderung^[5]. Ob dann Abschnitt 13 greift, ist bei Werkzeugen, die Nutzer nicht direkt bedienen, umstritten: Die FSF zählt ein Programm, das nicht dafür gebaut ist, mit Nutzern über ein Netz zu arbeiten, nicht dazu, auch wenn es zufällig so läuft^[6]. Der sichere Weg: Ihre Patches veröffentlichen.

So machen es andere: Der 3D-Druck-Dienst SimplyPrint betreibt den AGPL-Slicer PrusaSlicer nach eigener Aussage unverändert über die Kommandozeile^[14] und veröffentlicht seine Bau-Patches offen auf GitHub^[15]. Das erfüllt die Lizenz auch bei strengster Lesart. (Einschätzung.)

Die häufigste Falle: Ihr Frontend ist eine Weitergabe

Viele denken: „Wir sind SaaS, wir geben nichts weiter.“ Das stimmt nur für den Server. Der JavaScript-Code Ihrer Website, Ihre mobile App oder eine Erweiterung, die im Shop des Kunden läuft, wird an den Nutzer übertragen. Nach der Definition der GPL ist das eine Weitergabe, denn der Nutzer erhält eine Kopie^[3]. (Unsere Lesart.)

Daraus folgen zwei praktische Regeln:

1. Lizenzhinweise der Frontend-Bausteine mitliefern, etwa als Seite „Lizenzen“ oder als Datei im Bundle. Das verlangen schon MIT und Apache^[1][2]. Werkzeuge, die die Hinweise automatisch aus den Paketen sammeln, gibt es für jede gängige Sprache.
2. GPL- und AGPL-Bibliotheken im Frontend meiden, außer Sie wollen das Frontend ohnehin offenlegen.

Und wenn man die Lizenz ignoriert?

Deutsche Gerichte haben die GPL bereits durchgesetzt. Das Landgericht München I hat 2004 in einem Eilverfahren eine einstweilige Verfügung gegen einen Händler bestätigt, der Router mit der Firewall-Software netfilter/iptables verkaufte, ohne die GPL einzuhalten^[7][8]. Das Gericht hatte laut der Übersetzung des Urteils „keine Zweifel“ an der Wirksamkeit der Bedingungen der GPL^[7].

Die GPL v3 regelt die Folge selbst: Wer sie verletzt, verliert seine Rechte automatisch. Wer die Verletzung beendet, bekommt sie zurück, endgültig, wenn der Rechteinhaber sich nicht binnen 60 Tagen meldet. Beim ersten Hinweis haben Sie außerdem 30 Tage Zeit, den Fehler zu beheben^[3]. Ohne Lizenz nutzen Sie fremden Code ohne Erlaubnis. Dann drohen Unterlassung und Schadensersatz nach Urheberrecht. (Einschätzung.)

Recht und Praxis: Die Lizenz selbst ist auf Reparieren angelegt, nicht auf Strafe: Wer nach dem ersten Hinweis innerhalb von 30 Tagen nachbessert, behält seine Rechte^[3]. Ein Fehler, den Sie schnell beheben, ist also meist kein Drama. Teuer wird es, wenn Sie Hinweise ignorieren. (Einschätzung.)

Lizenzen können sich ändern

Für die Bausteine, auf die Sie sich verlassen, lohnt ein Blick auf den Hersteller. Einige bekannte Projekte haben ihre Lizenz gewechselt:

• HashiCorp stellte Terraform am 10.08.2023 von der Open-Source-Lizenz MPL auf die Business Source License um, die keine Open-Source-Lizenz ist. Daraufhin entstand der freie Ableger OpenTofu unter dem Dach der Linux Foundation^[11].
• Elastic kündigte am 29.08.2024 an, Elasticsearch wieder unter einer Open-Source-Lizenz anzubieten, der AGPL, und zwar zusätzlich zu den beiden eigenen Lizenzen ELv2 und SSPL. Weggenommen werde nichts^[9].
• Redis machte es ab Redis 8 (01.05.2025) genauso: AGPL als zusätzliche Option^[10].

Das ging, weil diese Firmen die Rechte am Code gebündelt hielten. (Einschätzung.) Für Sie heißt es: Alte Versionen bleiben unter der alten Lizenz, aber Updates können neue Bedingungen haben. Prüfen Sie die Lizenz bei jedem großen Versionssprung.

Neu ab Dezember 2026: Haftung für Software

Am 09.12.2026 tritt das neue Produkthaftungsgesetz in Kraft. Es zählt Software ausdrücklich zu den Produkten. Ausgenommen ist freie und Open-Source-Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird^[12]. Wer Open Source in ein Produkt einbaut und es verkauft, haftet also für das Produkt, auch für die eingebauten Teile. (Folgerung aus^[12].)

Wer Software als Produkt verkauft, sollte außerdem den Cyber Resilience Act kennen. Seine Meldepflichten für ausgenutzte Schwachstellen gelten seit 11.09.2026, die übrigen Pflichten ab 11.12.2027^[13]. Wen er genau betrifft, ist ein eigenes Thema.

Ihre Checkliste

1. Liste führen, welche fremden Bausteine in Ihrer Software stecken und unter welcher Lizenz (Fachwort: SBOM, Software-Stückliste).
2. Weitergabe erkennen: Download, App, Frontend, Gerät, Image an einen Dienstleister.
3. Hinweise mitliefern für alles, was Sie weitergeben.
4. Copyleft bewusst einsetzen: GPL und AGPL gern auf dem Server, unverändert und getrennt angebunden. Im ausgelieferten Code nur, wenn Sie den Quellcode offenlegen wollen.
5. Änderungen an AGPL-Code veröffentlichen oder vermeiden.
6. Lizenzwechsel beobachten bei großen Versionssprüngen.

Häufige Fragen

Darf ich Open-Source-Software verkaufen? Ja. Weder MIT noch GPL verbieten das^[1][3]. Die GPL verlangt aber, dass Käufer den Quellcode bekommen und ihn weitergeben dürfen^[3].

Muss ich meinen Code offenlegen, wenn ich eine GPL-Software auf meinem Server nutze? Nach dem Text der GPL nicht, solange Sie keine Kopie weitergeben^[3]. Bei der AGPL nur, wenn Sie das Programm geändert haben^[5].

Wird mein Programm GPL, wenn ich eine GPL-Bibliothek einbinde? Wenn Sie das zusammengesetzte Programm weitergeben, in der Regel ja. Bei LGPL-Bibliotheken nicht, solange Sie deren Bedingungen für „Combined Works“ einhalten^[4].

Wo Ihre Daten und Programme in Ihrem Betrieb sonst noch hängen, zeigen wir unter Datenwege.