PHP 8.6 will officially adopt the BSD 3-clause license, ending a 20-year regime of custom licensing that included a separate license for the Zend engine. The PHP Group has formally requested the Open Source Initiative (OSI) retire the old licenses, which had long blocked adoption in environments requiring OSI approval or GPL compatibility.

The project’s licensing history traces back to PHP 1 and 2 released under GPLv2. PHP 3 (1998) introduced a custom license inspired by Apache 1.0, with two key differences: prior written permission was required for commercial redistribution, and the clause barring derivative works from using the PHP name was omitted—intended to allow commercial forks while protecting contributors. The hybrid system proved legally burdensome, leading to revisions in PHP 3.0.1 (allowing the PHP name to indicate module support) and 3.0.14 (removing the commercial redistribution permission requirement). The GPL option disappeared after a disagreement with Richard Stallman, the details of which remain undisclosed.

PHP 4.0 (2000) further modified the license, dropping the requirement that advertising mentioning PHP include the project URL, and granting the PHP Group the right to revise the license at any time without notice, provided changes preserved its free and open-source nature. Meanwhile, a separate Zend Engine license was created for distributions where the engine was used standalone (e.g., embedded in MySQL), while the PHP license applied to bundled distributions. In 2002, PHP 4.2.3 made the Zend license mandatory for code in the Zend/ directory, removed the module-naming exception, and prohibited derivatives from being called PHP.

The push for change accelerated after an Oracle engineer revealed in a 2020 mailing list post that the company refused to allow use of phpdbg without OSI approval, which the PHP licenses had never secured. PHP community leader Ben Ramsey heard the story, initiated OSI engagement, and later called it the “seed” for the formal migration effort he launched in summer 2025.

Ramsey argued that the deep intertwining of PHP and Zend code made separate licenses obsolete, and that the clause forbidding derivatives from using the PHP name created ambiguity for Linux distributions. Moreover, neither license was GPL-compatible, and the Zend license was never OSI-approved. Because only the PHP Group held the authority to change the license, individual member approvals were sought, along with consent from Perforce Software (parent of Zend Technologies). A community vote was held as a non-binding gesture: 51 in favor, 2 abstentions.

The core changes simply strip out the PHP Group- and Zend-specific conditions, leaving contributor and user rights intact. Removed from the PHP license are: the prohibition on derivatives using the PHP name without written consent, the PHP Group’s right to unilaterally revise the license, and the requirement to include the project URL in redistributions. From the Zend license, removed are: Zend’s right to revise the license, the URL redistribution requirement, and the obligation to mention the project in advertising materials. Existing users of extensions or software under the old PHP license can now transition to BSD 3-clause, and maintainers may do the same.

C’est officiel : PHP 8.6 sera sous licence BSD 3 clauses.

Le projet vient de soumettre à l’OSI une demande formelle de retrait de la licence précédente, en place depuis plus de 20 ans. Ou plutôt des licences. Il y en a effectivement une spécifique au moteur Zend.

Cette distinction n’a pas toujours été. Dans les années 90, PHP 1 puis PHP 2 furent publiés sous GPLv2.

PHP 3, lancé en 1998, avait conservé cette option et y avait ajouté une licence custom. Celle-ci s’inspirait d’Apache 1.0, avec deux différences majeures. D’une part, une exigence de permission écrite préalable pour toute redistribution commerciale. De l’autre, l’omission de la clause interdisant de donner aux produits dérivés le nom du projet. L’idée était d’ouvrir la porte à des versions commerciales tout en assurant que les principaux contributeurs ne seraient pas lésés.

Ce système « à la carte » s’est révélé difficile à gérer pour le PHP Group sur le plan juridique (manque de bande passante, notamment pour fournir les accords écrits). Dans ce contexte, deux révisions intervinrent, avec PHP 3.0.1 puis 3.0.14. La première avait autorisé l’usage du nom PHP pour indiquer sa prise en charge par des modules complémentaires. La seconde avait supprimé l’exigence – problématique, donc – de permission écrite pour la redistribution commerciale. Le résultat se rapprochait de la licence Apache 1.0. En complément, l’option GPL avait disparu, sur fond de désaccord avec Richard Stallman (on en ignore la teneur).

La double licence, produit de l’an 2000

En 2000, la sortie de PHP 4.0 s’était accompagnée d’autres changements dans la licence. D’un côté, la suppression de la clause imposant que tout support publicitaire mentionnant les fonctionnalités ou l’usage de PHP affiche l’URL du projet. De l’autre, l’ajout d’une clause donnant au PHP Group le droit de modifier la licence à tout moment et sans préavis, aussi longtemps que les changements conservaient la nature libre et open source de PHP.

La licence Zend avait émergé en parallèle. Elle s’appliquait à toute distribution séparée du moteur (ses fondateurs songeaient par exemple à l’embarquer dans MySQL). La licence PHP pouvait continuer à s’appliquer en cas de distribution groupée (bundling).

Les choses avaient changé en 2002 avec PHP 4.2.3. Le code source localisé dans le répertoire Zend/ devenait systématiquement couvert par la licence spécifique au moteur. Par ailleurs, l’exception pour les modules complémentaires disparaissait. Et les dérivés n’avaient plus le droit de se nommer PHP.

Un blocage chez Oracle présenté comme le déclencheur

En 2006, avec la sortie de PHP 5.1.2 et 4.4.2, la licence avait subi des modifications mineures. Découlant essentiellement de débats avec la communauté Debian sur le packaging de PHP (distribution de patchs, donc d’un dérivé, soumis à l’interdiction d’exploiter la marque), elles suffirent toutefois à bloquer des développements, faute d’approbation par l’OSI. Chez Oracle, par exemple. Début 2020, un ingé s’en était fait l’écho sur la mailing list php-general. Il souhaitait exploiter phpdbg (débogueur interactif), mais l’entreprise ne voulait pas lui donner le feu vert sans l’approbation en question.

En ayant eu vent, Ben Ramsey, ponte de la communauté PHP, avait effectué les démarches auprès de l’OSI. Mais cela a surtout, explique-t-il désormais, « semé une graine ». Celle qui allait le pousser à emmener, formellement à partir de l’été 2025, l’initiative de basculement vers la BSD 3 clauses.

L’intrication croissante entre PHP et Zend ne justifiait plus l’existence de licences séparées, estime l’intéressé. La clause empêchant les produits dérivés de se nommer PHP a créé de l’ambiguïté pour les distributions Linux, souligne-t-il aussi. Tout en rappelant qu’aucune licence n’était compatible GPL… et que l’OSI n’a jamais approuvé celle de Zend.

Comme seul le PHP Group avait le pouvoir de modifier la licence de PHP, il a fallu obtenir, au cas par cas, l’accord de ses membres. Il a également fallu obtenir celui de Perforce Software, dont Zend Technologies est aujourd’hui filiale. Mais pas celui des contributeurs, la licence ne l’imposant pas (il y a tout de même eu un vote communautaire, à 51 pour et 2 abstentions).

Une histoire de suppression de conditions spécifiques

Au final, les modifications ont, dans les grandes lignes, consisté à retirer les conditions spécifiques au PHP Group et à Zend. Sans changer les droits des contributeurs ni des utilisateurs.

Supprimé côté licence PHP :

Interdiction, pour les dérivés, de se nommer PHP sans accord écrit du PHP Group

Autorité du PHP Group pour réviser la licence

Renvoi URL vers le projet PHP dans le cadre de toute redistribution

Supprimé côté licence Zend :

Autorité de Zend pour réviser la licence

Renvoi URL vers le projet Zend dans le cadre de toute redistribution

Mention et renvoi URL sur les supports publicitaires

Les utilisateurs d’extensions ou d’autres logiciels publiés sous la version précédente de la licence PHP peuvent choisir de passer sous la BSD 3 clauses. Les mainteneurs peuvent faire de même.

Illustration générée par IA

The post PHP finalise son retour à une licence « GPL-compatible » appeared first on Silicon.fr.