Das

PHP-Projekt ist seit vielen Jahren ein Projekt mit schwerem „historischen Ballast“ in Bezug auf Lizenzprobleme und bereitet sich nun auf eine wichtige und gründliche Bereinigung vor: Ein von Community-Mitglied Ben Ramsey geleiteter Vorschlag sieht vor, die beiden derzeit verwendeten Sätze benutzerdefinierter Lizenzen aufzugeben – PHP-Lizenz 3.01, die den größten Teil des Codes abdeckt, und Zend-Lizenz 2.0 für Zend-Verzeichniscode – und BSD in zukünftigen Versionen zu übernehmen. Drei-Klausel-Lizenz (Modified BSD). Derzeit stimmt die PHP-Community über diesen „PHP License Update“ RFC ab, der bis zum 4. April 2026 dauern wird.

In den frühen Entwicklungsstadien von PHP änderte das Projekt seine Lizenz recht häufig: von 1995 bis Im Jahr 2006 erfuhr PHP insgesamt sieben Lizenzänderungen bzw. Vertragsanpassungen. Ursprünglich wurde PHP unter GPLv2 veröffentlicht; PHP 3, das 1998 veröffentlicht wurde, übernahm eine doppelte Autorisierungsmethode von GPLv2 und der neuen PHP-Lizenz. Diese neue Lizenz basierte auf der Apache-Lizenz 1.0 und wurde vom PHP-Gründer Rasmus Lerdorf formuliert, um PHP für kommerzielle Benutzer „freundlicher“ zu machen und gleichzeitig die Eigenschaften freier Software beizubehalten. Lerdorf sagte damals, er wolle sicherstellen, dass PHP weiterhin kostenlos bleibt, damit kommerzielle Unternehmen kommerzielle Versionen ausprobieren können, ohne dass sich große Mitwirkende „ausgenutzt“ fühlen.

Die ursprüngliche Version der benutzerdefinierten PHP-Lizenz enthielt jedoch eine Klausel, die eine schriftliche Genehmigung des PHP-Entwicklungsteams für die kommerzielle Weiterverbreitung erforderte, was sich in der Praxis als schwierig zu handhaben erwies und schließlich in PHP-Version 3.0.14 entfernt wurde. Die mit dieser Version gelieferte LIZENZ-Datei gibt nicht einmal die Versionsnummer der Lizenz an.

PHP 4.0, veröffentlicht im Mai 2000, war eine umfassende Umgestaltung, die die von Zeev Suraski und Andi Gutmans geschriebene Zend-Engine einführte, die später Zend Technologies in der Hoffnung gründeten, die Zend-Engine unabhängig von PHP zu kommerzialisieren. Zend stellt PHP-Projekten Lizenzen zur Integration der Zend-Engine in PHP zur Verfügung und verspricht, dass der relevante Code unter der Zend-Lizenz oder anderen Lizenzen im Einklang mit der Open Source Definition (OSD) bleibt, obwohl die Zend-Lizenz selbst nicht offiziell von der Open Source Initiative (OSI) genehmigt wurde. Seitdem hat der Code im Zend-Verzeichnis im PHP-Quellbaum die Zend-Lizenz übernommen; PHP 4.0 hat auch GPLv2 vollständig aufgegeben und PHP License 2.02 eingeführt.

In den folgenden Jahren wurde die PHP-Lizenz weiter verfeinert: Die PHP 3.0-Version der Lizenz wurde von OSI genehmigt, dann wurde jedoch eine geringfügige Änderung vorgenommen, um die PHP-Lizenz 3.01 zu bilden. Durch diese Änderung werden lediglich das Urheberrechtsjahr und die Art und Weise, wie der Bestätigungstext für PHP und Zend ausgedrückt wird, angepasst, die Lizenzrechte selbst werden jedoch nicht geändert. Diese neue Version wurde jedoch nie wieder von OSI überprüft. Um die Sache noch besorgniserregender zu machen, gilt der Lizenztext angeblich nur für Software, die von der „PHP Group“ veröffentlicht wurde, bei der es sich selbst nicht um eine tatsächliche juristische Person, sondern um eine Liste von zehn frühen PHP-Entwicklern handelt. Diese Unklarheit hat einige Leute zu der Annahme geführt, dass von anderen Unternehmen veröffentlichte Software die PHP-Lizenz nicht legal als Autorisierungstext verwenden darf, was zu praktischen Problemen für Projekte wie Debian führt. Ramsey geht speziell in RFC auf diesen historischen Hintergrund ein.

Im aktuellen RFC schlug Ramsey vor, dass ab der nächsten Hauptversion (ursprünglich als PHP 9.0 geschrieben, später auf „die nächste Version von PHP“ aktualisiert) die aktuelle PHP-Lizenz und die Zend-Lizenz einheitlich durch die BSD-Drei-Klausel-Lizenz ersetzt werden. Er sagte, dass er beim Verfassen des Vorschlags mit der Vorsitzenden des OSI-Lizenzausschusses, Pamela Chestek, zusammengearbeitet habe, um relevante rechtliche Fragen und Fragen zu klären.

Ramsey sagte, er habe mit allen Mitgliedern der PHP-Gruppe kommuniziert und jedes Mitglied habe seine Unterstützung für diese Änderung zum Ausdruck gebracht. Gleichzeitig erwarb er auch eine Lizenz von Perforce Software – Perforce brachte Zend im Jahr 2019 durch die Übernahme von Rogue Wave, das Zend im Jahr 2015 übernahm, unter sein Dach. Man könnte sich fragen: Da im Laufe der Jahre so viele Personen Code an PHP übermittelt haben, muss dann jeder Mitwirkende zustimmen, bevor die Lizenz geändert werden kann? Im RFC meint Ramsey: Nein. PHP verlangt von den Mitwirkenden nicht, dass sie eine CLA unterzeichnen, die das Urheberrecht auf das Projekt überträgt, sodass die Mitwirkenden das Urheberrecht an ihrem beigesteuerten Code behalten; sofern sie jedoch nicht ausdrücklich andere Lizenzbedingungen angeben, kann davon ausgegangen werden, dass sie dem Projekt das Recht einräumen, ihre Beiträge unter der aktuellen Lizenz des Projekts zu nutzen.

Mit anderen Worten: Die Mitwirkenden besitzen das Urheberrecht an dem Code, den sie einreichen. Wenn jedoch keine andere Lizenz angegeben ist, sind ihre Beiträge gemäß der vom Projekt angenommenen Lizenz zur Nutzung durch das Projekt berechtigt. Ramsey wies weiter darauf hin, dass bei einer Änderung der Lizenz eines Open-Source-Projekts in der Regel die Zustimmung aller Urheberrechtsinhaber erforderlich sei, da sich durch die neue Lizenz der Umfang der den Nutzern gewährten Rechte ändern könne. In diesem Fall ändert der Wechsel zur BSD-Drei-Klausel-Lizenz jedoch nicht die Rechte, die anderen Mitwirkenden als PHP Group und Perforce Software gewährt werden. Daher ist er der Ansicht, dass Projekte nicht die ausdrückliche Genehmigung aller Mitwirkenden einzeln einholen müssen.

Während der RFC anmerkt, dass eine individuelle Zustimmung gesetzlich nicht erforderlich ist, schlug Ramsey aus „Höflichkeit“ vor, den Diskussionszeitraum mindestens sechs Monate lang beizubehalten, um sicherzustellen, dass alle Beteiligten ausreichend Gelegenheit haben, ihre Ansichten zu äußern. Seit der RFC im Juli 2025 vorgeschlagen wurde, hat er mehrere Aktualisierungen herausgegeben und die Community daran erinnert, dass das Thema immer noch diskutiert wird; Es bestehen bislang keine sachlichen Einwände.

Während der Diskussion kamen auch einige spezifische Probleme zur Sprache. Derick Rethans fragte beispielsweise, warum es notwendig sei, bis PHP 9 zu warten, anstatt Änderungen in der „nächsten Version“ nach 8.5 vorzunehmen. Ramsey antwortete, dass es dafür keinen eindeutigen technischen oder rechtlichen Grund gebe, es sei lediglich eine intuitive Beurteilung, die auf dem Versionsrhythmus basierte, und wenn die Community der Meinung sei, dass es angemessener sei, die Änderungen in PHP 8.6 abzuschließen, werde er keine Einwände erheben. Der RFC hat die Implementierung inzwischen von „PHP 9“ auf „die nächste Version“ verschoben.

Ein anderer Entwickler, Peter Kokot, schlug vor, die Kompatibilität mit der GPL klarer zu machen, um Zweifel bei der Arbeit mit GPL-lizenzierter Software in Zukunft zu verringern. Er wies darauf hin, dass PHP beim Erstellen die Möglichkeit hat, eine Verknüpfung mit zwei GPLv3-lizenzierten Bibliotheken herzustellen: GNU Readline und GNU dbm (GDBM). Er hofft, die Option zur Verknüpfung mit diesen GPL-Bibliotheken während der Build-Phase auslaufen zu lassen, damit sich Paketierer keine Sorgen mehr über mögliche Inkompatibilitäten machen müssen, und schließlich die Möglichkeit der Verknüpfung mit GDBM und Readline ganz zu beseitigen. Ramsey antwortete, dass die Lizenz unter der bestehenden PHP-Lizenz 3.01 aufgrund einiger zusätzlicher Einschränkungen für Benutzer nicht mit der GPL kompatibel sei. Diese Unvereinbarkeit kann derzeit nicht beseitigt werden; Wenn jedoch stattdessen die Modified BSD-Lizenz verwendet wird, treten keine derartigen Kompatibilitätsprobleme auf, solange das endgültige Paket insgesamt unter den GPL-Bedingungen veröffentlicht wird, was auch die Arbeit an der Distributionspaketierung erheblich vereinfacht.

Am 14. März 2026 gab Ramsey die offizielle Eröffnung der Abstimmung zu diesem RFC bekannt. Die Ergebnisse der Abstimmung werden öffentlich auf der RFC-Seite des PHP-Wikis aufgezeichnet. Die Gesamtzahl der Stimmberechtigten ist derzeit ungewiss – eine Zählung aus dem Jahr 2019 ergab, dass damals insgesamt 180 Entwickler wahlberechtigt waren. Kurz nach Beginn der Abstimmung stimmten 47 Personen dafür, zwei enthielten sich. Erste Ergebnisse deuten darauf hin, dass die Stimmung in der Community gegenüber dem Vorschlag äußerst positiv ist, das Ergebnis kann jedoch nicht als ausgemachte Sache angesehen werden, bis der Abstimmungsprozess abgeschlossen ist. Unabhängig vom Endergebnis ist klar, dass diese Bemühungen zur Bereinigung und Straffung der Genehmigungen ohne Ramseys Kommunikation, Koordination und Unterstützung hinter den Kulissen in den letzten Jahren nicht möglich sein werden.