Open-Source-Lizenzen: Copyleft vs. permissiv
Linux läuft auf fast allen Servern weltweit. React ist in Millionen Webprojekten. PostgreSQL ist eine der beliebtesten Datenbanken. All das ist Open Source – kostenlos, frei einsehbarer Quellcode. Aber „Open Source" bedeutet nicht „mach damit was du willst". Je nach Lizenz gibt es strenge Bedingungen – und wer sie ignoriert, riskiert Abmahnungen und Klage. Der entscheidende Unterschied ist: Copyleft oder permissiv.
1) Das Grundprinzip: zwei Philosophien
Copyleft vs. permissiv – der Kernunterschied
🔁 Copyleft-Lizenzen
Grundprinzip: Wer die Software modifiziert und weitergibt, muss den Code ebenfalls unter derselben Lizenz offenlegen.
Ziel: Software soll dauerhaft frei bleiben – niemand darf sie in proprietäre Produkte einschließen.
Für Unternehmen: Riskant bei proprietärer Entwicklung – der Copyleft-Effekt kann den gesamten eigenen Code betreffen.
Beispiele: GPL v2/v3, AGPL, LGPL (schwach)
🟢 Permissive Lizenzen
Grundprinzip: Nutzung fast ohne Einschränkungen – auch in proprietärer Software, auch kommerziell.
Bedingungen: Meist nur: Copyright-Hinweis im Code/Dokumentation behalten.
Für Unternehmen: Unkritisch – kann problemlos in geschlossene Software eingebunden werden.
Beispiele: MIT, Apache 2.0, BSD 2/3-Clause
Merkhilfe: Copyleft = „Wenn du es nimmst und teilst, teile auch zurück." Permissiv = „Nimm es, mach was du willst, aber nenn den Urheber." Der Name „Copyleft" ist ein Wortspiel mit „Copyright" – statt alle Rechte zu reservieren, werden alle Rechte weitergegeben.
2) Die wichtigsten Lizenzen im Detail
GPL v2 / GPL v3 – GNU General Public License
Jede Software, die GPL-Code enthält und weitergegeben wird, muss vollständig als Open Source unter GPL veröffentlicht werden. Das gilt für das gesamte kombinierte Werk – nicht nur den GPL-Teil. GPL v3 schließt zusätzlich Patent-Fallen aus (Tivoization-Klausel). Bekannte Projekte: Linux Kernel (GPL v2), GNU-Tools. Für proprietäre Software: sehr riskant – kann die gesamte Codebasis betreffen.
AGPL – Affero General Public License
Wie GPL, aber mit einer wichtigen Erweiterung: Selbst wenn die Software nur über ein Netzwerk (z.B. als SaaS/Webdienst) genutzt wird – ohne direkte Weitergabe – muss der Quellcode offengelegt werden. Das schließt die „SaaS-Lücke" der GPL. Bekannte Projekte: MongoDB (bis 2018), Nextcloud. Für Cloud-Dienste besonders kritisch.
LGPL – GNU Lesser General Public License
Entwickelt für Bibliotheken: Wenn eine LGPL-Bibliothek nur eingebunden (dynamisch gelinkt) wird, muss das einbindende Programm nicht unter LGPL stehen. Der Copyleft-Effekt gilt nur für Änderungen an der Bibliothek selbst. Vorteil: Bibliotheken können in proprietäre Software eingebunden werden. Bekannte Projekte: Qt (LGPL-Option), glibc.
MIT License
Eine der kürzesten und freiheitlichsten Lizenzen. Erlaubt: Nutzung, Kopieren, Modifizieren, Verkaufen, Einbinden in proprietäre Software – alles. Bedingung: Der Copyright-Hinweis und der Lizenztext müssen im Code und/oder in der Dokumentation erhalten bleiben. Bekannte Projekte: React, jQuery, Rails, Vue.js, .NET Core.
Apache License 2.0
Ähnlich wie MIT, aber mit wichtiger Ergänzung: explizite Patentlizenz. Wer Apache-2.0-Code nutzt, erhält automatisch eine Lizenz für alle Patente der Beitragenden. Das schützt Nutzer vor Patent-Fallen. Bedingung: Copyright-Hinweise erhalten, NOTICE-Datei weitergeben. Bekannte Projekte: Apache HTTP Server, Android (AOSP), Kubernetes, Elasticsearch.
BSD 2-Clause / 3-Clause
Sehr einfache Lizenzen. 2-Clause: Copyright-Hinweis erhalten, keine Werbung mit dem Projektnamen. 3-Clause: Zusätzlich darf der Name der Organisation nicht ohne Erlaubnis für Werbung genutzt werden. Bekannte Projekte: FreeBSD, OpenBSD, einige Python-Bibliotheken.
3) Praktische Entscheidungshilfe für Entwickler
| Situation | Empfehlung |
|---|---|
| Ich entwickle proprietäre Software und will Open-Source-Bibliotheken einbinden | Nur MIT, Apache 2.0 oder BSD verwenden – kein GPL/AGPL |
| Ich betreibe einen SaaS-Dienst auf Basis von Open-Source-Projekten | AGPL-Projekte vermeiden – der Quellcode des Dienstes müsste offengelegt werden |
| Ich möchte mein eigenes Open-Source-Projekt dauerhaft frei halten | GPL oder AGPL wählen – Copyleft verhindert proprietäre Abzweigungen |
| Ich will maximale Verbreitung meiner Bibliothek, auch in proprietären Produkten | MIT oder Apache 2.0 – niedrigste Eintrittshürde |
Zusammenfassung
Open-Source-Lizenzen teilen sich in Copyleft (GPL, AGPL, LGPL) und permissiv (MIT, Apache 2.0, BSD). Copyleft zwingt zur Offenlegung des eigenen Codes bei Weitergabe – GPL für Programme, AGPL schließt auch SaaS ein, LGPL nur für Bibliotheksänderungen. Permissive Lizenzen erlauben fast alles, fordern nur die Nennung des Urhebers. Für proprietäre Entwicklung: ausschließlich permissive Lizenzen verwenden. Für Lizenz-Management im Unternehmen: Lizenz-Audit & Software Asset Management.