GPL & WordPress – Teil 6: Was die GPL NICHT erfasst – Fonts, Assets und proprietäre Inhalte

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 →