PHP: Vorschlag zur Umstellung der Lizenz auf BSD 3-Clause

• Im PHP-Projekt wird derzeit ein RFC diskutiert, das die bisher komplexen und inkompatiblen PHP-eigenen Lizenzen sowie die Zend-Engine-Lizenz auf BSD 3-Clause (Modified BSD License) vereinheitlichen soll
• Der neue Lizenzstandard soll ab PHP 9.0 gelten; im gesamten Quellcode, in Headern und in der Dokumentation würde dann BSD 3-Clause verwendet, während frühere Sonderklauseln und markenbezogene Einschränkungen entfallen
• Durch OSI- und FSF-Zulassung sowie GPL-Kompatibilität wird rechtliche Klarheit geschaffen; die Rechte von Mitwirkenden und Nutzern bleiben dabei unverändert gewahrt
• Für die Lizenzänderung ist die offizielle Zustimmung der PHP Group und von Perforce Software (ehemals Zend) erforderlich; nach der Community-Diskussion folgt ein Verfahren mit mehr als 6 Monaten Diskussion und Abstimmung
• Die Änderung empfiehlt auch externen Projekten wie PECL/Erweiterungen die Wahl von BSD 3-Clause; die Bezeichnung „PHP-Lizenz“ wird nicht empfohlen

---

Überblick

• Das PHP-Projekt war lange Zeit durch seine eigenen Open-Source-Lizenzen und die Zend Engine License von Verwirrung und Kontroversen geprägt
• Besonders die Zend Engine License für Quellcode im Zend-Verzeichnis machte die Lage noch komplexer, da sie keine OSI-anerkannte Lizenz ist
• Dieses RFC schlägt eine praktische Vereinfachung der Lizenzierung vor, die das Urheberrecht aller PHP-Mitwirkenden bewahrt und Nutzern zugleich dieselben Rechte wie unter den bisherigen Lizenzen einräumt
• Ziel ist es, BSD 3-Clause (Modified BSD License) als neue offizielle Lizenz einzuführen, um Rechte und Nutzungsbedingungen beizubehalten und zugleich Komplexität und Missverständnisse zu reduzieren

Vorschlag und wichtigste Änderungen

• Im Kern geht es darum, neue Versionen der PHP License und der Zend Engine License zu veröffentlichen und damit die Modified BSD License (BSD-3-Clause, von OSI und FSF anerkannt) offiziell zu übernehmen
• Die bisherige PHP License (Version 3.01) und die Zend Engine License (Version 2.00) sind abgesehen von Sonderklauseln praktisch identisch mit der Modified BSD License; die grundlegenden Rechte ändern sich daher nicht
• Nach der Lizenzaktualisierung:
  • keine Änderungen an den Rechten für Mitwirkende und Nutzer
  • Entfernung gruppenspezifischer Sonderklauseln in Zusammenarbeit mit der PHP Group und Perforce Software
  • PHP und Zend Engine werden unter einer OSI-anerkannten, GPL-kompatiblen Lizenz bereitgestellt
• Von der weiteren Nutzung der alten PHP License und Zend Engine License wird abgeraten
• Auch die Lizenz-Header in LICENSE-Dateien und im Quellcode werden durch das neue Format ersetzt

Zusammenfassung des Lizenztexts

• BSD 3-Clause erlaubt freies Kopieren, Modifizieren und Weiterverbreiten, enthält jedoch Bedingungen zu Urheberrechtshinweisen, Haftungsausschluss sowie zum Verbot unautorisierter Nutzung von Namen und Marken
• BSD-3-Clause ist eine von OSI (Open Source Initiative) und FSF anerkannte freie Softwarelizenz und GPL-kompatibel

Änderungsverfahren und Genehmigung

• Das RFC wird nach öffentlicher Diskussion in der Community per Abstimmung entschieden; nach offizieller Zustimmung und Abstimmung folgt die Umsetzung
• Die Lizenzänderung erfordert die offizielle Zustimmung der PHP Group und von Perforce Software
• Die Rechte früherer Quellcode-Mitwirkender bleiben unverändert erhalten; die Änderung verletzt keine bestehenden Rechte
• Der Community wird ein Diskussionszeitraum von mehr als 6 Monaten eingeräumt, bevor abgestimmt wird
• Die Änderung soll in PHP 9.0 offiziell übernommen werden

Hintergrund und historischer Kontext

• Die frühen Versionen PHP 1 und 2 standen unter GPL; später entwickelte sich das Projekt über die Apache-Lizenz und eine angepasste BSD-basierte Lizenz weiter
• Die Zend Engine behielt zwar eine separate Lizenz, wird heute jedoch faktisch als Teil eines untrennbaren gemeinsamen Projekts betrachtet
• Die Einschränkungen der bisherigen PHP-Lizenz bei der Nutzung des Namens sowie Klauseln zum Markenschutz haben wiederholt Probleme bei Kompatibilität und Distribution mit anderer Open-Source-Software verursacht

Auswirkungen auf bestehenden Code, Erweiterungen und Dokumentation

• Dieses RFC gilt für das gesamte php-src (ausgenommen Code mit explizit anderer Lizenz); auch PECL/Erweiterungen wird die Einführung von BSD 3-Clause empfohlen
• Betroffen ist sämtlicher Code in neuen und bestehenden PHP-Source-Repositories, der unter der PHP License oder Zend Engine License steht
• Bereits bestehende Lizenzen (z.B. timelib und anderer separat lizenzierter Code) sind von dieser Änderung nicht betroffen
• Das PHP-Handbuch bleibt weiterhin unter der Lizenz Creative Commons Attribution 3.0 oder höher
• Bestehende Erweiterungsmodule/Software erhalten die Wahlmöglichkeit, PHP License v4 (Modified BSD) zu verwenden
• Für künftige Erweiterungen und neue Projekte wird die Nutzung aktueller anerkannter Lizenzen wie BSD oder Apache empfohlen

Fazit

• Die Lizenzstruktur von PHP und Zend Engine wird auf 3-clause BSD vereinfacht, was Klarheit, Kompatibilität, kommerzielle Nutzungsmöglichkeiten und rechtliche Stabilität im Open-Source-Ökosystem stärken dürfte
• Wird der Vorschlag genehmigt und umgesetzt, können Nutzer PHP und Zend Engine nach den Bedingungen von BSD-3-Clause frei verwenden
• Nach Zustimmung von Mitwirkenden, Community und wichtigen Unternehmen sowie dem Abschluss des Abstimmungsverfahrens soll die Änderung offiziell in Kraft treten

[GN⁺]

Hacker-News-Kommentare

• Es wird darauf hingewiesen, dass die von Meta verwendete Sprache nicht PHP, sondern Hack ist. Zugleich wird erwähnt, dass Packaging, Dokumentation und Verfügbarkeit von Hack eher schwach sind. Als Grund wird genannt, dass diese Aspekte innerhalb von Meta nicht sichtbar seien und daher nicht in Leistungsbewertungen einflössen. Außerdem wird angemerkt, dass das Zurückhalten internen Wissens direkt mit Jobsicherheit verbunden sei. Aus Lizenzsicht wird zudem darauf hingewiesen, dass große IT-Unternehmen wie Meta, Google, Microsoft und Apple die Nutzung von AGPL-Software strikt verbieten. Grund dafür sei, dass sie wegen der Unschärfe der Klausel zu „Remote Network Interaction“ kein rechtliches Risiko eingehen wollten. Ergänzend wird vorgeschlagen: Wenn man wirklich möchte, dass große Unternehmen oder gewöhnliche kommerzielle Anbieter den eigenen Code auf keinen Fall nutzen, sollte man AGPL wählen. Siehe dazu: Googles AGPL-Policy-Dokument
  • Es wird betont, dass viele Unternehmen AGPL-Software tatsächlich intern verwenden, etwa Grafana, Mastodon oder Mattermost. Nur als Dienst für zahlende externe Kunden werde sie seltener eingesetzt. Als Entwickler sei einem die Freiheit der Nutzer der eigenen Software wichtiger als die überzogene Vorsicht riesiger Konzerne.
  • Es wird darauf hingewiesen, dass nicht „alle Unternehmen“, sondern nur „Unternehmen, die mit meiner Software einen proprietären Netzwerkdienst anbieten“, von der AGPL betroffen sind. Genau das sei die Kernabsicht der AGPL. Auch Googles Policy nenne ausdrücklich, dass der Grund in der Rolle als Netzwerkanbieter liege. Auf die meisten nichttechnischen Unternehmen habe das keinerlei Auswirkungen, und sie müssten sich darüber keine Gedanken machen.
  • Für Open-Source-Startups wird empfohlen, AGPL plus kommerzielle Dual-Lizenzierung zu verwenden, idealerweise mit einer CLA zur Übertragung von IP-Rechten, wenn man verhindern will, von Megaclouds wie AWS vereinnahmt zu werden.
  • Es wird erklärt, dass viele Großunternehmen AGPL-Software nutzen, weil Dual Licensing möglich ist. Man kann also mit AGPL als Open Source werben und Kunden bei Nutzung unter einer kommerziellen Lizenz zugleich Gebühren berechnen.
  • Jemand merkt an, in letzter Zeit häufig Go zu sehen; viele Pakete wirkten auf ihn so, als seien sie in Go neu geschrieben worden.
• Es wird als sehr positiv empfunden, dass die Informationen zur PHP-Lizenz und ihrer Geschichte hier an einem Ort zusammengetragen sind, ohne Marketing oder AI-generierte Inhalte.
  • Dazu kommt die heitere Bemerkung, dass AI-generierte Inhalte in Wahrheit keine zusätzlichen Informationen liefern und überflüssiges Gerede schon immer existiert habe; im Kern sei daran nichts wirklich neu.
• Jemand erinnert sich daran, vor 25 Jahren beim direkten Studium des Quellcodes der PHP Zend Engine zum ersten Mal im Leben einem Triple-Pointer (zval***) begegnet zu sein. Danach habe er mit PHP vieles gemacht und sogar als Gymnasiast bei Programmierwettbewerben im CLI-Umfeld mit PHP teilgenommen, sei damals aber ausgeschieden, weil die Betreuer mit Sprache und Umgebung nicht vertraut gewesen seien. Er drückt seine Dankbarkeit für die Möglichkeiten aus, die PHP ihm damals eröffnet habe.
  • Die Geschichte wird als unterhaltsam empfunden; jemand anderes teilt, dass er für sein Abschlussprojekt Perl verwendet habe.
  • Es wird gesagt, dass sich für dreifache „nackte“ Pointer kaum ein logisch überzeugender Anwendungsfall finden lasse. Noch vor Performance-Fragen sei die Komplexität impliziter Indirektion schwer zu rechtfertigen. Etwas Klares wie ein struct-Member könne man noch verstehen, doch zusätzliche Komplexität ohne Not sei unvernünftig. In Erinnerung bleibt der häufige Satz eines Bekannten: „Warum ist es nicht einfach?“
• Es gibt die Sorge, dass böswillige Beitragende Probleme verursachen könnten, wenn nicht die Zustimmung aller Mitwirkenden eingeholt wird. In den USA und anderswo seien Schikaneklagen jederzeit möglich, und alle müssten sich auf eigene Kosten verteidigen. Das führe letztlich zu einer Kultur übertriebener rechtlicher Absicherung. Nebenbei wird die klassische Anekdote über Richard Stallman, PHPs Verwendung der GPL und das dadurch beendete Dual Licensing erwähnt.
  • Es wird erklärt, dass die PHP Group dank der „or later“-Klausel den Lizenztext ändern und neue Versionen veröffentlichen könne, ohne eine gesonderte Zustimmung der Beitragenden einzuholen.
  • Es wird angemerkt, dass die in der Hauptquelle erwähnte Lizenzanekdote mit Stallman in Wirklichkeit eher mit MySQLs Umstellung auf GPL und deren Einfluss auf die PHP-Lizenz zu tun habe. Es wird Unverständnis darüber geäußert, warum man die GPL verwerfen sollte, nur weil Stallman sie nicht mochte.
• Den Hintergrund kann man im Hintergrunddokument zur Lizenzänderung im PHP-Wiki nachlesen.
• Die Seite wird ausdrücklich als Pflichtlektüre empfohlen, wenn man Fachwissen über Softwarelizenzen und deren Änderungen aufbauen möchte. Zugleich wird betont, dass diese Lizenzänderung für uns keine Änderungen oder Re-Zertifizierungen erforderlich macht und weder Beitragende noch Nutzer betroffen sind.
  • Mit humorvoller Bodenhaftung wird angemerkt, dass Meldungen über „Änderungen ohne große Auswirkungen“ in der Realität auch schon massive Folgen hatten, als Beispiel werden die 787MAX- und MCAS-Vorfälle genannt.
  • Es wird im Detail erklärt, dass tatsächlich Formulierungen zu den Marken PHP/Zend entfernt werden und die beiden Projekte in einer einzigen Lizenz zusammengeführt werden. Konkret brauchte man bisher für die Verwendung der Bezeichnungen „PHP“, „Zend“ und „Zend Engine“ jeweils eigene Genehmigungen; künftig werde dies einheitlich auf die Namen von Rechteinhabern und Beitragenden angewendet. Außerdem würden die Klauseln zu Kennzeichnung, Überarbeitung, Zertifizierung und Benachrichtigung (Nr. 4 bis 6) mit entfernt.
• Es wird die Frage gestellt, warum in Lizenztexten wichtige Passagen vollständig in Großbuchstaben (ALL CAPS) geschrieben werden.
  • Nach US-Recht müssten Haftungs- und Gewährleistungsausschlüsse „conspicuous“ sein, also deutlich auffallen. In Fließtext sei Großschreibung das einfachste Mittel dafür.
  • Es wird gesagt, dies sei auch eine Methode, die Debatte über Groß- und Kleinschreibung selbst zu beenden. Wenn alle Wörter großgeschrieben seien, werde alles gleichermaßen hervorgehoben, was Verwirrung reduziere.
  • Nach Bestimmungen des Handelsrechts (UCC) müsse der Text so formuliert sein, dass eine vernünftige Person ihn zwingend wahrnehmen kann; eine Möglichkeit dafür seien große Überschriften in Großbuchstaben. Wenn also der ganze Abschnitt in Großbuchstaben geschrieben ist, könne ein Gericht ihn eher als „auffällig“ einstufen.
• Jemand bittet darum, dass eine sachkundige Person die Änderung auf ELI5-Niveau erklärt, und fragt sich, ob die Lizenz von PHP insgesamt geändert wird.
  • Es wird nachgefragt, was genau mit „ganz PHP“ gemeint sei, und erklärt, dass die Änderung die Sprache selbst betrifft, also Interpreter, Runtime und Standardbibliothek.
• Es wird gefragt, warum nicht einfach die MIT-Lizenz verwendet wird, die doch viel einfacher sei.
  • Es wird zurückgefragt, ob der Unterschied zwischen MIT und BSD-3-Klausel in der Praxis wirklich spürbar einfacher sei, und ob es zwischen der MIT-Lizenz und der BSD-3-Klausel-Lizenz überhaupt einen bedeutenden Unterschied gibt.