Open Source Lizenzen¶

Siehe auch

Offizielle Dokumentation

Die Lizenz einer Software entscheidet, welche Pflichten beim Einsatz, beim Ändern und vor allem beim Weitergeben entstehen. Solange Code nur intern läuft, spielt sie kaum eine Rolle. Sobald eine Software an Dritte weitergegeben, in ein eigenes Produkt eingebaut oder als Dienst über das Netz angeboten wird, bestimmt die Lizenz, ob der Quellcode offengelegt werden muss und unter welcher Lizenz das Ergebnis stehen darf.

Open-Source-Lizenzen lassen sich entlang einer einzigen Achse einordnen: wie stark sie verlangen, dass Änderungen und abgeleitete Werke wieder offen bleiben. Das reicht von permissiven Lizenzen ohne nennenswerte Pflichten bis zu starkem Copyleft, das die Offenlegung erzwingt.

Permissiv vs. Copyleft¶

Permissive Lizenzen (MIT, BSD, Apache 2.0, Boost) erlauben Nutzung, Änderung und Weitergabe nahezu ohne Auflagen. Einzige Pflicht ist meist, den Lizenz- und Copyright-Hinweis zu erhalten. Der Code darf in proprietäre Produkte übernommen werden, ohne dass diese offengelegt werden müssen.

The Unlicense geht einen Schritt weiter und widmet den Code der Public Domain. Es gibt keine Bedingungen, nicht einmal die Pflicht, einen Hinweis zu behalten.

Schwaches Copyleft (LGPL, MPL 2.0) verlangt die Offenlegung nur für den lizenzierten Teil selbst: Änderungen an einer LGPL-Bibliothek oder an einzelnen MPL-Dateien müssen unter derselben Lizenz offen bleiben, das umgebende Programm darf proprietär sein. Die LGPL ist genau dafür gedacht, eine Bibliothek in proprietäre Software einzubinden, ohne diese ebenfalls offenlegen zu müssen.

Starkes Copyleft (GPL, AGPL) erfasst das gesamte abgeleitete Werk: Wird ein GPL-Programm weitergegeben, muss der vollständige Quellcode unter der GPL verfügbar sein. Die AGPL erweitert das auf die Nutzung über das Netz - wer AGPL-Software als Dienst anbietet, ohne ein Binary weiterzugeben, muss den Quellcode trotzdem herausrücken. Diese Netzwerk-Klausel schliesst die „SaaS-Lücke“ der GPL, bei der ein reiner Webdienst die Offenlegung nie auslöst.

Die Netzwerk-Klausel verbietet SaaS nicht. AGPL-Software wie Nextcloud darf als Dienst betrieben werden; nur muss den Nutzern der (gegebenenfalls geänderte) Quellcode zugänglich sein. Betreibt man die Software unverändert, ist diese Pflicht bereits erfüllt, weil der Quellcode ohnehin öffentlich vorliegt.

Ein Patent-Grant (Spalte „Patentschutz“) bedeutet praktisch: Wer den Code herausgibt, verspricht zugleich, niemanden wegen Patenten zu verklagen, die in diesem Code stecken. Bei MIT, BSD und Boost fehlt dieses Versprechen - theoretisch könnte ein Beitragender später ein Patent auf eine im Code verwendete Technik geltend machen und Lizenzgebühren verlangen. In der Praxis selten, aber Apache 2.0, MPL und die (A/L)GPLv3 schliessen dieses Risiko ausdrücklich aus; die ältere GPLv2 noch nicht.

Vergleich¶

Die Spalten verdichten die Permissions- und Conditions-Daten von choosealicense.com auf die im Betrieb entscheidenden Fragen. Die Beispiele stammen aus dem hier dokumentierten Software-Stack, ihre Lizenz wurde gegen das jeweilige Repository geprüft.

Lizenz	Veröffentlicht	Typ	Quelle offenlegen	Gleiche Lizenz (Copyleft)	Patentschutz	Netzwerk-Klausel	Beispiele aus dem Stack
The Unlicense	2010	Public Domain	nein	nein	nein	nein	SQLite
MIT	Ende 1980er	permissiv	nein	nein	nein	nein	React, Node.js
BSD	1990 (3-Clause 1999)	permissiv	nein	nein	nein	nein	Flask
Boost 1.0	2003	permissiv	nein	nein	nein	nein	-
Apache 2.0	2004	permissiv	nein	nein	ja	nein	Apache HTTPD, OpenSearch
MPL 2.0	2012	schwaches Copyleft	ja (geänderte Dateien)	ja (geänderte Dateien)	ja	nein	Collabora
LGPLv3	2007	schwaches Copyleft	ja (Bibliotheksteil)	ja (Bibliotheksteil)	ja	nein	-
GPLv2	1991	starkes Copyleft	ja	ja (gesamtes Werk)	nein	nein	MariaDB, WordPress
GPLv3	2007	starkes Copyleft	ja	ja (gesamtes Werk)	ja	nein	Ansible, Netdata
AGPLv3	2007	starkes Copyleft	ja	ja (gesamtes Werk)	ja	ja	Nextcloud, Mastodon, Grafana

Unabhängig von der Lizenz schliessen alle hier genannten jegliche Gewährleistung und Haftung aus.

SPDX-Identifier¶

SPDX (Software Package Data Exchange) ist ein Standard, der jeder Lizenz eine kurze, eindeutige Kennung gibt: MIT, Apache-2.0, GPL-3.0-or-later, AGPL-3.0, Unlicense. Statt „GNU General Public License, Version 3 oder neuer“ auszuschreiben, genügt GPL-3.0-or-later.

Werkzeuge brauchen eine maschinenlesbare Angabe, keine Fliesstext-Lizenzdatei. Dependency-Scanner, SBOM-Generatoren (Software Bill of Materials) und die Lizenz-Erkennung von GitHub lesen den SPDX-Identifier aus, um Lizenzkonflikte in einem Software-Stack aufzuspüren. Auch der Header SPDX-License-Identifier: MIT am Anfang einer Quelldatei stammt aus diesem Standard und macht die Lizenz pro Datei eindeutig.

Die Lizenz eines GitHub-Repos lässt sich direkt abfragen:

gh api repos/<owner>/<repo>/license --jq '.license.spdx_id'

Liefert das NOASSERTION, konnte das Tool die Lizenz keinem SPDX-Identifier eindeutig zuordnen - meist, weil die LICENSE-Datei mehrere Lizenzen bündelt oder eine Eigenlizenz enthält. Dann hilft nur der Blick in die Datei selbst.

Lizenz der Linuxfabrik¶

Die Linuxfabrik veröffentlicht ihre eigenen Open-Source-Produkte unter The Unlicense, etwa die Monitoring-Plugins, LFOps und die gemeinsame Python-Bibliothek. Der Grund ist Reibungsfreiheit: Kunden und Dritte dürfen den Code ohne jede Auflage übernehmen, anpassen und weitergeben, auch in geschlossene oder kommerzielle Umgebungen. Es entfällt die Pflicht, Hinweise mitzuführen, und es gibt keine Copyleft- oder Kompatibilitätsfragen, wenn der Code mit anders lizenzierter Software kombiniert wird. Für Werkzeuge, die möglichst breit genutzt werden sollen, ist das die einfachste Grundlage.

Die einzige Ausnahme ist FirewallFabrik. FirewallFabrik steht unter der GPLv2, weil es GPL-lizenzierten Fremdcode einbindet. Starkes Copyleft färbt ab: Wer GPL-Code übernimmt, muss das gesamte abgeleitete Werk wieder unter die GPL stellen. The Unlicense wäre damit nicht vereinbar.