PHP tem sido um projeto com pesada "bagagem histórica" em termos de problemas de licença por muitos anos, e agora está se preparando para uma limpeza importante e completa: uma proposta liderada pelo membro da comunidade Ben Ramsey, planeja abandonar os dois conjuntos de licenças personalizadas usadas atualmente - Licença PHP 3.01 cobrindo a maior parte do código e Licença Zend 2.0 para código de diretório Zend - e adotar BSD no futuro versões. Licença de três cláusulas (BSD modificado). Atualmente, a comunidade PHP está votando nesta RFC de "Atualização de Licença PHP", que durará até 4 de abril de 2026.
Nos estágios iniciais de desenvolvimento do PHP, o projeto mudou sua licença com bastante frequência: de De 1995 a 2006, o PHP passou por um total de sete alterações de licença ou ajustes de termos. Inicialmente, o PHP foi lançado sob GPLv2; O PHP 3, lançado em 1998, adotou um método de autorização dupla da GPLv2 e da nova licença PHP. Esta nova licença foi baseada na Licença Apache 1.0 e foi formulada pelo fundador do PHP, Rasmus Lerdorf, a fim de tornar o PHP mais "amigável" para usuários comerciais, mantendo ao mesmo tempo os atributos do software livre. Lerdorf disse na época que esperava garantir que o PHP permanecesse livre para que as empresas comerciais pudessem experimentar versões comerciais sem fazer com que os principais contribuidores se sentissem "aproveitados".
No entanto, a versão original da licença personalizada do PHP incluía uma cláusula que exigia permissão por escrito da equipe de desenvolvimento do PHP para redistribuição comercial, que se mostrou difícil de operar na prática e acabou sendo removida na versão 3.0.14 do PHP. O arquivo LICENSE que acompanha esta versão nem indica o número da versão da licença.
PHP 4.0, lançado em maio de 2000, foi uma grande refatoração que introduziu o mecanismo Zend escrito por Zeev Suraski e Andi Gutmans, que mais tarde fundaram a Zend Technologies com a esperança de comercializar o mecanismo Zend em um caminho independente do PHP. Zend fornece licenças para projetos PHP para integrar o mecanismo Zend ao PHP e promete que o código relevante permanecerá sob a Licença Zend ou outras licenças consistentes com a Definição de Código Aberto (OSD), embora a Licença Zend em si não tenha sido oficialmente aprovada pela Open Source Initiative (OSI). Desde então, o código no diretório Zend na árvore de origem do PHP adotou a licença Zend; O PHP 4.0 também abandonou completamente a GPLv2 e adotou a Licença PHP 2.02.
Nos anos seguintes, a Licença PHP continuou a ser aperfeiçoada: a versão PHP 3.0 da licença foi aprovada pela OSI, mas depois uma pequena modificação foi feita para formar a Licença PHP 3.01. Esta modificação apenas ajusta o ano dos direitos autorais e a forma como o texto de reconhecimento para PHP e Zend é expresso, mas não altera os direitos de licenciamento em si. No entanto, esta nova versão nunca mais foi revisada pela OSI. Para tornar as coisas mais preocupantes, o texto da licença aplica-se ostensivamente apenas ao software lançado pelo “Grupo PHP”, que em si não é uma entidade legal real, mas uma lista dos dez primeiros desenvolvedores de PHP. Esta ambigüidade levou algumas pessoas a acreditar que software lançado por outras entidades não pode usar legalmente a Licença PHP como texto de autorização, causando assim problemas práticos para projetos como o Debian. Ramsey revela esse contexto histórico especificamente na RFC.
Na RFC atual, Ramsey propôs que a partir da próxima versão principal (originalmente escrita como PHP 9.0, posteriormente atualizada para "a próxima versão do PHP"), a Licença PHP e a Licença Zend atuais serão substituídas uniformemente pela licença de três cláusulas BSD. Ele disse que, ao escrever a proposta, trabalhou com a presidente do Comitê de Licenciamento da OSI, Pamela Chestek, para abordar questões e questões jurídicas relevantes.
Ramsey disse que se comunicou com todos os membros do Grupo PHP e todos os membros expressaram apoio a esta mudança. Ao mesmo tempo, ele também adquiriu uma licença da Perforce Software - a Perforce colocou o Zend sob seu guarda-chuva em 2019 por meio da aquisição da Rogue Wave, que adquiriu o Zend em 2015. Pode-se perguntar: já que tantos indivíduos enviaram código para PHP ao longo dos anos, cada contribuidor precisa concordar antes que a licença possa ser alterada? Na RFC, o argumento de Ramsey é: Não. O PHP não exige que os contribuidores assinem um CLA que transfira os direitos autorais para o projeto, portanto, os contribuidores retêm os direitos autorais do código contribuído; mas desde que não indiquem explicitamente outros termos de licenciamento, pode considerar-se que concedem ao projecto o direito de utilizar as suas contribuições ao abrigo da licença actual do projecto.
Em outras palavras, os contribuidores possuem os direitos autorais do código que enviam, mas se nenhuma outra licença for especificada, suas contribuições serão autorizadas para uso pelo projeto de acordo com a licença adotada pelo projeto. Ramsey destacou ainda que normalmente ao alterar a licença de um projeto de código aberto, é necessário o consentimento de todos os detentores de direitos autorais, porque a nova licença pode alterar o escopo dos direitos concedidos aos usuários. Mas neste caso, mudar para a licença de três cláusulas BSD não altera os direitos concedidos a outros contribuidores além do PHP Group e Perforce Software. Portanto, ele acredita que os projetos não precisam buscar permissão explícita de todos os contribuidores individualmente.
Embora a RFC observe que o consentimento individual não é legalmente exigido, Ramsey propôs como “cortesia” que o período de discussão fosse mantido por pelo menos seis meses para garantir que todas as partes interessadas tenham oportunidade adequada de expressar suas opiniões. Desde que a RFC foi proposta em julho de 2025, ele publicou diversas atualizações e lembrou à comunidade que o tema ainda está em discussão; até agora, nenhuma objeção substantiva surgiu.
Algumas questões específicas também surgiram durante a discussão. Por exemplo, Derick Rethans perguntou por que era necessário esperar até o PHP 9 em vez de fazer alterações na “próxima versão” após 8.5. Ramsey respondeu que não há nenhuma razão técnica ou legal para isso, é apenas um julgamento intuitivo baseado no ritmo da versão, e se a comunidade achar que é mais apropriado completar as mudanças no PHP 8.6, ele não se oporá. Desde então, a RFC mudou a implementação do "PHP 9" para a "próxima versão".
Outro desenvolvedor, Peter Kokot, sugeriu que a compatibilidade com a GPL deveria ser esclarecida para reduzir dúvidas ao trabalhar com software licenciado pela GPL no futuro. Ele observou que o PHP tem a opção de vincular duas bibliotecas licenciadas pela GPLv3 durante a construção: GNU Readline e GNU dbm (GDBM). Ele espera eliminar gradualmente a opção de vinculação a essas bibliotecas GPL durante a fase de construção, para que os empacotadores não precisem mais se preocupar com possíveis incompatibilidades e, eventualmente, remover completamente a possibilidade de vinculação a GDBM e Readline. Ramsey respondeu que sob a licença PHP 3.01 existente, devido a algumas restrições adicionais aos usuários, a licença é incompatível com a GPL. Esta incompatibilidade não pode ser eliminada neste momento; entretanto, se a licença BSD modificada for usada, desde que o pacote final seja lançado sob os termos da GPL como um todo, não haverá tais problemas de compatibilidade, o que também simplificará significativamente o trabalho de empacotamento de distribuição.
Em 14 de março de 2026, Ramsey anunciou a abertura oficial da votação nesta RFC. Os resultados da votação são registrados publicamente na página RFC do PHP Wiki. O número total de pessoas com direito a voto é atualmente incerto – uma contagem de 2019 colocou um total de 180 desenvolvedores elegíveis para votar naquele momento. Pouco depois do início da votação, 47 pessoas votaram a favor e duas se abstiveram. Os primeiros resultados indicam que o sentimento da comunidade em relação à proposta é altamente positivo, mas o resultado não pode ser considerado uma conclusão precipitada até que o processo de votação esteja concluído. Independentemente do resultado final, está claro que este esforço de limpeza e racionalização de licenças não será possível sem a comunicação, coordenação e facilitação de bastidores de Ramsey ao longo dos últimos anos.