PHP propõe mudar a licença para BSD 3-Clause

• O projeto PHP está discutindo uma RFC para unificar a licença própria do PHP e a licença do Zend Engine, que hoje são complexas e incompatíveis, sob a BSD 3-Clause (licença BSD modificada)
• A nova licença passaria a valer a partir do PHP 9.0, com a BSD 3-Clause aplicada ao código-fonte, cabeçalhos e documentação em geral, eliminando cláusulas especiais antigas e restrições relacionadas à marca
• Com isso, haveria aprovação da OSI e da FSF, compatibilidade com GPL e maior clareza jurídica, enquanto os direitos de contribuidores e usuários permaneceriam os mesmos
• Para a mudança de licença, é necessário o consentimento oficial do PHP Group e da Perforce Software (antiga Zend), além de um processo de discussão comunitária seguido de mais de 6 meses de debate e votação
• A mudança também recomenda que projetos externos, como PECL e extensões, adotem BSD 3-Clause, e desencoraja o uso da “licença PHP”

---

Visão geral

• O projeto PHP convive há muito tempo com confusão e controvérsia por causa de sua licença própria de código aberto e da Zend Engine License
• Em especial, a Zend Engine License aplicada ao código-fonte no diretório Zend aumenta a complexidade por não ser uma licença aprovada pela OSI
• Esta RFC propõe uma simplificação prática do licenciamento que preserva os direitos autorais de todos os contribuidores do PHP, ao mesmo tempo em que concede aos usuários os mesmos direitos da licença atual
• O objetivo é adotar a BSD 3-Clause (licença BSD modificada) como nova licença oficial, mantendo direitos e condições de uso enquanto reduz complexidade e mal-entendidos

Proposta e principais mudanças

• O ponto central da proposta é publicar novas versões da PHP License e da Zend Engine License para adotar oficialmente a Modified BSD License (BSD-3-Clause, aprovada por OSI e FSF)
• A PHP License atual (versão 3.01) e a Zend Engine License (versão 2.00) são na prática equivalentes à Modified BSD, exceto por cláusulas especiais, portanto não há mudança substancial de permissões
• Após a atualização da licença:
  • não haverá mudança nos direitos concedidos a contribuidores e usuários
  • em colaboração com o PHP Group e a Perforce Software, serão removidas cláusulas específicas desses grupos
  • PHP e Zend Engine passarão a ser distribuídos sob licenças aprovadas pela OSI e compatíveis com GPL
• O uso da antiga PHP License e da Zend Engine License deixa de ser recomendado
• O arquivo LICENSE e os cabeçalhos de licença no código-fonte também serão substituídos por um novo formato

Resumo do texto da licença

• A BSD 3-Clause permite copiar, modificar e redistribuir livremente, desde que sejam mantidos os avisos de copyright e isenção de responsabilidade, além da proibição de uso não autorizado de nomes e marcas
• A BSD-3-Clause é uma licença de software livre aprovada tanto pela OSI (Open Source Initiative) quanto pela FSF e compatível com GPL

Processo de mudança e aprovação

• A RFC será definida por votação após discussão pública na comunidade, e a aplicação avançará depois do consentimento oficial e da votação
• A mudança de licença exige o consentimento oficial do PHP Group e da Perforce Software
• Os direitos dos contribuidores do código-fonte existente serão mantidos, e a mudança não viola permissões já concedidas
• A comunidade terá mais de 6 meses para discussão antes da votação final
• A mudança deve ser incorporada oficialmente no PHP 9.0

Contexto histórico

• Nas fases iniciais, o PHP 1 e o PHP 2 usavam GPL; depois, evoluíram passando por licenças Apache e por uma licença baseada em BSD customizada
• O Zend Engine manteve uma licença separada, mas hoje é visto na prática como parte de um único projeto inseparável
• As restrições de uso do nome e as cláusulas de proteção de marca da licença atual do PHP vêm causando problemas contínuos de compatibilidade e distribuição com outros projetos de código aberto

Impacto no código existente, extensões e documentação

• Esta RFC se aplica a todo o php-src (exceto códigos com licença separada explicitamente indicada), e também recomenda a adoção da BSD 3-Clause em projetos como PECL e extensões
• Afeta todo o código, novo e existente, dentro do repositório de código-fonte do PHP que hoje esteja sob a PHP License ou a Zend Engine License
• Códigos sob outras licenças existentes (por exemplo, timelib e outros componentes com licença própria) não são alvo desta mudança
• O manual do PHP continuará sob a licença Creative Commons Attribution 3.0 ou superior
• Módulos de extensão e softwares existentes terão a opção de adotar a PHP License v4 (Modified BSD)
• Para extensões futuras e novos projetos, recomenda-se o uso de licenças reconhecidas mais recentes, como BSD ou Apache

Conclusão

• A estrutura de licenciamento do PHP e do Zend Engine deve ser simplificada para a BSD de 3 cláusulas, o que tende a reforçar clareza, compatibilidade, uso comercial e segurança jurídica no ecossistema open source
• Se a proposta for aprovada e aplicada, os usuários poderão usar livremente PHP e Zend Engine com base na BSD-3-Clause
• A aplicação oficial está prevista após a conclusão do processo de consentimento e votação entre contribuidores, comunidade e empresas-chave

[GN⁺]

Opiniões do Hacker News

• Aponta que a linguagem usada pela Meta não é PHP, mas Hack, e comenta que o empacotamento, a documentação e a disponibilidade do Hack deixam a desejar; a razão seria que isso não é visível internamente na Meta e, portanto, não conta na avaliação de desempenho; também observa que esconder conhecimento interno acaba se conectando com garantia de emprego; e, do ponto de vista de licenciamento, grandes empresas de TI como Meta, Google, Microsoft e Apple proíbem com rigor o uso de software AGPL por causa da ambiguidade da cláusula de “Remote Network Interaction” e do desejo de evitar risco jurídico; acrescenta que, se você quer que grandes empresas ou operadores comerciais em geral jamais usem seu código, então escolha AGPL; referência: documento de política de AGPL do Google
  • Enfatiza que muitas empresas de fato usam software AGPL internamente, como Grafana, Mastodon e Mattermost, embora seja menos comum usá-lo em serviços pagos voltados a clientes externos; como desenvolvedor, afirma valorizar mais a liberdade dos usuários do seu software do que as preocupações excessivas das gigantes de tecnologia
  • Observa que não são “todas as empresas” que são afetadas pela AGPL, mas apenas as empresas que oferecem serviços de rede proprietários com seu software; explica que essa é justamente a intenção central da AGPL; também ressalta que a justificativa da política do Google menciona explicitamente esse ponto por ser um provedor de rede; acrescenta que isso não afeta a maioria das empresas não técnicas, que nem precisam se preocupar com isso
  • Recomenda, para startups open source, AGPL + licença comercial dual (com CLA de cessão de propriedade intelectual) para evitar ser engolido por megaclouds como a AWS
  • Explica que muitas grandes empresas usam software AGPL porque o licenciamento dual é possível; ou seja, ele é divulgado como open source sob AGPL, mas o uso via licença comercial pode ser cobrado dos clientes corporativos
  • Comenta que recentemente teve a impressão de que Go está sendo muito usado, e que muitos pacotes parecem ter sido reescritos em Go
• Diz que foi muito bom ver, em um só lugar, um resumo do conteúdo sobre a licença do PHP e sua história, sem marketing nem texto gerado por IA
  • Acrescenta de forma bem-humorada que conteúdo gerado por IA na verdade não traz informação adicional, e que texto inútil sempre existiu; em essência, não há nada de novo nisso
• Recorda que, ao estudar diretamente o código-fonte do PHP Zend Engine há 25 anos, viu pela primeira vez na vida um ponteiro triplo (zval***); desde então fez várias coisas com PHP e até participou de competições de programação no ensino médio usando PHP em ambiente CLI, mas acabou eliminado porque a equipe do evento não conhecia bem a linguagem nem o ambiente, numa experiência engraçada e triste ao mesmo tempo; agradece pelas possibilidades que o PHP permitiu naquela época
  • Diz que achou essa história divertida e compartilha que usou Perl no projeto de formatura
  • Afirma que é difícil encontrar um ponto de apoio lógico para aceitar ponteiros triplos “nus”; antes mesmo da performance, a complexidade da indireção implícita é difícil de justificar; por exemplo, algo claro como um membro de struct é compreensível, mas adicionar complexidade à toa parece irracional; relembra que um conhecido costumava dizer: “por que não é simples?”
• Há preocupação de que, se não houver consentimento de todos os contribuidores, um contribuidor mal-intencionado possa causar problemas; comenta que em lugares como os EUA é perfeitamente possível abrir processos apenas para assediar, e como cada um precisa se defender com o próprio dinheiro, acaba surgindo uma cultura de preocupação excessiva com defesa jurídica; menciona também, de passagem, a anedota clássica sobre Richard Stallman, o uso de GPL pelo PHP e a interrupção do dual licensing por causa disso
  • Explica que, graças à cláusula “or later”, o PHP Group pode alterar o texto da licença e publicar uma nova versão sem precisar de consentimento separado dos contribuidores
  • Observa que o material principal que cita a anedota com Stallman está, na verdade, mais relacionado à mudança do MySQL para GPL e ao impacto disso sobre a licença do PHP; expressa que não faz sentido abandonar a GPL só porque Stallman não gosta
• O contexto relacionado pode ser visto no documento de contexto da mudança de licença no wiki do PHP
• Recomenda essa página como leitura obrigatória para quem quiser adquirir conhecimento especializado sobre licenças de software e suas alterações, e enfatiza que essa mudança de licença não exige nenhuma mudança nem recertificação de nossa parte; não há impacto para contribuidores nem usuários
  • Expressa, com humor e realismo, certa cautela ao ouvir notícias de que algo vai acontecer “sem grandes mudanças”, citando como exemplo o caso do 787MAX e do MCAS, em que isso acabou acompanhando mudanças enormes
  • Explica em detalhe que a mudança real consiste na remoção de trechos relacionados às marcas registradas PHP/Zend e na unificação dos dois projetos sob uma única licença; antes, para usar os nomes “PHP”, “Zend” e “Zend Engine”, eram necessárias aprovações separadas, mas agora isso passa a se aplicar de forma unificada aos nomes de titulares de direitos autorais e contribuidores; além disso, também são removidas as cláusulas 4 a 6 sobre menção, revisão, certificação e notificação
• Pergunta por que as partes importantes dos documentos de licença são escritas inteiramente em maiúsculas
  • Explica que, no direito dos EUA, cláusulas de isenção de garantia e responsabilidade precisam ser “conspicuous” (visíveis/em destaque), e escrever em maiúsculas é a forma mais simples de destacar isso em texto corrido
  • Diz que isso também serve para eliminar a própria discussão sobre maiúsculas e minúsculas; se todas as palavras estiverem em maiúsculas, tudo fica enfatizado e a confusão diminui
  • Explica que, segundo disposições do direito comercial (UCC), o texto deve estar escrito de modo que uma pessoa razoável necessariamente perceba sua importância, e uma das formas aceitas é usar títulos grandes em maiúsculas; por isso, colocar tudo em maiúsculas pode levar o tribunal a entender que a importância estava “claramente visível”
• Pede que alguém que entenda bem da mudança explique em nível ELI5, e pergunta se a licença de todo o PHP está mudando
  • Pergunta o que exatamente significa “todo o PHP” e explica que esta mudança se aplica à linguagem em si, ou seja, ao interpretador, ao runtime e à biblioteca padrão
• Diz que a licença MIT é muito mais simples e pergunta por que não usar essa licença
  • Retruca perguntando se a diferença entre a MIT e a BSD de 3 cláusulas é realmente perceptível em termos práticos de simplicidade, e questiona se há alguma diferença significativa entre a licença MIT e a licença BSD de 3 cláusulas