Copyleft verständlich erklärt

Copyleft ist eines der faszinierendsten und gleichzeitig meist missverstandenen Konzepte im Open-Source-Recht. Bei SecuraPoint treffen wir häufig auf Unternehmen, die Copyleft-Lizenzen pauschal ablehnen oder umgekehrt unkritisch einsetzen, ohne die Konsequenzen für ihre proprietäre Software oder SaaS-Angebote zu bedenken. Deshalb möchten wir in diesem Blogartikel einen detaillierten Blick auf die Grundlagen, Hintergründe und die praktische Bedeutung von Copyleft werfen. Außerdem geben wir konkrete Tipps und Beispiele, wie man in Projekten damit umgehen sollte.

Was bedeutet Copyleft?

Der Begriff Copyleft wurde in den 1980er-Jahren von Richard Stallman geprägt. Er ist kein Gegensatz zu Copyright, sondern basiert direkt darauf. Das Copyright gibt dem Urheber das exklusive Recht, sein Werk zu vervielfältigen, zu verbreiten oder zu lizenzieren. Copyleft dreht den Spieß um und nutzt dieses Recht, um sicherzustellen, dass Software immer frei bleibt und Verbesserungen nicht in proprietäre Mauern eingeschlossen werden.

Ein bekanntes Beispiel dafür ist der Linux Kernel, der unter der GPL-2.0 steht. Ohne Copyleft könnten Hersteller von Embedded-Geräten den Kernel modifizieren und nur ihre Binärversion verteilen, ohne je den Sourcecode freizugeben. Durch die GPL müssen sie den Sourcecode jedoch zugänglich machen.

Copyright in Adaptationen

Wann immer ein Entwickler ein fremdes Werk unter einer Lizenz anpasst, entsteht ein eigenes, abhängiges Urheberrecht. Dieses “Copyright in der Adaption” hat zwei Seiten:

• Es schützt die schöpferische Leistung des Anpassenden.
• Es zwingt dazu, weiterhin die Lizenzbedingungen des Originals einzuhalten.

So entsteht eine Kette von Lizenzverpflichtungen. Bei Copyleft bedeutet das, niemand darf plötzlich andere oder restriktivere Bedingungen auferlegen. Genau das macht es für große Software-Ökosysteme oft einfacher. Anstatt sich durch zig unterschiedliche Lizenzen wühlen zu müssen, gilt bei Copyleft immer dieselbe Lizenz.

Starkes vs. schwaches Copyleft

In der Praxis wird Copyleft meist in zwei Kategorien unterteilt:

Starkes Copyleft

Beispiele: GNU GPL-2.0, GPL-3.0, AGPL-3.0

Diese Lizenzen verlangen, dass alle abgeleiteten Werke unter der gleichen Lizenz veröffentlicht werden müssen. Wenn also eine proprietäre Anwendung statisch mit GPL-Code linked, muss die gesamte Anwendung inklusive Sourcecode offengelegt werden.

Beispiele:

• Linux Kernel (GPL-2.0)
• GCC Compiler (GPL-3.0)
• Mattermost (AGPL-3.0 für Netzwerke)

Schwaches Copyleft

Beispiele: LGPL-2.1, LGPL-3.0, Mozilla Public License (MPL-2.0), Eclipse Public License (EPL-2.0)

Hier muss nur der Code offengelegt werden, der direkt von der Copyleft-Komponente abgeleitet wurde. Dynamisches Linking ist erlaubt, ohne dass die gesamte proprietäre Software GPL werden muss.

Beispiele:

• glibc (LGPL)
• Firefox (MPL)
• Eclipse IDE (EPL)

Multilicensing: OR und AND

Viele Projekte setzen auf Multilicensing, um es Unternehmen und Entwicklern einfacher zu machen. Sie bieten z. B. „GPL OR MIT“ oder „GPL OR kommerziell“ an. Bei „OR“ darf man wählen. Bei „AND“ müssen alle Bedingungen gleichzeitig erfüllt werden.

Praxisbeispiele:

• jQuery: MIT OR GPL
• Qt: GPL OR kommerziell
• OpenSSL: Apache OR OpenSSL License

Das muss im Projekt dokumentiert werden. In Compliance-Reports, NOTICE- oder THIRD_PARTY_LICENSES-Files gehört ein Hinweis, unter welcher Lizenz man das Paket konkret nutzt und was die Originallizenz war.

Risiken und Mythen rund um Copyleft

Viele Unternehmen fürchten Copyleft, weil es angeblich “viral” oder “infektiös” sei. Das ist aber falsch. Es zwingt niemanden unfreiwillig in eine Lizenz. Es wirkt nur dann, wenn man sich aktiv entscheidet, Copyleft-Code zu nutzen und diesen zu verändern oder zu kombinieren.

Typische Fehler:

• Statisches Linking von GPL-Bibliotheken mit proprietärem Code.
• Keine klare Trennung bei Build-Systemen.
• Fehlende Dokumentation der Lizenzentscheidung bei Multilicensing.
• Keine Transparenz, welche Komponenten, mit welchen Lizenzen verwenden werden.

Use Cases: Wie wirkt sich Copyleft praktisch aus?

Embedded Linux

Ein Hersteller nutzt den Linux Kernel (GPL-2.0) und muss daher den Quellcode der Kernel-Änderungen auf Anfrage bereitstellen.

SaaS mit AGPL

Ein Start-up setzt Mattermost (AGPL-3.0) ein. Nach der AGPL muss es auch den Server-Sourcecode veröffentlichen, falls dieser angepasst wurde.

Desktop-App mit LGPL-Library

Ein Entwickler nutzt FFmpeg unter LGPL und linked dynamisch. Er muss nur sicherstellen, dass die Nutzer FFmpeg austauschen können.

Unternehmensrichtlinien: Wann ist was erlaubt?

Eine Copyleft-Policy sollte klar festlegen:

• Welche Lizenzen sind stark, welche schwach?
• Wann dürfen Copyleft-Komponenten genutzt werden?
• Welche Abteilungen müssen prüfen (z. B. Legal, Engineering)?
• Wie wird dokumentiert?
• Wer darf entscheiden?

Das schützt IP und verhindert, dass Copyleft-Pflichten versehentlich ausgelöst werden.

Fazit: Copyleft souverän managen

Copyleft ist weder Fluch noch Virus, sondern ein mächtiges Werkzeug, das Freiheit garantiert, wenn man weiß, wie es funktioniert. Wer eine klare Policy hat und sauber dokumentiert, kann Copyleft-Software gewinnbringend einsetzen, ohne unangenehme Überraschungen. So können Unternehmen Open Source selbstbewusst und rechtskonform nutzen und ihre digitale Souveränität sichern.