Open-Source-Lizenz für Plugins wählen: GPL, MIT oder Apache?

Für ein WordPress-Plugin wählen Sie eine GPL-kompatible Lizenz, meist „GPLv2 or later“, weil das Plugin-Verzeichnis das verlangt und WordPress selbst unter der GPL steht. Für Browser-Erweiterungen, VS-Code-Extensions und die meisten JavaScript-Projekte ist MIT die gängige Wahl: kurz, verständlich und sehr freizügig. Apache 2.0 eignet sich, wenn Sie zusätzlich Patentfragen klar regeln wollen. Entscheidend ist die Frage, ob Weiterentwicklungen anderer offen bleiben müssen. Dann führt der Weg zur GPL.

Die Grundfrage: freizügig oder Copyleft?

Open-Source-Lizenzen lassen sich grob in zwei Familien teilen:

• Freizügige Lizenzen (permissive) wie MIT, BSD oder Apache 2.0 erlauben fast alles, auch die Nutzung in geschlossener, kommerzieller Software. Verlangt wird im Kern nur, dass Lizenz- und Urheberhinweis erhalten bleiben.
• Copyleft-Lizenzen wie die GPL verlangen, dass abgeleitete Werke bei der Weitergabe ebenfalls unter der GPL stehen und der Quellcode verfügbar ist. Wer Ihren Code verbessert und verbreitet, muss die Verbesserungen also offenlegen.

Keine Familie ist besser. Freizügige Lizenzen fördern maximale Verbreitung, Copyleft schützt davor, dass Ihre Arbeit in geschlossenen Produkten verschwindet.

Die drei häufigsten Lizenzen im Vergleich

MIT

Die MIT-Lizenz besteht aus wenigen Absätzen. Sie erlaubt Nutzung, Veränderung, Verbreitung und Verkauf, verlangt den Erhalt des Hinweises und schließt die Haftung weitgehend aus. Für kleine Add-ons, bei denen Sie keine Bedingungen stellen möchten, ist sie meist die einfachste Wahl.

Apache 2.0

Apache 2.0 ist ebenfalls freizügig, aber ausführlicher. Wer beiträgt, räumt eine Patentlizenz für seine Beiträge ein. Wer wegen des Codes eine Patentklage erhebt, verliert diese Lizenz. Außerdem müssen geänderte Dateien als geändert gekennzeichnet werden. Für Projekte mit vielen Beitragenden oder in Unternehmen ist das ein Vorteil.

GPL

Die GNU General Public License gibt es vor allem in den Versionen 2 und 3. Die Angabe „oder später“ (or later) erlaubt Nutzern, auch eine spätere Version der Lizenz anzuwenden, und erleichtert damit die Kombination mit anderen Projekten. Wichtig ist der Begriff der Weitergabe: Die Pflichten der GPL greifen, wenn Sie Software verbreiten. Wer ein Plugin nur auf dem eigenen Server nutzt, muss nichts offenlegen. Für Webdienste gibt es mit der AGPL eine Variante, die auch die Bereitstellung über ein Netzwerk erfasst.

Was die Plattformen verlangen

Beim WordPress-Verzeichnis ist die Lizenz ein harter Prüfpunkt. Wie die Einreichung abläuft und wo die Lizenz in der readme.txt und im Plugin-Header steht, beschreibt der Beitrag WordPress-Plugin im offiziellen Plugin-Verzeichnis veröffentlichen. Grundlagen zum Aufbau von Plugins finden Sie im Bereich WordPress-Plugins.

Kompatibilität: wenn Sie fremden Code einbinden

Kaum ein Add-on kommt ohne Bibliotheken aus. Die Lizenz Ihres Projekts muss mit allen eingebundenen Lizenzen vereinbar sein.

• MIT oder BSD in einem GPL-Projekt: in der Regel unproblematisch. Die Hinweise der Bibliothek bleiben erhalten.
• Apache 2.0 in einem GPL-Projekt: mit GPLv3 vereinbar, mit GPLv2 ohne „oder später“ nach Auffassung der Free Software Foundation nicht. Ein weiterer Grund für die Angabe „or later“.
• GPL-Bibliothek in einem MIT-Projekt: Das Gesamtwerk muss bei der Weitergabe unter die GPL. Wollen Sie MIT bleiben, brauchen Sie eine andere Bibliothek.
• Bibliothek ohne Lizenz: nicht verwenden, solange die Rechte nicht geklärt sind.

Ein Paketmanager listet die Lizenzen Ihrer Abhängigkeiten. Werkzeuge zur Lizenzprüfung zeigen Konflikte, bevor das Paket im Store landet.

Bilder, Schriften und Symbole nicht vergessen

Die Lizenz betrifft nicht nur Code. Symbole, Schriften, Bilder und Übersetzungen haben eigene Rechte. Das WordPress-Verzeichnis verlangt auch für mitgelieferte Grafiken GPL-kompatible Bedingungen. Prüfen Sie bei jedem Symbolsatz und jeder Schrift die Lizenz und dokumentieren Sie die Herkunft, etwa in einer Datei CREDITS oder im Abschnitt Danksagungen der README.

Häufige Missverständnisse

• „Auf GitHub ist alles frei.“ Öffentlich sichtbarer Code ist nicht automatisch nutzbar. Ohne Lizenz gilt das Urheberrecht mit allen Rechten beim Urheber.
• „MIT heißt, ich muss nichts beachten.“ Auch MIT verlangt, dass der Lizenz- und Urheberhinweis in Kopien erhalten bleibt. In gebündeltem Code geht er leicht verloren, wenn der Build Kommentare entfernt.
• „GPL verbietet kommerzielle Nutzung.“ Das Gegenteil ist richtig. Die GPL erlaubt Verkauf und kommerzielle Nutzung, verlangt aber bei Weitergabe die Offenlegung des Quellcodes.
• „Eine eigene Lizenz ist flexibler.“ Selbst formulierte Lizenzen sind oft unklar und schrecken Beitragende und Unternehmen ab. Bekannte Lizenzen sind geprüft, verstanden und von Werkzeugen erkennbar.
• „Die Store-Bedingungen ersetzen die Lizenz.“ Nutzungsbedingungen eines Stores regeln das Verhältnis zwischen Ihnen und dem Store. Was andere mit Ihrem Code tun dürfen, regelt allein die Lizenz.

Lizenz und Marke sind zweierlei

Eine Open-Source-Lizenz regelt den Code, nicht den Namen. Auch wenn jeder Ihren Code unter MIT weiterverwenden darf, darf er sein Produkt nicht so nennen, dass es mit Ihrem verwechselt wird. Umgekehrt gilt das ebenso: Namen von Plattformen wie WordPress, Firefox oder Chrome sind geschützte Marken. Viele Stores verbieten, sie so in den Namen eines Add-ons aufzunehmen, dass ein offizielles Produkt vermutet wird. Formulierungen wie „für Firefox“ sind meist zulässig, ein Name, der mit der Marke beginnt, oft nicht. Prüfen Sie die Markenrichtlinien der jeweiligen Plattform.

Lizenz richtig einbinden

1. Lizenzdatei anlegen: Legen Sie den vollständigen, unveränderten Lizenztext als LICENSE oder LICENSE.txt ins Hauptverzeichnis. Bei MIT ergänzen Sie Jahr und Rechteinhaber.
2. Kennung im Manifest: Tragen Sie die Lizenz maschinenlesbar ein, etwa die SPDX-Kennung "license": "MIT" in der package.json. Bei WordPress-Plugins gehören die Felder License: GPLv2 or later und License URI in den Plugin-Header.
3. Kopfzeile in Dateien: Optional, aber hilfreich: eine kurze Zeile wie SPDX-License-Identifier: GPL-2.0-or-later am Dateianfang.
4. Drittanbieter dokumentieren: Listen Sie eingebundene Bibliotheken mit ihren Lizenzen auf. Build-Werkzeuge können diese Hinweise automatisch sammeln.
5. Beiträge regeln: Wer Beiträge von außen annimmt, legt in der Datei CONTRIBUTING fest, dass sie unter der Projektlizenz stehen.

Entscheidungshilfe

• Sie bauen ein WordPress-Plugin? GPLv2 or later.
• Sie wollen maximale Verbreitung ohne Bedingungen? MIT.
• Ihr Projekt ist groß, mit vielen Beitragenden oder im Unternehmensumfeld? Apache 2.0.
• Verbesserungen sollen immer offen bleiben? GPLv3 oder later.
• Sie wollen später Geld verdienen? Die Lizenz schließt das nicht aus, beeinflusst aber das Modell. Mehr dazu im Beitrag Add-ons monetarisieren.