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 →
Schreibe einen Kommentar