Isometrische 3D-Illustration, die das Konzept der GPL-Lizenz visualisiert. Ein zentrales Lizenzdokument mit dem Copyleft-Symbol öffnet eine Box mit Quellcode ("Open Source"). Dieser Code fließt frei zu verschiedenen Entwicklern, und modifizierte Versionen, die weitergegeben werden, tragen weiterhin das GPL-Siegel, was das virale Prinzip der Lizenz verdeutlicht.

GPL (General Public License) – Bedeutung, Versionen & WordPress

Die GPL (General Public License) ist eine freie Software-Lizenz mit Copyleft-Charakter, die sicherstellt, dass Software und alle davon abgeleiteten Werke dauerhaft frei bleiben. Entwickelt von der Free Software Foundation (FSF), garantiert die GPL grundlegende Freiheiten: Software nutzen, verstehen, verändern und weitergeben zu dürfen – kommerziell oder nicht-kommerziell.

Die GPL ist die weltweit am häufigsten genutzte Open-Source-Lizenz und bildet das rechtliche Fundament für bedeutende Projekte wie Linux, WordPress, MySQL und tausende weitere Softwarelösungen. Ihre besondere Stärke liegt im Copyleft-Prinzip: Wer GPL-lizenzierte Software verändert und verbreitet, muss die Änderungen ebenfalls unter der GPL veröffentlichen.

Was macht die GPL besonders?

Die General Public License unterscheidet sich fundamental von proprietären Lizenzen und auch von permissiven Open-Source-Lizenzen wie der MIT- oder Apache-Lizenz. Während permissive Lizenzen weitgehend erlauben, dass Code in proprietäre Software integriert wird, verhindert die GPL dies gezielt.

Die vier Grundfreiheiten der GPL

Die GPL garantiert vier essentielle Freiheiten, die jede freie Software aufweisen muss:

  1. Freiheit 0: Die Software für jeden Zweck nutzen zu dürfen
  2. Freiheit 1: Die Funktionsweise der Software studieren und an eigene Bedürfnisse anpassen zu können (Zugang zum Quellcode erforderlich)
  3. Freiheit 2: Kopien der Software weitergeben zu dürfen, um anderen zu helfen
  4. Freiheit 3: Die Software verbessern und diese Verbesserungen veröffentlichen zu dürfen, sodass die gesamte Community profitiert

Diese Freiheiten sind nicht nur theoretisch, sondern rechtlich durchsetzbar. Sie machen die GPL zu einer der stärksten Garantien für Softwarefreiheit.

Das Copyleft-Prinzip verstehen

Copyleft ist das definitive Merkmal der GPL. Anders als Copyright, das Nutzung einschränkt, nutzt Copyleft das Urheberrecht, um Freiheit zu garantieren. Konkret bedeutet das:

Wenn du GPL-lizenzierte Software nutzt und veränderst, darfst du deine Version verbreiten – aber nur, wenn du sie ebenfalls unter der GPL lizenzierst. Du kannst also nicht GPL-Code nehmen, modifizieren und dann als proprietäre Software verkaufen, ohne den Quellcode offenzulegen.

Dieses „virale“ Prinzip sorgt dafür, dass einmal freie Software dauerhaft frei bleibt. Es schützt die Gemeinschaft vor Trittbrettfahrern, die von gemeinschaftlich entwickelter Software profitieren möchten, ohne selbst etwas zurückzugeben.

Wichtig: Das Copyleft gilt nur, wenn du die Software verbreitest. Wenn du GPL-Software nur intern in deinem Unternehmen nutzt und modifizierst, ohne sie nach außen zu verteilen, musst du deine Änderungen nicht veröffentlichen.

GPL-Versionen im Überblick

Die GPL existiert in mehreren Versionen, die jeweils auf aktuelle technologische und rechtliche Entwicklungen reagieren.

GPL Version 2 (GPLv2)

Die GPL v2 wurde 1991 veröffentlicht und ist bis heute eine der meistgenutzten Versionen. WordPress und der Linux-Kernel nutzen beispielsweise GPL v2. Sie ist vergleichsweise kurz und fokussiert sich auf die Kernprinzipien freier Software.

Charakteristika der GPLv2:

  • Klare Definition der vier Freiheiten
  • Starkes Copyleft ohne Ausnahmen
  • Kompatibilität mit vielen anderen Lizenzen
  • Bewusst einfach gehalten für breite Akzeptanz

Viele Projekte verwenden die Formulierung „GPL v2 or later“ (GPL v2 oder spätere Versionen), was Nutzern erlaubt, zwischen verschiedenen GPL-Versionen zu wählen.

GPL Version 3 (GPLv3)

Die GPL v3 erschien 2007 nach jahrelanger Diskussion. Sie adressiert neue Herausforderungen wie Software-Patente, Digital Rights Management (DRM) und Hardware-Beschränkungen.

Neuerungen der GPLv3:

  • Anti-Tivoization: Verhindert, dass Hersteller GPL-Software auf Hardware einsetzen, die Nutzer dann nicht mehr modifizieren können (benannt nach TiVo, die genau das taten)
  • Patent-Schutz: Wer GPL v3 Software verbreitet, gewährt automatisch Patent-Lizenzen für die beigetragenen Teile
  • Internationalisierung: Bessere Anpassung an verschiedene Rechtssysteme weltweit
  • DRM-Klauseln: Einschränkungen gegen die Nutzung von DRM-Systemen, die Nutzerfreiheiten beschneiden

Die GPL v3 ist umfangreicher und komplexer als v2. Einige Projekte bleiben bewusst bei v2, weil sie die zusätzlichen Einschränkungen als zu weitgehend empfinden.

Welche Version sollte man wählen?

Für neue Projekte empfiehlt die FSF grundsätzlich die GPL v3, da sie zeitgemäßeren Schutz bietet. In der Praxis hängt die Wahl jedoch von mehreren Faktoren ab:

  • Kompatibilität: Wenn dein Projekt GPL v2-Code einbindet, der nicht „or later“ lizenziert ist, kannst du nur v2 nutzen
  • Community-Präferenzen: In manchen Bereichen (z.B. Linux-Kernel-Entwicklung) dominiert v2
  • Patent-Schutz: Wenn Patente relevant sind, bietet v3 besseren Schutz
  • Flexibilität: „v2 or later“ ermöglicht maximale Kompatibilität

GPL und WordPress: Eine besondere Beziehung

WordPress ist zu 100% unter der GPL v2 lizenziert – und das prägt die gesamte WordPress-Community fundamental. Diese Entscheidung hat weitreichende Konsequenzen für alle, die mit WordPress arbeiten.

Warum WordPress die GPL nutzt

Die Wahl der GPL für WordPress war keine Zufallsentscheidung. Matt Mullenweg, Mitbegründer von WordPress, übernahm das Projekt 2003 von b2/cafelog, das bereits GPL-lizenziert war. Die GPL-Lizenzierung wurde beibehalten und zur Philosophie des gesamten Ökosystems.

Die GPL garantiert für WordPress:

  • Jeder kann WordPress kostenlos herunterladen und nutzen
  • Der vollständige Quellcode ist einsehbar und modifizierbar
  • Niemand kann WordPress „kaufen“ und proprietär machen
  • Verbesserungen kommen der gesamten Community zugute

Die „100%-GPL“-Regel für Themes und Plugins

Hier wird es interessant und manchmal kontrovers: Nach Auffassung der WordPress Foundation müssen auch alle Themes und Plugins GPL-kompatibel lizenziert sein. Das bedeutet konkret:

PHP-Code: Muss zwingend unter GPL oder GPL-kompatibel lizenziert sein. Da Themes und Plugins WordPress-Funktionen nutzen und somit abgeleitete Werke sind, greift hier das Copyleft-Prinzip.

CSS, JavaScript, Bilder: Technisch gesehen sind diese Dateien keine abgeleiteten Werke von WordPress, da sie unabhängig vom PHP-Code funktionieren könnten. Die WordPress Foundation empfiehlt dennoch GPL-Lizenzierung für maximale Freiheit.

Split-Licensing: Manche Entwickler lizenzieren PHP-Code unter GPL und Grafiken/CSS unter restriktiveren Lizenzen. Diese Praxis ist umstritten, wird aber oft toleriert.

Premium-Themes und -Plugins unter der GPL

Ein häufiges Missverständnis: GPL bedeutet nicht „kostenlos“. Du darfst GPL-Software verkaufen. Aber: Wer deine Software kauft, erhält alle GPL-Rechte – inklusive des Rechts, sie weiterzuverbreiten.

Geschäftsmodelle unter GPL:

  • Support & Updates: Verkauf von Wartungsverträgen und Premium-Support (z.B. ACF Pro)
  • Hosting & Services: Managed Hosting und professionelle Dienstleistungen (z.B. WP Engine)
  • SaaS-Modelle: Software as a Service unterliegt oft nicht der GPL, da keine Distribution stattfindet
  • Dual-Licensing: Anbieten unter GPL und einer kommerziellen Lizenz für spezielle Nutzungsfälle

GPL-Enforcement in der WordPress-Community

Das WordPress.org-Plugin-Verzeichnis und Theme-Verzeichnis akzeptieren ausschließlich 100% GPL-lizenzierte Software. Dies wird aktiv durchgesetzt:

  • Plugins mit proprietären Teilen werden abgelehnt
  • Split-License-Ansätze werden kritisch geprüft
  • Bei Verstößen erfolgt Ausschluss aus dem Verzeichnis

Gleichzeitig existiert ein florierender Markt für Premium-WordPress-Produkte außerhalb des offiziellen Verzeichnisses, die unterschiedliche Lizenzmodelle nutzen.

Praktische Auswirkungen der GPL für Website-Betreiber

Als Website-Betreiber oder Agentur beeinflusst die GPL deinen Alltag mehr, als du vielleicht denkst. Hier die wichtigsten praktischen Implikationen:

Was du darfst

Uneingeschränkte Nutzung: Du darfst WordPress, GPL-Themes und -Plugins unbegrenzt auf beliebig vielen Websites einsetzen – kommerziell, privat, für Kunden. Keine Lizenzgebühren pro Website.

Modifikationen: Du darfst jeden Aspekt von WordPress, Themes und Plugins nach deinen Wünschen anpassen. Der Quellcode steht dir offen.

Weiterverteilung: Du kannst modifizierte Versionen weitergeben – an Kunden, als kostenloses Download oder sogar verkaufen. Aber: Du musst den Quellcode mitliefern und GPL-Lizenzierung beibehalten.

Kundenprojekte: Wenn du für Kunden Websites entwickelst, darfst du GPL-Software nutzen und nach deinen Anforderungen anpassen. Die entwickelte Website gehört rechtlich dem Kunden.

Was du beachten musst

Lizenz-Weitergabe: Wenn du modifizierte GPL-Software verbreitest, musst du die GPL-Lizenz mitliefern und deutlich auf die Lizenzierung hinweisen.

Quellcode-Verfügbarkeit: Bei Verbreitung musst du Zugang zum vollständigen Quellcode gewähren. Dies kann per Download, auf Anfrage oder durch Hinweis auf öffentliche Repositories erfolgen.

Keine zusätzlichen Restriktionen: Du darfst keine Einschränkungen hinzufügen, die über die GPL hinausgehen. Etwa Klauseln wie „nicht für kommerzielle Nutzung“ oder „Quellcode darf nicht weitergegeben werden“ wären unzulässig.

Support-Unterschiede: Wenn du GPL-Software von Dritten weitergibst, bist du nicht verpflichtet, Support zu leisten – aber du darfst auch keine Support-Verpflichtung des Original-Entwicklers vortäuschen.

Grauzone: Interne Nutzung

Wenn du GPL-Software nur intern nutzt, ohne sie zu verbreiten, greift das Copyleft nicht. Du könntest theoretisch WordPress für ein geschlossenes Intranet modifizieren, ohne Änderungen veröffentlichen zu müssen. Sobald du aber die Software an Dritte weitergibst (z.B. an Kunden), wird daraus eine Distribution.

Achtung bei SaaS: Wenn du einen Web-Service betreibst (z.B. eine WordPress-basierte Plattform), gilt das traditionell nicht als „Distribution“, da Nutzer keine Software-Kopie erhalten. Die GPL greift hier also nicht zwingend. Die AGPL (Affero GPL) wurde entwickelt, um auch SaaS-Anwendungen mit Copyleft zu erfassen.

Vorteile der GPL für die Software-Community

Die GPL hat entscheidend zur Entstehung robuster Open-Source-Ökosysteme beigetragen. Ihre Stärken liegen in mehreren Bereichen:

Langfristige Verfügbarkeit

Software unter GPL kann nicht nachträglich „geschlossen“ werden. Selbst wenn der Original-Entwickler das Projekt aufgibt oder verkauft, bleibt der Code frei verfügbar. Die Community kann jederzeit Forks erstellen und Weiterentwicklung übernehmen.

Schutz vor Vendor Lock-in

GPL-Software garantiert, dass du nie von einem einzelnen Anbieter abhängig wirst. Du hast immer Zugang zum Quellcode und kannst bei Bedarf selbst weiterentwickeln oder alternative Anbieter beauftragen.

Gemeinschaftliche Entwicklung

Das Copyleft-Prinzip motiviert Rückgabe an die Community. Unternehmen, die GPL-Software nutzen und verbessern, haben einen Anreiz, ihre Verbesserungen zu teilen, da sie ohnehin bei Distribution offengelegt werden müssen.

Transparenz und Sicherheit

Offener Quellcode ermöglicht unabhängige Sicherheitsprüfungen. Sicherheitslücken können schneller gefunden und geschlossen werden. Bei proprietärer Software musst du dem Hersteller blind vertrauen.

Kritik und Herausforderungen

Trotz ihrer Popularität ist die GPL nicht ohne Kritik:

Komplexität und Rechtsunsicherheit

Die GPL ist rechtlich komplex. Insbesondere die Frage, wann ein Werk ein „abgeleitetes Werk“ ist und damit unter das Copyleft fällt, ist oft unklar. Dies führt zu Unsicherheit bei Entwicklern und Unternehmen.

„Virale“ Natur als Hindernis

Manche Unternehmen meiden GPL-Software, weil sie befürchten, dass das Copyleft ihre eigenen proprietären Produkte „infiziert“. Dies kann die Verbreitung von GPL-Software in bestimmten Kontexten behindern.

Inkompatibilität zwischen Versionen

GPL v2 und GPL v3 sind nicht direkt kompatibel. Code unter „GPL v2 only“ kann nicht mit GPL v3-Code kombiniert werden. Dies fragmentiert das Ökosystem teilweise.

Business-Herausforderungen

Geschäftsmodelle rund um GPL-Software sind schwieriger als bei proprietärer Software. Man kann nicht einfach „Lizenzen verkaufen“, sondern muss kreative Wege finden (Support, Hosting, Dual-Licensing).

GPL vs. andere Open-Source-Lizenzen

Die GPL ist nur eine von vielen Open-Source-Lizenzen. Ein Vergleich hilft bei der Einordnung:

GPL vs. MIT/BSD (Permissive Lizenzen)

MIT/BSD:

  • Erlauben Integration in proprietäre Software
  • Kein Copyleft, keine Verpflichtung zur Offenlegung
  • Sehr kurz und einfach zu verstehen
  • Maximale Freiheit für Nutzer, geringerer Schutz für die Community

GPL:

  • Verhindert Proprietarisierung durch Copyleft
  • Garantiert dauerhafte Freiheit aller Derivate
  • Komplexer und umfangreicher
  • Stärkerer Schutz für die Community, mehr Einschränkungen für Nutzer

Die Wahl zwischen beiden hängt von deinen Prioritäten ab: Maximale Verbreitung (MIT/BSD) oder Schutz vor Proprietarisierung (GPL).

GPL vs. LGPL (Lesser GPL)

Die LGPL ist eine abgeschwächte Version der GPL, primär für Bibliotheken gedacht. Sie erlaubt, LGPL-Libraries in proprietärer Software zu nutzen, ohne dass diese unter GPL fallen muss. Dies macht LGPL attraktiver für Entwickler, die breitere Akzeptanz suchen.

GPL vs. AGPL (Affero GPL)

Die AGPL erweitert die GPL um eine Klausel für Netzwerk-Nutzung. Wenn du AGPL-Software als Web-Service anbietest, musst du den Quellcode verfügbar machen – auch wenn keine klassische Distribution stattfindet. Dies schließt die „SaaS-Lücke“ der GPL.

GPL-Compliance: Was Unternehmen beachten müssen

Wenn dein Unternehmen GPL-Software nutzt und verbreitet, solltest du folgende Punkte sicherstellen:

Compliance-Checkliste

1. Lizenz-Dokumentation:

  • Kopie der GPL-Lizenz in jedem Softwarepaket inkludieren
  • Deutlich auf GPL-Lizenzierung hinweisen
  • Copyright-Vermerke aller Beitragenden erhalten

2. Quellcode-Bereitstellung:

  • Vollständigen, kompilierbaren Quellcode bereitstellen
  • Build-Anleitungen und Abhängigkeiten dokumentieren
  • Quellcode mindestens 3 Jahre verfügbar halten

3. Keine zusätzlichen Einschränkungen:

  • Keine NDAs bezüglich GPL-Code
  • Keine Klauseln, die GPL-Rechte einschränken
  • Keine Patent-Bedrohungen gegen Nutzer

4. Third-Party-Code überprüfen:

  • Lizenzen aller eingebundenen Komponenten prüfen
  • Sicherstellen, dass alle Komponenten GPL-kompatibel sind
  • Dokumentation der Lizenz-Situation pflegen

Häufige Compliance-Fehler

  • Fehlende Lizenz-Dateien: GPL-Text nicht mitgeliefert
  • Unvollständiger Quellcode: Build-Scripts oder Abhängigkeiten fehlen
  • Zusätzliche Restriktionen: In AGB oder Verträgen versteckte Einschränkungen
  • Fehlende Attributierung: Copyright-Hinweise entfernt oder vergessen

Alternativen zur GPL

Je nach Projekt-Anforderungen können alternative Lizenzen sinnvoller sein:

Permissive Lizenzen (MIT, Apache, BSD): Wenn du maximale Verbreitung willst und es dir egal ist, ob jemand deine Software proprietär macht.

LGPL: Wenn du eine Bibliothek entwickelst, die auch in proprietärer Software nutzbar sein soll.

AGPL: Wenn du sicherstellen willst, dass auch SaaS-Anbieter ihren Code teilen müssen.

Dual-Licensing: Kommerzielle Lizenz für Kunden, die Copyleft vermeiden wollen, GPL für alle anderen.

Custom Lizenzen: Für spezifische Anforderungen, aber mit deutlich geringerer Community-Akzeptanz.

Zukunft der GPL

Die GPL bleibt relevant, steht aber vor Herausforderungen:

Cloud Computing: Traditionelle GPL greift bei SaaS-Modellen nicht. Die AGPL versucht dies zu adressieren, hat aber geringere Verbreitung.

Container & Microservices: Die Frage, wann ein Container ein „abgeleitetes Werk“ ist, ist rechtlich ungeklärt.

KI-Training: Neue Fragen entstehen: Ist ein auf GPL-Code trainiertes KI-Modell ein abgeleitetes Werk? Dies wird rechtlich noch zu klären sein.

GPL v4? Eine neue Version wird diskutiert, ist aber nicht konkret in Planung. Herausforderungen liegen in der Balance zwischen Schutz und Praktikabilität.

Fazit: GPL als Fundament digitaler Freiheit

Die GPL ist mehr als nur eine Lizenz – sie ist eine Philosophie über Softwarefreiheit und Community-Verantwortung. Ihre Stärke liegt im konsequenten Schutz der Nutzerfreiheiten durch das Copyleft-Prinzip.

Für WordPress-Nutzer und -Entwickler ist die GPL das rechtliche Fundament eines offenen Ökosystems. Sie garantiert, dass WordPress nie proprietär werden kann und dass alle Verbesserungen der Community zugutekommen können.

Ob die GPL für dein eigenes Projekt die richtige Wahl ist, hängt von deinen Zielen ab: Willst du maximale Kontrolle über Derivate behalten (dann GPL), maximale Verbreitung erreichen (dann permissive Lizenz) oder etwas dazwischen (dann LGPL oder Dual-Licensing)?

Die GPL hat wesentlich zur Entstehung der modernen Open-Source-Bewegung beigetragen und bleibt eine der einflussreichsten Software-Lizenzen der Welt. Ihr Erbe zeigt sich täglich in Millionen von WordPress-Websites, Linux-Servern und zahllosen anderen Anwendungen, die unser digitales Leben prägen.

Mach deine Website fit für mehr Sichtbarkeit, Geschwindigkeit und Nutzerfreundlichkeit

Sichere dir jetzt deinen kostenlosen 30-Minuten Website-Check im Zoom.
Wir prüfen deine Seite auf SEO, Ladezeit, UX und Barrierefreiheit – und geben dir konkrete Tipps, die du sofort umsetzen kannst.

Autor: Tim Ehling
Der Autor: Tim Ehling

Seit über zwei Jahrzehnten beschäftige ich mich mit Webentwicklung – und seit 2006 ganz besonders intensiv mit WordPress. Ich entwickle und optimiere Webseiten, betreue sie langfristig durch zuverlässige Wartung und biete Schulungen für alle, die WordPress sicher und effizient nutzen möchten. Außerdem unterstütze ich Unternehmen dabei, ihre Social-Media-Kanäle und SEO-Strategien so zu verbessern, dass sie bei Kunden und Suchmaschinen gleichermaßen gut ankommen.

Schwerpunkte:
✔ Webentwicklung ✔ WordPress-Updateservice
✔ WordPress-Schulungen ✔ Social-Media-Checkups
✔ Suchmaschinenoptimierung (SEO) ✔ KI ✔ Generative Engine Optimization (GEO)

Alle Beiträge von Tim Ehling lesen Tim Ehling auf LinkedIn