PHP-project is al vele jaren een project met zware "historische bagage" in termen van licentieproblemen, en nu bereidt het zich voor op een belangrijke en grondige opschoning: een voorstel geleid door gemeenschapslid Ben Ramsey, is van plan om de twee sets aangepaste licenties die momenteel worden gebruikt - PHP-licentie 3.01 die het grootste deel van de code omvat en Zend-licentie 2.0 voor Zend-directorycode - te verlaten en BSD in toekomstige versies over te nemen. Licentie met drie clausules (gewijzigde BSD). Momenteel stemt de PHP-gemeenschap over deze RFC "PHP License Update", die zal duren tot 4 april 2026.
In de vroege ontwikkelingsfasen van PHP veranderde het project de licentie vrij vaak: van Tussen 1995 en 2006 onderging PHP in totaal zeven licentiewijzigingen of aanpassingen van de voorwaarden. Aanvankelijk werd PHP uitgebracht onder GPLv2; PHP 3, uitgebracht in 1998, heeft een dubbele autorisatiemethode van GPLv2 en de nieuwe PHP-licentie aangenomen. Deze nieuwe licentie was gebaseerd op de Apache-licentie 1.0 en werd geformuleerd door PHP-oprichter Rasmus Lerdorf om PHP "vriendelijker" te maken voor commerciële gebruikers, terwijl de kenmerken van vrije software behouden bleven. Lerdorf zei destijds dat hij hoopte ervoor te zorgen dat PHP gratis blijft, zodat commerciële bedrijven commerciële versies kunnen uitproberen zonder dat grote bijdragers zich "misbruikt" voelen.
De originele versie van de aangepaste PHP-licentie bevatte echter een clausule die schriftelijke toestemming van het PHP-ontwikkelteam vereiste voor commerciële herdistributie, wat in de praktijk lastig bleek te werken en uiteindelijk werd verwijderd in PHP-versie 3.0.14. Het LICENSE-bestand dat bij deze release wordt geleverd, geeft niet eens het licentieversienummer aan.
PHP 4.0, uitgebracht in mei 2000, was een ingrijpende refactoring die de Zend-engine introduceerde, geschreven door Zeev Suraski en Andi Gutmans, die later Zend Technologies oprichtten in de hoop de Zend-engine te commercialiseren op een pad dat onafhankelijk is van PHP. Zend levert licenties aan PHP-projecten om de Zend-engine in PHP te integreren, en belooft dat de relevante code onder de Zend-licentie of andere licenties zal blijven die consistent zijn met de Open Source Definition (OSD), hoewel de Zend-licentie zelf niet officieel is goedgekeurd door het Open Source Initiative (OSI). Sindsdien heeft de code in de Zend-directory in de PHP-bronboom de Zend-licentie overgenomen; PHP 4.0 heeft GPLv2 ook volledig verlaten en PHP-licentie 2.02 overgenomen.
In de daaropvolgende jaren werd de PHP-licentie verder verfijnd: de PHP 3.0-versie van de licentie werd goedgekeurd door OSI, maar vervolgens werd een kleine wijziging aangebracht om PHP-licentie 3.01 te vormen. Deze wijziging wijzigt alleen het copyrightjaar en de manier waarop de bevestigingstekst voor PHP en Zend wordt uitgedrukt, maar verandert niets aan de licentierechten zelf. Deze nieuwe versie is echter nooit meer door OSI beoordeeld. Om de zaken nog verontrustender te maken: de licentietekst is ogenschijnlijk alleen van toepassing op software die is uitgebracht door de "PHP Group", die zelf geen echte juridische entiteit is, maar een lijst van tien vroege PHP-ontwikkelaars. Deze dubbelzinnigheid heeft ertoe geleid dat sommige mensen geloven dat software die door andere entiteiten is uitgegeven, de PHP-licentie niet legaal als autorisatietekst kan gebruiken, wat praktische problemen veroorzaakt voor projecten als Debian. Ramsey belicht deze historische achtergrond specifiek in RFC.
In de huidige RFC stelde Ramsey voor dat vanaf de volgende hoofdversie (oorspronkelijk geschreven als PHP 9.0, later bijgewerkt naar "de volgende versie van PHP"), de huidige PHP-licentie en Zend-licentie uniform zullen worden vervangen door de BSD-licentie met drie clausules. Hij zei dat hij bij het schrijven van het voorstel had samengewerkt met Pamela Chestek, voorzitter van de OSI Licensing Committee, om relevante juridische kwesties en vragen te beantwoorden.
Ramsey zei dat hij met alle leden van de PHP Group heeft gecommuniceerd en dat elk lid zijn steun voor deze wijziging heeft uitgesproken. Tegelijkertijd verwierf hij ook een licentie van Perforce Software - Perforce bracht Zend in 2019 onder zijn paraplu door de overname van Rogue Wave, dat Zend in 2015 overnam. Je zou je kunnen afvragen: aangezien zoveel individuen door de jaren heen code naar PHP hebben ingediend, moet elke bijdrager ermee instemmen voordat de licentie kan worden gewijzigd? In de RFC is het punt van Ramsey: Nee. PHP vereist niet dat bijdragers een CLA ondertekenen die het auteursrecht op het project overdraagt, dus behouden bijdragers het auteursrecht van hun bijgedragen code; maar op voorwaarde dat ze niet expliciet andere licentievoorwaarden vermelden, kunnen ze worden beschouwd als het verlenen van het recht aan het project om hun bijdragen te gebruiken onder de huidige licentie van het project.
Met andere woorden: bijdragers bezitten het auteursrecht op de code die zij indienen, maar als er geen andere licentie is gespecificeerd, zijn hun bijdragen geautoriseerd voor gebruik door het project volgens de licentie die door het project is aangenomen. Ramsey wees er verder op dat bij het wijzigen van de licentie van een open source-project doorgaans de toestemming van alle auteursrechthouders vereist is, omdat de nieuwe licentie de reikwijdte van de aan gebruikers verleende rechten kan veranderen. Maar in dit geval verandert de overstap naar de BSD-licentie met drie clausules niets aan de rechten die zijn verleend aan andere bijdragers dan PHP Group en Perforce Software. Daarom is hij van mening dat projecten niet expliciet toestemming hoeven te vragen aan alle bijdragers afzonderlijk.
Hoewel de RFC opmerkt dat individuele toestemming niet wettelijk vereist is, stelde Ramsey uit “hoffelijkheid” voor om de discussieperiode ten minste zes maanden te handhaven om ervoor te zorgen dat alle belanghebbenden voldoende gelegenheid hebben om hun mening te uiten. Sinds de RFC in juli 2025 werd voorgesteld, heeft hij meerdere updates uitgebracht en de gemeenschap eraan herinnerd dat het onderwerp nog steeds ter discussie staat; tot nu toe zijn er geen inhoudelijke bezwaren gerezen.
Tijdens de discussie kwamen ook enkele specifieke kwesties naar voren. Derick Rethans vroeg bijvoorbeeld waarom het nodig was om te wachten tot PHP 9 in plaats van wijzigingen aan te brengen in de "volgende versie" na 8.5. Ramsey antwoordde dat hier geen harde technische of juridische reden voor is, het is slechts een intuïtief oordeel gebaseerd op versieritme, en als de gemeenschap vindt dat het passender is om de wijzigingen in PHP 8.6 te voltooien, zal hij geen bezwaar maken. De RFC heeft sindsdien de implementatie verplaatst van "PHP 9" naar "de volgende versie".
Een andere ontwikkelaar, Peter Kokot, suggereerde dat compatibiliteit met de GPL duidelijker moet worden gemaakt om twijfels te verminderen bij het werken met GPL-gelicentieerde software in de toekomst. Hij merkte op dat PHP de mogelijkheid heeft om tijdens het bouwen te koppelen met twee GPLv3-gelicentieerde bibliotheken: GNU Readline en GNU dbm (GDBM). Hij hoopt de optie om tijdens de bouwfase te koppelen aan deze GPL-bibliotheken geleidelijk af te schaffen, zodat pakketmakers zich niet langer zorgen hoeven te maken over mogelijke incompatibiliteiten, en uiteindelijk de mogelijkheid om te koppelen aan GDBM en Readline helemaal te elimineren. Ramsey antwoordde dat de licentie onder de bestaande PHP-licentie 3.01, vanwege enkele aanvullende beperkingen voor gebruikers, niet compatibel is met de GPL. Deze onverenigbaarheid kan momenteel niet worden geëlimineerd; Als in plaats daarvan echter de gewijzigde BSD-licentie wordt gebruikt, zullen er, zolang het uiteindelijke pakket in zijn geheel onder de GPL-voorwaarden wordt vrijgegeven, geen dergelijke compatibiliteitsproblemen optreden, wat ook het distributiepakketwerk aanzienlijk zal vereenvoudigen.
Op 14 maart 2026 kondigde Ramsey de officiële opening van de stemming over deze RFC aan. De resultaten van de stemming worden openbaar vastgelegd op de RFC-pagina van de PHP Wiki. Het totale aantal mensen met stemrecht is momenteel onzeker; volgens een telling uit 2019 kwamen op dat moment in totaal 180 ontwikkelaars in aanmerking om te stemmen. Kort nadat de stemming begon, stemden 47 mensen vóór en twee onthielden zich van stemming. De eerste resultaten geven aan dat het sentiment onder de gemeenschap ten opzichte van het voorstel zeer positief is, maar de uitkomst kan pas als een uitgemaakte zaak worden beschouwd als het stemproces is voltooid. Ongeacht het uiteindelijke resultaat is het duidelijk dat deze inspanningen om vergunningen op te schonen en te stroomlijnen niet mogelijk zullen zijn zonder Ramsey’s communicatie, coördinatie en facilitering achter de schermen van de afgelopen jaren.