Open Source Lizenzen im Überblick

Die Welt der Open Source Lizenzen ist vielfältig und komplex. In diesem Beitrag erkläre ich die wichtigsten Lizenztypen, zeige viele konkrete Beispiele aus gängigen Programmiersprachen, gehe auf das oft vergessene Thema Multilicensing ein und beleuchte die oft übersehenen Acknowledgement Requirements. Damit liefert dieser Artikel eine umfassende Orientierung, warum Open Source Compliance so wichtig ist und welche Fallstricke es gibt.

Permissive Lizenzen

Permissive Lizenzen erlauben fast alles. Du darfst den Code verwenden, ändern, kombinieren und sogar in proprietäre Software integrieren. Lediglich die Urheber und der ursprüngliche Lizenztext müssen genannt werden. Sie sind daher in Unternehmen und bei Softwareentwicklern beliebt.

Beispiele für permissive Lizenzen

• MIT License
• BSD (2-Clause, 3-Clause)
• ISC
• Apache License 2.0 (inkl. Patentschutz)
• Zlib
• Boost Software License
• Unlicense
• Python Software Foundation License
• Artistic License 2.0
• WTFPL

Typische Pakete und Projekte

Was gibt es bei permissiven Lizenzen zu beachten?

Permissive Lizenzen verpflichten dazu, den ursprünglichen Urheber und Lizenztext beizubehalten. Bei Apache ist außerdem ein NOTICE-File nötig. Es gibt keine Pflicht, Änderungen zu veröffentlichen.

Copyleft Lizenzen

Copyleft sorgt dafür, dass Verbesserungen nicht wieder proprietär gemacht werden. Wer den Code nutzt und daraus abgeleitete Software erstellt, muss diese wieder unter die gleiche Lizenz stellen.

Beispiele für Copyleft Lizenzen

• GPL-2.0, GPL-3.0 (starkes Copyleft)
• AGPL-3.0 (Netzwerk-Copyleft)
• LGPL-2.1, LGPL-3.0 (schwächer)
• EPL-2.0
• CDDL, EUPL, CeCILL, RPL, SSPL

Starke vs. schwache Copyleft Lizenzen

Starkes Copyleft (z. B. GPL, AGPL) verpflichtet dazu, alle abgeleiteten Werke unter derselben Lizenz zu veröffentlichen. Wird also GPL-Code mit proprietärem Code statisch verlinkt, “infiziert” dies die ganze Software. Beispiele sind der Linux Kernel (GPL-2.0) oder GIMP (GPL-3.0). AGPL erweitert das auf Netzwerke: auch Webservices, die den Code nutzen, müssen den Quellcode offenlegen.

Schwaches Copyleft (z. B. LGPL, MPL) verpflichtet nur für Modifikationen an der eigentlichen Library. Dynamisches Linking oder Nutzung einzelner Module führt nicht dazu, dass die gesamte Software GPL-artig offengelegt werden muss. Beispiele sind glibc (LGPL) oder Mozilla Firefox (MPL-2.0, das nur geänderte Dateien betrifft).

Damit wird klarer, warum viele Firmen bewusst LGPL- oder MPL-lizenzierte Libraries verwenden, um Integration zu ermöglichen, ohne das Gesamtprojekt unter Copyleft stellen zu müssen.

Typische Projekte

Multilicensing und Dokumentationspflichten

Viele Projekte bieten mehrere Lizenzen an, was oft als “Multilicensing” bezeichnet wird. Nutzer können dann selbst wählen, unter welchen Bedingungen sie den Code verwenden. Das vermeidet Konflikte mit Copyleft, weil man z. B. bewusst eine permissive Variante wählt.

Beispiele für Multilicensing

• Qt (GPL + kommerziell)
• jQuery (MIT OR GPL)
• OpenSSL (Apache OR OpenSSL License)
• CKEditor (GPL OR LGPL OR MPL)
• Firefox (MPL OR GPL OR LGPL)
• LibreOffice (MPL OR LGPL)
• MathJax (Apache OR GPL)
• Boost (Boost License, teils mit MIT-ähnlichen Optionen)
• Rocket.Chat (MIT OR AGPL)
• Mongoose (GPL OR kommerziell)

Diese Multilicense-Formeln werden oft mit „OR“ oder „AND“ dargestellt. “OR” bedeutet, man kann frei wählen. “AND” heißt, alle Bedingungen müssen erfüllt werden. Gerade bei “OR” ist es wichtig, zu dokumentieren, für welche Lizenz man sich entschieden hat, damit bei späteren Audits oder rechtlichen Fragen klar ist, unter welchen Bedingungen die Nutzung erfolgt.

Acknowledgement Requirements

Viele Lizenzen – auch die permissiven – verpflichten zur Nennung. Apache verlangt ein NOTICE-File. GPL schreibt Copyright- und Haftungshinweise vor. Typisch sind:

• LICENSE-File mit allen Lizenztexten
• NOTICE oder THIRD_PARTY_LICENSES mit Urheberangaben
• Anzeige in der App, z. B. „About“-Dialog oder Imprint.

Das zeigt Respekt gegenüber Open Source Autoren und schützt rechtlich.

Fazit

Open Source Lizenzen sind ein mächtiges Werkzeug, um Innovation und Zusammenarbeit zu fördern. Gleichzeitig sind sie aber kein rechtsfreier Raum und erfordern sorgfältige Beachtung. Wer eine nachhaltige Compliance-Strategie verfolgt, sollte sich daher über die Unterschiede klar sein:

Permissive Lizenzen sind unkompliziert und stellen nur minimale Anforderungen, meist die Namensnennung der Urheber. Sie ermöglichen die Integration in proprietäre Produkte ohne weitreichende Verpflichtungen.

Copyleft Lizenzen sorgen dafür, dass Weiterentwicklungen und abgeleitete Werke wieder der Allgemeinheit zugutekommen. Je nach Stärke (GPL, AGPL vs. LGPL, MPL) kann das erhebliche Auswirkungen auf die Lizenzierung des gesamten Produkts haben.

Multilicensing eröffnet flexible Wege, da es Entwicklern und Unternehmen erlaubt, eine Lizenz zu wählen, die zu ihrem Geschäftsmodell passt. Wichtig ist dabei, die gewählte Lizenz auch klar zu dokumentieren.

Acknowledgement Requirements stellen sicher, dass die Leistungen der ursprünglichen Entwickler anerkannt werden und geben rechtliche Sicherheit. Ein gepflegtes NOTICE- oder THIRD_PARTY-LICENSES-File ist dafür unverzichtbar.

Wer diese Grundprinzipien versteht und dokumentiert umsetzt, kann Open Source Software souverän und rechtskonform einsetzen.