Autor: lortner

Dies ist Teil 10 und der Abschluss der Lese-Reihe „GPL & WordPress”. ← Zurück zu Teil 9 | Zur Übersicht aller Teile

Rückblick auf eine komplexe Reihe

In neun Teilen haben wir die GNU General Public License aus allen relevanten Winkeln beleuchtet: ihre Entstehung und philosophische Basis, die historische Verbindung mit WordPress, die Kollisionen mit kommerziellen AGBs, die Veröffentlichungspflichten, die Grenzen des Schutzes, Marken- und Copyrightfragen, legale Umgehungsstrategien und die echten Interessenskonflikte zwischen Entwicklern und Community. Es wird Zeit für ein klares Fazit.

Was die GPL regelt – und was nicht

Die wichtigste Erkenntnis dieser Reihe ist die Notwendigkeit, präzise zu unterscheiden:

• GPL: Regelt die Freiheiten und Pflichten rund um Software-Code. PHP-Code für WordPress-Plugins und -Themes ist GPL-pflichtig, wenn er WordPress-Kernfunktionen verknüpft. Die Veröffentlichungspflicht gilt bei Verbreitung, nicht bei interner Nutzung.
• Fonts, Bilder, Assets: Stehen unter eigenen Lizenzen und sind von der GPL des umgebenden Codes weitgehend unberührt. Ein GPL-Theme macht keine enthaltene proprieätere Font frei.
• Services, Updates, Support: Dienstleistungen rund um GPL-Software können kommerziell und lizenzpflichtig sein. Die GPL schützt den Code, nicht den Zugang zu Diensten.
• Marken: Das Wort „WordPress” ist eine Wortmarke. GPL-Konformität erlaubt keine Markenverletzung. Beide Rechtsbereiche sind vollständig getrennt.
• AGBs: Können die durch die GPL gewährten Code-Rechte nicht wirksam einschränken. Sie können jedoch Serviceleistungen separat regeln.

Die kritische Bilanz: Was hat die GPL geleistet?

Lassen wir die Zahlen sprechen: WordPress betreibt über 40 % des gesamten Webs. Über 60.000 kostenlose Plugins sind im offiziellen Verzeichnis. Millionen von Websites – von Vereinen über Schulen bis zu Konzernen – nutzen professionelle Werkzeuge ohne Lizenzkosten. Diese Demokratisierung des Webs wäre ohne die GPL nicht möglich gewesen.

Gleichzeitig ist ein milliardenschweres kommerzielles Ökosystem entstanden: Hosting-Anbieter, Plugin-Entwickler, Agenturen – all das gedeiht auf dem GPL-Fundament. Die GPL hat nicht verhindert, dass WordPress wirtschaftlich relevant wurde. Sie hat es ermöglicht.

Die kritische Einschränkung: Was die GPL nicht löst

Ehrlichkeit verlangt auch den Blick auf die Grenzen. Die GPL löst keine Fragen der nachhaltigen Finanzierung von Open-Source-Entwicklung. Sie verhindert nicht, dass große Unternehmen massiv von freier Community-Arbeit profitieren, ohne adäquat beizutragen. Sie schützt nicht automatisch vor Lock-in durch Marken oder proprietäre Infrastruktur. Und sie ist kein Schutz gegen das Ausbluten von Entwickler-Communitys durch wirtschaftlichen Druck.

Unser Fazit: GPL und freier Code sind das richtige Fundament

Nach sorgfältiger Abwägung beider Seiten ist unsere Position klar: Die GPL und das Prinzip des freien Codes sind für das WordPress-Ökosystem das richtige Fundament – mit wichtigen Nuancen.

Plugins und Themes sind abgeleitete Werke von WordPress. Sie bauen auf jahrelanger Community-Arbeit auf, nutzen eine Infrastruktur, die durch tausende unentgeltliche Beiträge entstanden ist. Diese Nutzung verpflichtet. Die GPL ist der formale Ausdruck dieser Verpflichtung – und sie ist fair.

Gleichzeitig gilt: Nicht alles muss frei sein. Proprietäre Fonts, custom Grafiken, Demo-Content, Lizenzkeys für Services – all das kann und darf separat geschützt werden. Die GPL schreibt keine Totalfreiheit vor; sie schreibt Code-Freiheit vor. Das ist ein wichtiger Unterschied, der in der Praxis oft vergessen wird.

Wer ein WordPress-Plugin kauft, darf dessen PHP-Code nutzen, weitergeben und modifizieren. Er darf nicht die beigelegten proprietären Assets weitergeben, den Support des Anbieters in Anspruch nehmen ohne aktive Lizenz oder den Namen des Anbieters für eigene Produkte missbrauchen. Das ist kein Widerspruch – das ist ein ausgewogenes System.

Empfehlungen für die Praxis

Für Entwickler: Akzeptiert die GPL als Fundament. Baut euer Geschäftsmodell auf Services, Assets, Support und Marke – nicht auf Code-Kontrolle. Das Ökosystem belohnt Qualität und Verlässlichkeit, nicht Verschlossenheit. Kennzeichnet eure Lizenzen transparent: Was ist GPL, was steht unter eigener Lizenz? Nutzer haben ein Recht auf diese Klarheit.

Für Nutzer und Agenturen: Versteht, dass GPL nicht „alles kostenlos” bedeutet. Respektiert die Arbeit von Entwicklern. Kauft Lizenzen – nicht weil ihr müsst, sondern weil ihr damit ein Ökosystem unterstützt, das auch euch nützt. Verwendet keine Nulled Plugins: Sie sind nicht nur ethisch fragwürdig, sondern echte Sicherheitsrisiken.

Für das WordPress-Ökosystem insgesamt: Die GPL ist kein Problem, das gelöst werden muss. Sie ist eine Entscheidung, die verteidigt werden sollte – mit Augenmaß, Pragmatismus und dem Verständnis, dass freier Code und wirtschaftlicher Erfolg kein Widerspruch sind, sondern sich gegenseitig bedingen.

Alle Teile der Reihe im Überblick

• Teil 1: Was ist die GNU General Public License überhaupt?
• Teil 2: Wie WordPress zur GPL-Plattform wurde
• Teil 3: Wenn GPL auf kommerzielle AGBs trifft
• Teil 4: Die Code-Veröffentlichungspflicht
• Teil 5: Themes und Plugins unter der GPL
• Teil 6: Was die GPL nicht erfasst – Fonts, Assets, proprietäre Inhalte
• Teil 7: Wortmarken, Copyright und der Name „WordPress”
• Teil 8: GPL-Schlupflöcher und kommerzielle Graubereiche
• Teil 9: Entwickler vs. Community – die kritische Bilanz
• Teil 10: Zusammenfassung und Fazit – Freier Code als Fundament (dieser Beitrag)

Teil 9 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 8

Zwei legitime Perspektiven – ein ungelöster Konflikt

Diese Lese-Reihe wäre unvollständig ohne eine ehrliche Betrachtung beider Seiten. Die GPL-Debatte im WordPress-Ökosystem ist keine Geschichte von Gut gegen Böse. Es sind zwei legitime Interessenslagen, die in struktureller Spannung zueinanderstehen – und diese Spannung verdient Respekt statt Vereinfachung.

Die Position der Entwickler: Arbeit hat ihren Wert

Professionelle WordPress-Entwickler, die Plugins oder Themes verkaufen, bringen oft Jahre an Entwicklungsarbeit, Design-Expertise und Supportaufwand in ihre Produkte ein. Ihre Kernargumente gegen eine strenge GPL-Auslegung sind:

• Wirtschaftliche Realität: Freie Weitergabe von mühsam entwickeltem Code zerstört Geschäftsmodelle. Wenn ein Premium-Plugin für 59 Euro auf Nulled-Sites kostenlos verfügbar ist, entfallen Einnahmen, die für Weiterentwicklung und Bugfixes nötig wären.
• Qualitätsverlust durch Kommerzialisierungsbarriere: Wenn professionelle Entwickler sich nicht mehr finanzieren können, verlässt Talent das Ökosystem. Die Qualität freier Alternativen sinkt.
• Rechtliche Unsicherheit: Die Frage, ob JavaScript oder CSS wirklich GPL-pflichtig sind, ist nicht höchstrichterlich entschieden. Entwickler operieren in einem Graubereich, der für die Geschäftsplanung ungünstig ist.
• Copyleft als Zwang: Die GPL zwingt Entwickler, ihre Innovationen sofort zu teilen – ohne Möglichkeit einer Schonfrist oder geschützten Entwicklungsphase.

Die Position der Community und der GPL-Befürworter

Auf der anderen Seite stehen überzeugte GPL-Vertreter und die breite Nutzer-Community:

• WordPress ist ein Gemeinschaftsgut: Das Projekt wurde durch tausende unbezahlte Beiträge aufgebaut. Wer auf diesem Fundament Geld verdient, hat eine ethische Verpflichtung zur Offenheit.
• GPL fördert Innovation: Freier Code bedeutet, dass jeder auf den Schultern anderer stehen kann. Das beschleunigt Innovation statt sie zu bremsen.
• Abhängigkeit und Lock-in: Proprietäre Plugins schaffen Abhängigkeiten. Wenn ein Anbieter seinen Betrieb einstellt, sind Kunden mit nicht weiterentwickelbarem Code gestrandet. GPL verhindert das.
• Demokratisierung des Webs: Die GPL ermöglicht es kleinen Organisationen, NGOs, Schulen und Einzelpersonen, professionelle Werkzeuge zu nutzen – unabhängig vom Budget.

Wo der Konflikt unauflösbar bleibt

Die Wahrheit ist unbequem: Beide Positionen haben Recht. Entwickler haben das Recht, für ihre Arbeit vergütet zu werden. Nutzer haben das Recht, Software zu verstehen, zu kontrollieren und weiterzugeben. Diese Rechte stehen in echter Spannung, und die GPL wählt bewusst eine Seite – die der Nutzerfreiheit. Wer mit dieser Wahl nicht leben kann, sollte kein GPL-Fundament verwenden.

Die größte Schwäche der Community-Position ist die Naivität in Bezug auf Kommerzialisierung: Ohne wirtschaftliche Anreize für Entwickler verarmt das Ökosystem langfristig. Die größte Schwäche der Entwickler-Position ist der Wunsch, von einer freien Community zu profitieren und gleichzeitig Geschlossenheit zu betreiben.

Weiter zu Teil 10: Zusammenfassung und Fazit – Freier Code als Fundament →

Teil 8 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 7

Wo die GPL nicht greift – legale Umgehungsstrategien

Die GPL ist eine mächtige Lizenz – aber sie ist keine lückenlose Mauer. Im Laufe der Jahre hat die kommerzielle WordPress-Welt eine Reihe von Geschäftsmodellen entwickelt, die die GPL formal respektieren und gleichzeitig erhebliche Kontrolle über die Software behalten. Diese Strategien sind nicht per se unethisch – aber es lohnt sich, sie zu kennen und kritisch zu betrachten.

1. Das SaaS-Modell: Code hosten statt verbreiten

Wie in Teil 4 erläutert, entsteht die GPL-Veröffentlichungspflicht nur bei Verbreitung. Wer WordPress-basierten Code ausschließlich als gehosteten Dienst betreibt und niemals zum Download anbietet, muss keinen Quellcode offenlegen. Plattformen wie WordPress.com nutzen massive Mengen an proprietärem Code auf Basis von Open-Source-Fundament – vollkommen legal. Dies ist die am weitesten verbreitete und mächtigste GPL-Umgehung.

2. Lizenzkey-Systeme und Update-Kontrolle

Zwar darf ein Nutzer GPL-Code weitergeben – aber die Update-Infrastruktur des Anbieters ist keine GPL-Pflicht. Anbieter wie ACF Pro oder WooCommerce-Extensions binden automatische Updates an aktive Lizenzen. Ein abgelaufener Lizenzkey bedeutet keine Updates, keinen Support – auch wenn der Code selbst GPL bleibt. Dieses Modell ist wirtschaftlich hocheffektiv und GPL-konform. Es kontrolliert nicht den Code, sondern den Zugang zu Dienstleistungen.

3. Proprietäre Assets als Mehrwert

Premium-Themes wie Divi oder Elementor Pro verdienen ihren Mehrwert nicht nur durch PHP-Code, sondern durch Design-Templates, Page-Builder-Oberflächen, Demo-Inhalte und visuelle Assets – alles außerhalb der GPL-Pflicht (oder zumindest im Graubereich). Der Code ist frei, aber das gesamte visuelle Erlebnis ist proprietär gebunden. Wer „Divi nulled” nutzt, bekommt den PHP-Code – aber keine rechtmäßige Lizenz auf die beigelegten Templates und Designs.

4. Verschleierung (Obfuscation): Legal, aber umstritten

Die GPL fordert die Bereitstellung des Quellcodes in „der bevorzugten Form für Modifikationen”. Minifizierter oder obfuskierter Code ist technisch vorhanden, aber praktisch unlesbar. Ob stark obfuskierter PHP-Code noch als „Quellcode” im GPL-Sinne gilt, ist rechtlich offen. Viele Entwickler nutzen Tools wie Ioncube oder PHP-Encoder, um ihren Code zu schützen – und riskieren damit, gegen die GPL zu verstoßen. Die Community betrachtet das als Graubereich; die FSF würde es als Verletzung werten.

5. Dual Licensing

Ein elegantes Modell: Der Entwickler bietet seinen Code unter zwei Lizenzen an – GPL für Open-Source-Nutzung und eine kommerzielle Lizenz für proprietäre Integration. Wer den Code in ein eigenes Closed-Source-Produkt einbauen will (was unter der GPL eigentlich nicht geht), zahlt für die kommerzielle Lizenz. Dieses Modell respektiert die GPL vollständig und eröffnet gleichzeitig kommerzielle Perspektiven.

Fazit: Schlupflöcher oder legitime Geschäftsmodelle?

Diese Strategien zeigen: Die GPL ist kein Garant dafür, dass Entwickler ihre Software wirklich „verschenken” müssen. Wer klug plant, kann im WordPress-Ökosystem sehr erfolgreich kommerziell agieren – und trotzdem GPL-konform bleiben. Die Frage ist nicht Schwarz oder Weiß, sondern wo man auf der Skala zwischen maximaler Offenheit und minimalem Compliance-Aufwand stehen möchte.

Weiter zu Teil 9: Die kritische Gegenüberstellung – Entwickler vs. Community →

Teil 7 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 6

GPL und Markenrecht: Zwei völlig verschiedene Rechtsbereiche

Ein fundamentales Missverständnis im WordPress-Ökosystem lautet: „Der Code ist GPL, also darf ich ihn auch unter dem Namen WordPress verkaufen.” Das ist falsch. Die GPL regelt Urheberrecht an Software – Markenrecht ist ein vollkommen separates Rechtsgebiet. Und hier liegt eine der mächtigsten Waffen der WordPress Foundation.

Die WordPress-Wortmarke

„WordPress” ist eine eingetragene Wortmarke der WordPress Foundation – in den USA und zunehmend auch international. Das bedeutet: Selbst wenn du GPL-lizenzierten WordPress-Code frei nutzen und verbreiten darfst, darfst du dein Produkt, dein Unternehmen oder deinen Dienst nicht ohne Weiteres „WordPress” nennen oder die Marke im Branding verwenden.

Die Foundation hat klare Richtlinien veröffentlicht: Der Name „WordPress” darf in beschreibenden Kontexten verwendet werden (z. B. „Plugin für WordPress”), nicht jedoch als Teil eines Produktnamens oder einer Domain, die Verwechslungen mit dem offiziellen WordPress-Projekt hervorrufen könnte. „WP” hingegen ist nicht markenrechtlich geschützt – weshalb viele Produkte dieses Kürzel verwenden.

Der WP Engine-Konflikt 2024: Ein Lehrstück

2024 eskalierte ein aufsehenerregender Streit zwischen Automattic-Gründer Matt Mullenweg und dem Hosting-Unternehmen WP Engine. Mullenweg warf WP Engine vor, massiv von der WordPress-Marke zu profitieren, ohne ausreichend zur Entwicklung des Open-Source-Projekts beizutragen. WP Engine konterte mit dem Argument, GPL-Code frei nutzen zu dürfen. Was folgte, war eine komplexe Auseinandersetzung, die die Grenzen zwischen Markenrecht, GPL, Community-Verantwortung und kommerziellem Interesse schmerzhaft offenlegte.

Dieser Konflikt illustriert: Die GPL schützt Code-Freiheit. Sie schützt nicht die Nutzung einer Marke. Und sie löst keine Fragen über ethische Verantwortung gegenüber einer Open-Source-Community.

Copyright an Code vs. Copyright an Inhalten

Neben Marken gibt es noch eine weitere wichtige Unterscheidung: das Copyright an den Inhalten eines WordPress-Projekts. Inhalte – Texte, Bilder, Videos – auf einer WordPress-Website sind vollständig unabhängig von der GPL. Der Betreiber einer WordPress-Seite behält das volle Urheberrecht an seinen Inhalten. Die GPL des verwendeten CMS berührt das nicht.

Umgekehrt gilt: Das Copyright am Code eines Plugins liegt beim Entwickler. Durch die GPL erteilt er eine sehr breite Nutzungslizenz – aber das Copyright selbst überträgt er nicht. Er kann Urheberrechtsverletzungen (z. B. Entfernung von Copyright-Hinweisen) weiterhin verfolgen.

Praxishinweis: Marken richtig handhaben

Für Entwickler und Agenturen im WordPress-Ökosystem gilt: GPL-Code frei nutzen – ja. Den Namen „WordPress” prominent im eigenen Produkt oder der Domain verwenden – nein, zumindest nicht ohne Abstimmung mit der Foundation. Das Markenrecht ist hier strenger und klarer als die oft diffuse GPL-Diskussion. Wer Ärger vermeiden will, hält sich an die veröffentlichten Trademark-Richtlinien der WordPress Foundation.

Weiter zu Teil 8: GPL-Schlupflöcher und kommerzielle Graubereiche →

Teil 6 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 5

Die Grenzen der GPL: Nicht alles ist Code

Die GPL reguliert Software – also ausführbaren Code und dessen Quellen. Sie ist keine universelle Freiheitslizenz für alle digitalen Inhalte. Wer ein WordPress-Theme unter der GPL verkauft, schützt damit nicht automatisch alle enthaltenen Assets. Dieser Unterschied ist in der Praxis enorm wichtig und wird von vielen Entwicklern und Nutzern falsch verstanden.

Fonts: Eine besonders heikle Kategorie

Schriftarten (Fonts) sind urheberrechtlich eigenständige Werke – vollkommen unabhängig von der Software, in die sie eingebettet sind. Ein Entwickler, der eine proprietäre Font in sein WordPress-Theme einbaut und dieses Theme unter der GPL veröffentlicht, hat damit keine Lizenz zur freien Weitergabe dieser Font erteilt. Die Font-Lizenz bleibt separat bestehen.

Das hat konkrete Konsequenzen: Wer ein GPL-Theme weitergibt oder nutzt, darf nicht automatisch annehmen, die enthaltenen Fonts unbegrenzt verwenden zu dürfen. Häufig ist das kein Problem – viele Entwickler nutzen Google Fonts (deren Lizenzen meist Open Font License oder Apache 2.0 sind, beide GPL-kompatibel). Wer jedoch Premium-Fonts wie Typekit/Adobe Fonts oder lizenzierte Hausschriften einbettet, muss dies gesondert klären.

Grafiken, Icons und Stock-Bilder

Ähnliches gilt für grafische Assets:

• Stock-Fotografien: Ein lizenziertes Stock-Foto aus Shutterstock oder Getty Images behält seine ursprüngliche Lizenz – die GPL des umgebenden Themes ändert daran nichts. Das Foto darf nur im Rahmen der ursprünglichen Lizenz genutzt werden.
• Icon-Sets: Proprietäre Icon-Bibliotheken (z. B. FontAwesome Pro) bleiben unter ihrer eigenen Lizenz. Open-Source-Sets wie FontAwesome Free (SIL OFL / MIT) sind problemlos.
• Demo-Inhalte: Bilder in Theme-Demos sind oft nicht zur freien Nutzung freigegeben – auch wenn das Theme GPL ist.

Datenbankstrukturen und Konfigurationsdateien

Interessant ist auch die Frage nach Datenbankschemas oder Konfigurationsdateien, die mit einem Plugin geliefert werden. Hier ist die GPL-Pflicht umstritten: Reine Datenstrukturen (SQL-Schemas, JSON-Configs) sind oft keine „Programme” im urheberrechtlichen Sinne und könnten damit außerhalb der GPL-Pflicht stehen.

Das Split-License-Modell in der Praxis

Das realistische Bild eines kommerziellen WordPress-Themes sieht daher oft so aus:

• PHP-Code: GPL v2
• JavaScript: GPL v2 oder proprietär (strittig)
• CSS: GPL v2 (wenn im WordPress.org-Verzeichnis), sonst oft proprietär
• Fonts: OFL, Apache 2.0 oder proprietär – je nach Quelle
• Bilder/Demo-Content: Proprietär oder CC0
• Icon-Sets: Je nach Bibliothek

Dieses Mosaik ist legitim – solange es transparent kommuniziert wird. Problematisch wird es, wenn Nutzer glauben, durch den GPL-Kauf eines Themes alle enthaltenen Elemente frei nutzen zu dürfen. Das ist ein verbreitetes und gefährliches Missverständnis.

Weiter zu Teil 7: Wortmarken & Copyright im WordPress-Ökosystem →

Teil 5 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 4

Die zentrale rechtliche Frage: Abgeleitetes Werk oder eigenständige Schöpfung?

Die GPL gilt für sogenannte „abgeleitete Werke” (Derivative Works). Wenn ein Plugin oder Theme als abgeleitetes Werk von WordPress gilt, unterliegt es zwingend der GPL. Doch wann ist das der Fall? Diese Frage ist der Dreh- und Angelpunkt des gesamten kommerziellen WordPress-Ökosystems – und sie ist bis heute nicht restlos geklärt.

Der starke Kopplungstest

Die herrschende Meinung in der WordPress-Community – und die offizielle Position der WordPress Foundation – lautet: Jeder PHP-Code, der WordPress-Hooks, Filter, Funktionen oder Klassen verwendet, ist ein abgeleitetes Werk und damit GPL-pflichtig. Die Begründung: PHP-Code wird direkt in den WordPress-Prozess eingebunden und läuft im selben Speicherraum. Es gibt keine klare technische Trennung – kein sauberes API, das eine Unabhängigkeit begründen könnte.

Diese Argumentation überzeugt viele Entwickler und entspricht der von der FSF (Free Software Foundation) bevorzugten Interpretation. Sie ist jedoch keine rechtskräftig bestätigte Gerichtsentscheidung.

Das Split-License-Modell: Ein pragmatischer Kompromiss

Viele kommerzielle Theme-Anbieter – darunter Platzhirsche wie Elegant Themes (Divi) und StudioPress – haben das sogenannte Split-License-Modell eingeführt:

• PHP-Code: GPL v2 (weil er WordPress-Code verknüpft)
• CSS, HTML, JavaScript, Bilder, Fonts: Proprietäre Lizenz des Entwicklers

Dieses Modell ist pragmatisch, rechtlich jedoch umstritten. WordPress.org akzeptiert nur Themes und Plugins mit 100 % GPL – wer im offiziellen Verzeichnis gelistet sein möchte, muss auch Assets unter GPL stellen. Kommerzielle Marktplätze wie ThemeForest oder direkte Verkäufer spielen nach anderen Regeln.

JavaScript: Ein ungelöstes Grenzproblem

Eine besonders kontroverse Zone ist JavaScript. Technisch läuft JavaScript im Browser des Nutzers, nicht im WordPress-Server-Prozess. Einige Rechtsmeinungen vertreten deshalb, dass JavaScript-Dateien eines WordPress-Plugins eigenständige Werke sind und nicht der GPL unterliegen. Die Gegenposition: Wenn JavaScript untrennbar mit dem Plugin-Konzept verbunden ist, fällt es unter das Gesamtwerk und damit unter die GPL.

Plugins für WordPress.org: Die 100-%-GPL-Pflicht

Für alle Entwickler, die ihre Arbeit im offiziellen WordPress Plugin Directory veröffentlichen wollen, gilt eine einfache Regel: Alles muss GPL-kompatibel sein. PHP, JavaScript, CSS – alles. Das schließt viele interessante kommerzielle Modelle aus und ist bewusst so gestaltet: Das offizielle Verzeichnis soll ein Raum echter Open-Source-Software bleiben.

Für den kommerziellen Markt außerhalb von WordPress.org gelten diese Einschränkungen nicht im gleichen Maß – hier entscheidet letztlich der Markt und das Recht.

Weiter zu Teil 6: Was die GPL nicht erfasst – Fonts, Assets, proprietäre Inhalte →

Teil 4 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 3

Die Kernpflicht der GPL: Source muss folgen

Das Herzstück der GPL ist die Quelloffenheitspflicht: Wer GPL-lizenzierten Code verbreitet – also an andere weitergibt –, muss den vollständigen Quellcode mitliefern oder auf Verlangen bereitstellen. Klingt einfach. Ist es nicht.

Wann entsteht die Pflicht?

Die entscheidende Frage lautet: Was zählt als „Verbreitung” (Distribution) im Sinne der GPL?

• Ja, Verbreitung liegt vor: Wenn du ein Plugin oder Theme zum Download anbietest – kostenlos oder kostenpflichtig. Wenn du WordPress-basierte Software an Kunden auslieferst (z. B. als maßgeschneidertes CMS). Wenn du modifizierten Code auf GitHub oder ähnlichen Plattformen veröffentlichst.
• Nein, keine Verbreitung: Wenn du die Software ausschließlich selbst nutzt – auch auf einem öffentlich zugänglichen Server. Wenn du ein WordPress-Theme für eine eigene Website baust und es niemals an Dritte weitergibst. Wenn du ein Plugin intern in deinem Unternehmen einsetzt.

Die SaaS-Lücke der GPL v2

Hier liegt eine der bemerkenswertesten Schwachstellen der GPL v2: Dienste, die über das Internet betrieben werden, gelten nicht als Verbreitung. Ein Unternehmen kann hochkomplex modifizierten WordPress-Code auf seinen Servern betreiben, Millionen von Nutzern damit bedienen – und muss dennoch keinen einzigen Quellcode veröffentlichen, solange es die Software nicht zum Download anbietet.

Genau diese Lücke hat die AGPL (Affero General Public License) geschlossen: Unter AGPL gilt auch der Betrieb eines Netzwerkdienstes als Distribution. WordPress selbst verwendet jedoch GPL v2 – die SaaS-Lücke bleibt bestehen.

Modifikation vs. Veröffentlichung: Wer muss was?

Viele Entwickler verwechseln zwei Dinge: Die GPL verpflichtet nicht dazu, eigene Weiterentwicklungen aktiv zu veröffentlichen oder der Community zurückzugeben. Sie verpflichtet lediglich dazu, den Quellcode dann bereitzustellen, wenn man die Software verbreitet. Wer seinen modifizierten WordPress-Fork niemals weitergibt, hat keinerlei Veröffentlichungspflicht – auch nicht gegenüber der WordPress-Community.

Praktische Konsequenzen für Plugin-Entwickler

Für professionelle WordPress-Entwickler bedeutet das:

• Jedes verkaufte oder kostenlos angebotene Plugin muss mit dem vollständigen PHP-Quellcode geliefert werden (Minifizierung ist erlaubt, Verschleierung nicht zwingend verboten, aber rechtlich riskant).
• Lizenzschlüssel und Aktivierungsmechanismen dürfen implementiert werden – sie sind kein Bestandteil des GPL-Codes.
• Assets wie Bilder, Icons und Schriften können unter separaten Lizenzen stehen – dazu mehr in Teil 6.

Die Veröffentlichungspflicht ist also gezielter und begrenzter als oft angenommen – aber wo sie greift, greift sie vollständig.

Weiter zu Teil 5: Was ist GPL-konform? Themes & Plugins im Detail →

Teil 3 der Lese-Reihe über WordPress & GPL. ← Zurück zu Teil 2

Das Spannungsfeld: Zwei Rechtssysteme treffen aufeinander

Wer ein kommerzielles WordPress-Plugin oder -Theme kauft, begegnet oft einem merkwürdigen Widerspruch: Die Software steht unter GPL – darf also theoretisch frei geteilt, verändert und weitergegeben werden. Gleichzeitig enthält die AGB des Anbieters Klauseln wie „Nutzung auf maximal 1 Domain erlaubt” oder „Weitergabe untersagt”. Was gilt nun wirklich?

Was AGBs über GPL-Code regeln können – und was nicht

Die Antwort ist rechtlich eindeutig, aber im Alltag verwirrend: AGBs können die durch die GPL gewährten Rechte nicht einschränken. Die GPL ist eine Urheberrechtslizenz – und Urheberrechtslizenzien rangieren über vertraglichen Zusatzvereinbarungen, wenn es um die Nutzung des lizenzierten Werkes geht.

Das bedeutet konkret: Eine AGB-Klausel, die besagt „Du darfst diesen GPL-Code nicht weitergeben”, ist in Bezug auf den Code selbst unwirksam. Die GPL gewährt explizit das Recht zur Weitergabe – dieses Recht kann durch keine nachgelagerte Vereinbarung entzogen werden.

Was AGBs legitimerweise regeln können

Es gibt jedoch einen wichtigen Bereich, in dem AGBs sehr wohl gelten: Serviceleistungen rund um die Software. Lizenzkeys, Update-Zugänge und Support sind keine Bestandteile der GPL-Software selbst – sie sind eigenständige Dienstleistungen. Ein Anbieter darf also:

• Den Zugang zu automatischen Updates an eine aktive Lizenz knüpfen
• Support auf Lizenznehmer beschränken
• Premium-Funktionen über separate, nicht-GPL-pflichtige Dienste (SaaS) anbieten
• Lizenzkeys für seine eigenen Server-Dienste kontrollieren

Was er nicht darf: den Download oder die Weitergabe des Codes selbst blockieren – zumindest nicht, wenn dieser Code GPL-lizenziert ist.

Der „GPL-Nulled”-Graubereich

Dieses Prinzip führt zu einem der umstrittensten Phänomene im WordPress-Ökosystem: sogenannte „Nulled Plugins” – Websites, die Premium-GPL-Plugins kostenlos anbieten und dies mit dem Verweis auf die GPL rechtfertigen. Technisch gesehen ist das nicht zwingend illegal, wenn der Code tatsächlich GPL-lizenziert ist. Moralisch und praktisch betrachtet ist es destruktiv: Entwickler verlieren Einnahmen, Updates entfallen, Sicherheitsrisiken entstehen.

Hier zeigt sich die tiefste Spannung zwischen dem idealen GPL-Gedanken und der kommerziellen Realität: Eine Lizenz, die maximale Freiheit für Nutzer vorsieht, kann in der Praxis auch Trittbrettfahrer ermächtigen – auf Kosten derer, die den Code tatsächlich entwickeln.

Das Fazit des Rechtskonflikts

Kein deutsches oder österreichisches Gericht hat bisher in einem Landmark-Urteil die Kombination aus GPL und AGB im WordPress-Kontext abschließend geklärt. Die rechtliche Praxis zeigt: Viele kommerzielle Anbieter operieren in einem Graubereich, der von der Community toleriert wird, solange er pragmatisch bleibt. Die GPL setzt die Grenze – aber die Durchsetzung dieser Grenze liegt beim Urheber.

Weiter zu Teil 4: Die Code-Veröffentlichungspflicht →

Dies ist Teil 2 einer 10-teiligen Lese-Reihe über WordPress, GPL, AGB-Konflikte und freien Code. ← Zurück zu Teil 1

Die Geburtsstunde: b2/cafelog und Matt Mullenweg

WordPress entstand 2003 aus dem Fork eines GPL-lizenzierten Blogsystems namens b2/cafelog. Matt Mullenweg und Mike Little übernahmen den verwaisten Code und entwickelten ihn weiter – und weil b2 unter der GPL stand, war auch WordPress automatisch GPL-pflichtig. Die Lizenzwahl war kein ideologisches Statement, sondern eine rechtliche Konsequenz.

Doch was als Notwendigkeit begann, wurde zur Philosophie. Matt Mullenweg und Automattic haben die GPL seither aktiv verteidigt und ausgebaut – nicht zuletzt durch juristische Auseinandersetzungen mit Entwicklern, die versuchten, WordPress-Code unter restriktiveren Lizenzen zu vertreiben.

Die WordPress Foundation und ihr Lizenzdiktat

Die WordPress Foundation ist die gemeinnützige Organisation hinter WordPress. Sie verwaltet das WordPress-Projekt, die Markenrechte und – entscheidend – die Lizenzpolitik. Wer Themes oder Plugins im offiziellen WordPress.org-Verzeichnis veröffentlichen möchte, muss seine gesamte Software zu 100 % unter der GPL lizenzieren.

Diese Anforderung klingt selbstverständlich, ist aber in der Praxis weitreichend: Selbst kommerzielle Anbieter außerhalb von WordPress.org unterliegen nach der Rechtsauffassung der Foundation der GPL, wenn ihr Code auf WordPress-Funktionen aufbaut – also praktisch immer.

Der „Themes sind GPL”-Streit von 2009

2009 eskalierte der erste große Lizenzkonflikt im WordPress-Ökosystem: Matt Mullenweg und die Software Freedom Law Center (SFLS) vertraten die Position, dass WordPress-Themes vollständig unter der GPL stehen, weil sie durch PHP-Funktionen wie get_template_part() oder Hook-Systeme eng mit dem WordPress-Core verknüpft sind und damit als „abgeleitete Werke” (Derivative Works) gelten.

Premium-Theme-Anbieter sahen das naturgemäß anders: Sie hatten teilweise jahrelang in ihre Designs investiert und wollten diese nicht zwingend offen legen müssen. Der Streit mündete in einer faktischen Branchenregel, dem sogenannten „Split-License”-Modell: PHP-Code unter GPL, CSS/HTML/Assets unter eigener Lizenz. Mehr dazu in Teil 5 und 6 dieser Reihe.

Automattic als kommerzieller GPL-Akteur

Automattic – das Unternehmen hinter WordPress.com, WooCommerce und Jetpack – zeigt eindrücklich, dass GPL und Kommerz kein Widerspruch sein müssen. Automattic verdient Milliarden mit GPL-lizenzierter Software: durch Hosting, Support, Premium-Features und Markenrechte. Der Code bleibt frei, das Geschäftsmodell nicht. Dieses Modell ist sowohl Vorbild als auch Streitpunkt – denn es wirft die Frage auf, ob „freier Code” wirklich allen nutzt oder vor allem denen, die die Infrastruktur kontrollieren.

Die historische Weichenstellung

Die Entscheidung, WordPress als GPL-Projekt zu führen, hat das gesamte Web-Ökosystem geprägt. Sie hat eine riesige Community ermöglicht, Tausende von kostenlosen Plugins hervorgebracht und technische Innovation demokratisiert. Sie hat aber auch Spannungen erzeugt, die bis heute andauern – zwischen Entwicklern, die von ihrer Arbeit leben wollen, und einer Lizenz, die Offenheit verlangt. Diese Spannung ist der rote Faden dieser gesamten Reihe.

Weiter zu Teil 3: GPL vs. kommerzielle AGBs – wenn Lizenzen kollidieren →

Dies ist Teil 1 einer 10-teiligen Lese-Reihe über WordPress, die GPL-Lizenz, AGB-Konflikte, Markenrecht und freien Code. Die Reihe beleuchtet kritisch beide Seiten und schließt mit einem klaren Fazit ab.

Der Ursprung: Richard Stallman und die Free Software Foundation

Die Geschichte der GNU General Public License (GPL) beginnt 1983 mit Richard Stallman, einem Programmierer am MIT. Als er feststellt, dass proprietäre Software Nutzern Freiheiten entzieht – die Freiheit zu lesen, zu verändern, weiterzugeben –, gründet er das GNU-Projekt und formuliert eine radikale Gegenvision: Software, die für alle frei bleibt.

1989 erscheint die erste Version der GPL. Ihr Kernprinzip ist das sogenannte Copyleft: Wer GPL-lizenzierten Code nutzt, verändert oder weiterverbreitet, muss sein Werk ebenfalls unter der GPL veröffentlichen. Freiheit pflanzt sich fort – zwangsweise.

Die vier Freiheiten

Die GPL basiert auf vier fundamentalen Freiheiten für jeden Nutzer von Software:

• Freiheit 0: Das Programm für jeden Zweck ausführen zu dürfen.
• Freiheit 1: Die Funktionsweise des Programms zu untersuchen und es den eigenen Bedürfnissen anzupassen (Quellcode-Zugang vorausgesetzt).
• Freiheit 2: Kopien des Programms weitergeben zu dürfen, um dem Nächsten zu helfen.
• Freiheit 3: Das Programm zu verbessern und diese Verbesserungen zu veröffentlichen, damit die gesamte Gemeinschaft davon profitiert.

GPL v2 vs. GPL v3: Was hat sich geändert?

WordPress verwendet bis heute die GPL v2 (mit der Option „or any later version”). GPL v2 von 1991 war die dominierende Version in der Open-Source-Welt. GPL v3 erschien 2007 und adressiert zusätzliche Bedrohungen wie Tivoization (Hardware-Sperren gegen modifizierte Software) und Software-Patente – Themen, die für das WordPress-Ökosystem weniger relevant sind, weshalb v2 die Basis bleibt.

Was die GPL nicht ist

Ein weit verbreitetes Missverständnis: GPL bedeutet nicht zwingend kostenlos. „Free software” meint Freiheit, nicht Gratis. Entwickler dürfen GPL-Software verkaufen – sie müssen lediglich den Quellcode bereitstellen. Dieses Prinzip ist das Fundament des gesamten kommerziellen WordPress-Ökosystems und gleichzeitig der Kern vieler Konflikte, die wir in dieser Reihe beleuchten werden.

Warum das für WordPress wichtig ist

WordPress ist das meistgenutzte CMS der Welt – betreibt über 40 % aller Websites. Als GPL-lizenziertes Projekt hat diese Lizenz direkte Auswirkungen auf jeden Entwickler, der Themes oder Plugins erstellt, jedes Unternehmen, das WordPress-Produkte verkauft, und jeden Nutzer, der glaubt, unbegrenzte Rechte an einem gekauften Plugin zu haben. In den folgenden Teilen dieser Reihe werden wir sehen, wie tiefgreifend diese Lizenz das gesamte Ökosystem prägt – und wo die Grenzen des freien Codes tatsächlich liegen.

Weiter zu Teil 2: Wie WordPress zur GPL-Plattform wurde →