PHP : proposition de passer la licence à BSD 3-Clause

• Le projet PHP discute d'une RFC visant à unifier la licence historique propre à PHP, complexe et incompatible, ainsi que la licence du Zend Engine sous BSD 3-Clause (licence BSD modifiée)
• Le nouveau cadre de licence s'appliquerait à partir de PHP 9.0 ; BSD 3-Clause serait alors reflétée dans l'ensemble du code source, des en-têtes et de la documentation, tandis que les clauses spéciales historiques et les restrictions liées à la marque disparaîtraient
• L'approbation par l'OSI et la FSF, ainsi que la compatibilité GPL, apporteraient une clarté juridique, sans modifier les droits garantis aux contributeurs et aux utilisateurs
• Pour modifier la licence, l'accord officiel du PHP Group et de Perforce Software (anciennement Zend) est nécessaire ; après les discussions communautaires, une période de débat de plus de six mois et une procédure de vote sont prévues
• Ce changement recommande aussi aux projets externes comme PECL/les extensions d'opter pour BSD 3-Clause, et déconseille l'usage de la « licence PHP »

---

Vue d'ensemble

• Le projet PHP traîne depuis longtemps confusion et controverses à cause de sa propre licence open source et de la Zend Engine License
• En particulier, la Zend Engine License appliquée au code source du répertoire Zend ajoute de la complexité car elle n'est pas approuvée par l'OSI
• Cette RFC propose une simplification pragmatique des licences qui préserve les droits d'auteur de tous les contributeurs PHP tout en accordant aux utilisateurs les mêmes droits que les licences actuelles
• L'objectif est d'adopter BSD 3-Clause (licence BSD modifiée) comme nouvelle licence officielle afin de conserver les droits et conditions d'usage tout en réduisant la complexité et les malentendus

Proposition et principaux changements

• Le cœur de la proposition consiste à publier de nouvelles versions de la PHP License et de la Zend Engine License afin d'adopter officiellement la Modified BSD License (BSD-3-Clause, approuvée à la fois par l'OSI et la FSF)
• La PHP License existante (version 3.01) et la Zend Engine License (version 2.00) sont en pratique équivalentes à la Modified BSD, à l'exception de clauses particulières, sans changement substantiel des autorisations
• Après cette mise à jour des licences :
  • aucun changement dans les droits accordés aux contributeurs et aux utilisateurs
  • suppression, en coopération avec le PHP Group et Perforce Software, des clauses propres à certains groupes
  • PHP et Zend Engine seraient distribués sous une licence approuvée par l'OSI et compatible GPL
• L'utilisation de l'ancienne PHP License et de la Zend Engine License est désormais déconseillée
• Le fichier LICENSE et les en-têtes de licence dans le code source seraient eux aussi remplacés par un nouveau format

Résumé du texte de la licence

• BSD 3-Clause autorise librement la copie, la modification et la redistribution, à condition de conserver les mentions de copyright et de non-responsabilité, ainsi que l'interdiction d'utiliser sans autorisation les noms et marques
• BSD-3-Clause est une licence de logiciel libre approuvée à la fois par l'OSI (Open Source Initiative) et la FSF, et elle est compatible GPL

Processus de modification et approbation

• La RFC sera tranchée par un vote après une discussion publique au sein de la communauté, puis appliquée après accord officiel et validation du vote
• La modification de licence requiert l'accord officiel du PHP Group et de Perforce Software
• Les droits des anciens contributeurs au code source restent inchangés, et la modification ne porte pas atteinte aux droits existants
• Une période de discussion de plus de six mois sera accordée à la communauté avant le vote final
• Le changement doit être officiellement intégré à PHP 9.0

Contexte et historique

• Aux débuts, PHP 1 et 2 étaient sous GPL, avant d'évoluer via la licence Apache puis une licence fondée sur une BSD personnalisée
• Le Zend Engine a conservé une licence distincte, mais il est aujourd'hui considéré de fait comme faisant partie d'un seul et même projet, impossible à dissocier
• Les restrictions d'usage du nom dans l'ancienne licence PHP, ainsi que les clauses de protection de marque, posent depuis longtemps des problèmes de compatibilité et de distribution avec d'autres projets open source

Impact sur le code existant, les extensions et la documentation

• Cette RFC s'applique à l'ensemble de php-src (hors code dont une licence distincte est explicitement indiquée), et recommande aussi l'adoption de BSD 3-Clause pour PECL/les extensions
• Elle concerne l'ensemble du code, nouveau ou existant, dans les dépôts de code source PHP utilisant la PHP License ou la Zend Engine License
• Les licences existantes distinctes (par ex. timelib et autres codes sous licence séparée) ne sont pas concernées par ce changement
• Le manuel PHP continuerait à relever de la licence Creative Commons Attribution 3.0 ou ultérieure
• Les modules d'extension et logiciels existants se verraient offrir le choix d'appliquer PHP License v4 (Modified BSD)
• Pour les futures extensions et les nouveaux projets, il est recommandé d'utiliser des licences reconnues récentes comme BSD/Apache

Conclusion

• La structure de licence de PHP et du Zend Engine serait simplifiée en une BSD 3-Clause, ce qui devrait renforcer la clarté, la compatibilité, l'usage commercial et la sécurité juridique dans l'écosystème open source
• Si cette proposition est approuvée et appliquée, les utilisateurs pourront utiliser librement PHP et le Zend Engine selon les termes de BSD-3-Clause
• L'application officielle est prévue après l'accord des contributeurs du projet, de la communauté et des principales entreprises concernées, ainsi qu'après la procédure de vote

[GN⁺]

Avis sur Hacker News

• Rappelle que le langage utilisé par Meta n’est pas PHP mais Hack, tout en soulignant que le packaging, la documentation et la disponibilité de Hack laissent à désirer, car ces aspects ne sont pas visibles en interne chez Meta et n’entrent donc pas dans l’évaluation des performances ; il pointe aussi le fait que la rétention de connaissances internes est liée à la sécurité de l’emploi ; sur le plan des licences, il indique que les grands groupes IT comme Meta, Google, Microsoft et Apple interdisent strictement l’usage de logiciels sous AGPL, en raison de l’ambiguïté de la clause « Remote Network Interaction » et du risque juridique associé ; il ajoute que si l’on veut absolument empêcher les grandes entreprises ou les acteurs commerciaux classiques d’utiliser son code, il faut choisir l’AGPL ; référence : document de politique AGPL de Google
  • Souligne que beaucoup d’entreprises utilisent effectivement en interne des logiciels sous AGPL, comme Grafana, Mastodon ou Mattermost, mais qu’ils sont moins souvent employés pour des services payants destinés à des clients externes ; en tant que développeur, il dit accorder plus d’importance à la liberté des utilisateurs de son logiciel qu’aux inquiétudes excessives des géants du secteur
  • Précise que ce ne sont pas « toutes les entreprises » qui sont concernées, mais seulement celles qui fournissent un service réseau propriétaire à partir de son logiciel ; c’est précisément l’intention centrale de l’AGPL ; il note d’ailleurs que la politique de Google le dit explicitement parce qu’il s’agit d’un fournisseur de services réseau ; cela n’a pratiquement aucun effet sur la plupart des entreprises non techniques, qui n’ont donc pas à s’en soucier
  • Pour une startup open source, recommande l’AGPL + une double licence commerciale (avec CLA de transfert de propriété intellectuelle) afin d’éviter qu’un méga-cloud comme AWS ne capte toute la valeur
  • Explique que si beaucoup de grandes entreprises utilisent des logiciels sous AGPL, c’est parce que la double licence le permet : on peut afficher l’open source avec l’AGPL tout en facturant les clients via une licence commerciale
  • Dit avoir eu récemment l’impression que beaucoup de projets utilisent désormais Go, et que de nombreux paquets semblent avoir été réécrits en Go
• Dit apprécier qu’un même endroit rassemble clairement les éléments sur la licence PHP et son histoire, sans marketing ni contenu généré par IA
  • Ajoute avec humour que le contenu généré par IA n’apporte en réalité aucune information supplémentaire, et que les discours inutiles existaient déjà avant ; au fond, il n’y a rien de vraiment nouveau
• Se souvient avoir étudié directement le code source du Zend Engine de PHP il y a 25 ans, et y avoir découvert pour la première fois de sa vie un triple pointeur (zval***) ; il raconte avoir ensuite fait toutes sortes de choses avec PHP, y compris participer à des concours de programmation au lycée en utilisant PHP en environnement CLI, mais avoir été éliminé parce que les encadrants ne connaissaient ni le langage ni l’environnement ; il remercie PHP pour les possibilités que cela lui a offertes à l’époque
  • Dit avoir trouvé cette histoire amusante, et partage avoir lui-même utilisé Perl pour son projet de fin d’études
  • Explique qu’il lui est difficile de trouver une justification logique à des triples pointeurs « nus » ; au-delà des performances, la complexité de l’indirection implicite est difficile à défendre ; il dit pouvoir comprendre quelque chose de clair comme un membre de struct, mais qu’ajouter de la complexité gratuitement lui paraît déraisonnable ; il se souvient qu’un proche répétait souvent : « pourquoi ce n’est pas plus simple ? »
• S’inquiète du fait que, sans l’accord de tous les contributeurs, un contributeur malveillant puisse créer des problèmes ; il explique qu’aux États-Unis notamment, des poursuites intentées dans un simple but de harcèlement sont tout à fait possibles, et que chacun doit se défendre à ses propres frais, ce qui alimente une culture obsédée par la protection juridique ; il évoque aussi au passage l’anecdote classique concernant Richard Stallman, l’usage du GPL par PHP et l’arrêt de la double licence qui en a découlé
  • Explique que le PHP Group peut, grâce à la clause « or later », modifier le texte de la licence et publier une nouvelle version sans avoir besoin d’obtenir séparément l’accord des contributeurs
  • Fait remarquer que l’anecdote de licence impliquant Stallman, mentionnée dans la source principale, se rapproche en réalité davantage du passage de MySQL au GPL et de ses conséquences sur la licence PHP ; il dit ne pas comprendre en quoi le simple fait que Stallman n’aime pas quelque chose justifierait d’abandonner le GPL
• Le contexte associé peut être consulté dans le document de contexte du changement de licence sur le wiki PHP
• Recommande vivement cette page à quiconque veut acquérir de solides connaissances sur les licences logicielles et leur modification ; il insiste aussi sur le fait que ce changement de licence est une information qui ne nous impose ni changement ni recertification, sans impact pour les contributeurs comme pour les utilisateurs
  • Exprime avec humour une certaine méfiance réaliste envers les annonces de changements supposés mineurs, en évoquant l’affaire du 787MAX et du MCAS comme exemple de « rien d’important » ayant entraîné d’énormes conséquences
  • Détaille que les changements effectifs consistent à supprimer les formulations liées aux marques PHP/Zend et à fusionner les deux projets sous une licence unique ; auparavant, l’usage des noms « PHP », « Zend » et « Zend Engine » nécessitait des autorisations distinctes, alors que cela s’appliquera désormais de manière unifiée aux noms des titulaires de droits et des contributeurs ; il précise aussi que les clauses 4 à 6 sur la mention, la révision, la certification et la notification sont supprimées
• Se demande pourquoi les passages importants des documents de licence sont tous écrits en majuscules (ALL CAPS)
  • Explique qu’en droit américain, les clauses d’exonération de garantie ou de responsabilité doivent être « conspicuous » (visibles), et que dans un texte courant, le moyen le plus simple de les faire ressortir est l’écriture en majuscules
  • Dit que c’est aussi une façon d’éviter les débats sur ce qui est ou non mis en évidence : si tous les mots sont en majuscules, tout est souligné et il y a moins d’ambiguïté
  • Ajoute que, selon certaines dispositions du droit commercial (UCC), le texte doit être rédigé de manière à ce qu’une personne raisonnable ne puisse pas le manquer, et qu’un titre en grandes majuscules en est une méthode reconnue ; ainsi, si tout le passage est en majuscules, un tribunal peut considérer son importance comme suffisamment « visible »
• Demande à quelqu’un qui comprend bien le changement de l’expliquer en mode ELI5, et se demande si c’est l’ensemble de la licence PHP qui change
  • Demande ce que signifie exactement « l’ensemble de PHP », puis explique que le changement s’applique au langage lui-même, c’est-à-dire à l’interpréteur, au runtime et à la bibliothèque standard
• Trouve la licence MIT bien plus simple et se demande pourquoi elle n’est pas utilisée
  • Se demande si la différence entre la licence MIT et la BSD 3-clause est réellement assez faible pour être considérée comme négligeable en pratique, et s’il existe une différence significative entre la licence MIT et la licence BSD 3-clause