PHP est un projet avec un lourd « bagage historique » en termes de problèmes de licence depuis de nombreuses années, et maintenant il se prépare à un nettoyage important et approfondi : une proposition menée par un membre de la communauté Ben Ramsey, prévoit d'abandonner les deux ensembles de licences personnalisées actuellement utilisées - la licence PHP 3.01 couvrant la majeure partie du code et la licence Zend 2.0 pour le code de l'annuaire Zend - et d'adopter BSD dans les versions futures. Licence à trois clauses (BSD modifiée). Actuellement, la communauté PHP vote sur cette RFC "PHP License Update", qui durera jusqu'au 4 avril 2026.
Dans les premiers stades de développement de PHP, le projet a changé de licence assez fréquemment : de 1995 à En 2006, PHP a subi un total de sept modifications de licence ou ajustements des conditions. Initialement, PHP était publié sous GPLv2 ; PHP 3, sorti en 1998, a adopté une méthode de double autorisation GPLv2 et la nouvelle licence PHP. Cette nouvelle licence était basée sur la licence Apache 1.0 et a été formulée par le fondateur de PHP, Rasmus Lerdorf, afin de rendre PHP plus « convivial » pour les utilisateurs commerciaux tout en conservant les attributs du logiciel libre. Lerdorf avait déclaré à l'époque qu'il espérait garantir que PHP reste gratuit afin que les entreprises commerciales puissent essayer des versions commerciales sans que les principaux contributeurs se sentent « exploités ».
Cependant, la version originale de la licence PHP personnalisée incluait une clause exigeant l'autorisation écrite de l'équipe de développement PHP pour la redistribution commerciale, ce qui s'est avéré difficile à utiliser dans la pratique et a finalement été supprimé dans la version PHP 3.0.14. Le fichier LICENSE fourni avec cette version n'indique même pas le numéro de version de la licence.
PHP 4.0, sorti en mai 2000, était une refactorisation majeure qui a introduit le moteur Zend écrit par Zeev Suraski et Andi Gutmans, qui ont ensuite fondé Zend Technologies dans l'espoir de commercialiser le moteur Zend sur une voie indépendante de PHP. Zend fournit des licences aux projets PHP pour intégrer le moteur Zend dans PHP, et promet que le code concerné restera sous la licence Zend ou d'autres licences compatibles avec la définition Open Source (OSD), bien que la licence Zend elle-même n'ait pas été officiellement approuvée par l'Open Source Initiative (OSI). Depuis, le code du répertoire Zend dans l'arborescence des sources PHP a adopté la licence Zend ; PHP 4.0 a également complètement abandonné la GPLv2 et adopté la licence PHP 2.02.
Au cours des années suivantes, la licence PHP a continué à être peaufinée : la version PHP 3.0 de la licence a été approuvée par l'OSI, mais une modification mineure a ensuite été apportée pour former la licence PHP 3.01. Cette modification ajuste uniquement l'année du droit d'auteur et la façon dont le texte de reconnaissance pour PHP et Zend est exprimé, mais ne change pas les droits de licence eux-mêmes. Cependant, cette nouvelle version n’a jamais été révisée par OSI. Pour rendre les choses encore plus troublantes, le texte de la licence ne s'applique apparemment qu'aux logiciels publiés par le « Groupe PHP », qui lui-même n'est pas une véritable entité juridique mais une liste de dix premiers développeurs PHP. Cette ambiguïté a amené certaines personnes à croire que les logiciels publiés par d'autres entités ne peuvent pas légalement utiliser la licence PHP comme texte d'autorisation, causant ainsi des problèmes pratiques pour des projets tels que Debian. Ramsey expose ce contexte historique spécifiquement dans RFC .
Dans la RFC actuelle, Ramsey a proposé qu'à partir de la prochaine version majeure (écrite à l'origine comme PHP 9.0, mise à jour plus tard vers "la prochaine version de PHP"), la licence PHP et la licence Zend actuelles seront uniformément remplacées par la licence BSD à trois clauses. Il a déclaré qu'en rédigeant la proposition, il avait travaillé avec la présidente du comité des licences de l'OSI, Pamela Chestek, pour résoudre les problèmes et questions juridiques pertinents.
Ramsey a déclaré qu'il avait communiqué avec tous les membres du groupe PHP et que chaque membre avait exprimé son soutien à ce changement. Dans le même temps, il a également acquis une licence auprès de Perforce Software - Perforce a placé Zend sous son égide en 2019 grâce à l'acquisition de Rogue Wave, qui a acquis Zend en 2015. On pourrait se demander : étant donné que tant de personnes ont soumis du code à PHP au fil des ans, chaque contributeur doit-il être d'accord avant que la licence puisse être modifiée ? Dans la RFC, le point de Ramsey est le suivant : Non. PHP n'exige pas que les contributeurs signent un CLA qui transfère les droits d'auteur sur le projet, donc les contributeurs conservent les droits d'auteur de leur code contribué ; mais à condition qu'ils n'énoncent pas explicitement d'autres conditions de licence, ils peuvent être considérés comme accordant au projet le droit d'utiliser leurs contributions dans le cadre de la licence actuelle du projet.
En d'autres termes, les contributeurs détiennent les droits d'auteur sur le code qu'ils soumettent, mais si aucune autre licence n'est spécifiée, leurs contributions sont autorisées à être utilisées par le projet selon la licence adoptée par le projet. Ramsey a en outre souligné que, généralement, lors du changement de licence d'un projet open source, le consentement de tous les détenteurs de droits d'auteur est requis, car la nouvelle licence peut modifier l'étendue des droits accordés aux utilisateurs. Mais dans ce cas, le passage à la licence BSD à trois clauses ne change pas les droits accordés aux contributeurs autres que PHP Group et Perforce Software. Par conséquent, il estime que les projets n’ont pas besoin de demander l’autorisation explicite de tous les contributeurs individuellement.
Bien que le RFC note que le consentement individuel n'est pas légalement requis, Ramsey a proposé par « courtoisie » que la période de discussion soit maintenue pendant au moins six mois pour garantir que toutes les parties prenantes aient une opportunité adéquate d'exprimer leurs points de vue. Depuis que la RFC a été proposée en juillet 2025, il a publié plusieurs mises à jour et a rappelé à la communauté que le sujet est toujours en discussion ; Pour l’instant, aucune objection de fond n’a été soulevée.
Certaines questions spécifiques ont également émergé au cours de la discussion. Par exemple, Derick Rethans a demandé pourquoi il était nécessaire d'attendre PHP 9 au lieu d'apporter des modifications dans la "prochaine version" après la 8.5. Ramsey a répondu qu'il n'y a aucune raison technique ou juridique à cela, c'est juste un jugement intuitif basé sur le rythme des versions, et si la communauté estime qu'il est plus approprié de compléter les modifications dans PHP 8.6, il ne s'y opposera pas. La RFC a depuis déplacé l'implémentation de « PHP 9 » vers « la version suivante ».
Un autre développeur, Peter Kokot, a suggéré que la compatibilité avec la GPL devrait être plus claire afin de réduire les doutes lors de l'utilisation future de logiciels sous licence GPL. Il a noté que PHP a la possibilité de se lier à deux bibliothèques sous licence GPLv3 lors de la construction : GNU Readline et GNU dbm (GDBM). Il espère supprimer progressivement l'option de liaison avec ces bibliothèques GPL pendant la phase de construction afin que les packageurs n'aient plus à se soucier des incompatibilités potentielles, et éventuellement supprimer complètement la possibilité de créer des liens avec GDBM et Readline. Ramsey a répondu qu'en vertu de la licence PHP 3.01 existante, en raison de certaines restrictions supplémentaires imposées aux utilisateurs, la licence est incompatible avec la GPL. Cette incompatibilité ne peut être éliminée à l'heure actuelle ; cependant, si la licence BSD modifiée est utilisée à la place, tant que le package final est publié sous les termes GPL dans son ensemble, il n'y aura pas de tels problèmes de compatibilité, ce qui simplifiera également considérablement le travail de packaging de distribution.
Le 14 mars 2026, Ramsey a annoncé l'ouverture officielle du vote sur cette RFC. Les résultats du vote sont enregistrés publiquement sur la page RFC du PHP Wiki. Le nombre total de personnes ayant le droit de vote est actuellement incertain : selon un décompte de 2019, 180 développeurs avaient alors le droit de voter. Peu de temps après le début du vote, 47 personnes ont voté pour et deux se sont abstenues. Les premiers résultats indiquent que le sentiment de la communauté à l'égard de la proposition est très positif, mais le résultat ne peut être considéré comme acquis tant que le processus de vote n'est pas terminé. Quel que soit le résultat final, il est clair que cet effort de nettoyage et de rationalisation des permis ne sera pas possible sans la communication, la coordination et la facilitation en coulisses de Ramsey au cours des dernières années.