PHP está votando pra trocar de licença. Depois de 25 anos.
A votação abriu essa semana no PHP Internals: a proposta é migrar da PHP License v3.01 e da Zend Engine License 2.0 para a 3-Clause BSD License. A mudança vale a partir do PHP 9.0.
Por que isso importa?
A licença atual do PHP é reconhecida como open source pela OSI. Mas a licença do Zend Engine não é. E depois de 25 anos com os dois códigos entrelaçados no mesmo repositório, já não dá mais pra separar um do outro. O resultado é uma zona cinzenta jurídica que incomoda quem precisa de clareza em compliance.
A BSD-3 resolve isso de uma vez: é reconhecida pela OSI, pela FSF, e é compatível com GPL. A PHP Group, a Zend/Perforce e os advogados já assinaram. A votação termina em 4 de abril.
Na prática, não muda quase nada no dia a dia. Você continua podendo usar, modificar e distribuir. Mas ter uma licença limpa e reconhecida universalmente facilita auditorias, reduz atrito jurídico e tira aquela dúvida que sempre aparecia quando alguém perguntava "mas a licença do PHP é GPL-compatible?".
A votação está aberta. Se passar, PHP 9.0 já nasce com licença BSD-3.
Auditoria quer um SPDX conhecido
O problema que a RFC descreve é de reconhecimento. A PHP License 3.01 teve aprovação OSI por processo legado: o texto já estava em uso amplo quando o comitê avaliou. A Zend Engine License 2.00 não é OSI Approved. Nenhuma das duas é GPL-compatible segundo a FSF. Depois de 25 anos no mesmo repositório, tratar Zend/ como produto destacável deixou de ser realista. Juntos, formam a implementação de referência da linguagem.
BSD-3-Clause, identificador SPDX BSD-3-Clause, é reconhecida por OSI e FSF e é GPL-compatible. A RFC argumenta que as cláusulas extras das licenças atuais são específicas do PHP Group e da Zend/Perforce: restrição ao nome "PHP", direito de republicar a licença, acknowledgement obrigatório, advertising da Zend. Removidas essas cláusulas, o texto coincide com BSD-3. Direitos de uso, modificação e distribuição permanecem. Copyright de cada contribuidor permanece com o contribuidor.
Para um time de compliance, a pergunta deixa de ser "explique a PHP License e a Zend Engine License, e por que o engine tem texto próprio" e passa a ser "o runtime declara BSD-3-Clause". Isso encurta questionário de vendor, SBOM e revisão de uso junto a código GPL.
A RFC também depreca PHP License e Zend Engine License para projetos novos. Continuar publicando biblioteca interna "sob PHP License 3.01" depois da mudança é escolher um texto que o próprio projeto pede para não usar.
O PHP da aplicação não muda de comportamento
Não há mudança de semântica, opcode ou API. composer update do seu código não precisa esperar a licença. Extensões, SAPI e ABI seguem o ciclo normal da versão. Testes de regressão da aplicação não são o lugar desta decisão. O lugar é o pacote legal: LICENSE no tarball, headers nos arquivos de php-src, remoção de Zend/LICENSE, texto de php --version.
Times que copiam o LICENSE do PHP para um pacote interno precisam copiar o arquivo novo, não o antigo. Times que citam "PHP License 3.01" em política de software aprovado precisam atualizar a lista quando a versão nova do runtime chegar. Sem esse passo, o engenheiro atualiza a imagem e o jurídico continua respondendo o questionário com a fórmula anterior.
Código de terceiros dentro de php-src com licença própria, como timelib em ext/date/lib/, não entra na troca. A documentação do manual permanece Creative Commons. O recorte é o software do repositório que hoje está sob PHP License ou Zend Engine License.
Eu trataria isso como um item de release notes para jurídico e para quem gera SBOM, não como um item de refactor. Se a equipe não tem SBOM do runtime, a troca de licença é um bom pretexto para passar a ter. O identificador SPDX cabe numa linha. A história das duas licenças não.
PECL, vendor e o opt-in da versão 4
Muita extensão PECL ainda declara PHP License 3.01. A cláusula 5 da 3.01 já permite ao usuário tratar o código coberto sob uma versão posterior publicada pelo PHP Group. Se a versão 4 for BSD-3, quem consome a extensão pode escolher esses termos. O maintainer pode migrar header e composer.json. O SPDX recomendado na RFC é BSD-3-Clause, não um nome novo "PHP License 4", justamente para não proliferar mais um texto.
Inventário útil, numa planilha curta:
- runtime PHP em produção, CLI, FPM e imagens de job;
- extensões PECL e o
licenseque cada uma declara; - pacotes internos que copiaram a PHP License;
- política da empresa que lista "PHP License" como opção aprovada ou bloqueada.
Jurídico atualiza a lista. Engenharia aponta as versões. Sem os dois, o time continua preenchendo questionário com a resposta antiga e descobre o descompasso numa due diligence.
A RFC recomenda, para software novo, Apache-2.0, BSD-2, BSD-3, LGPLv3, MIT, MPL-2.0 ou Unlicense, entre outras. GPL em extensão PHP continua um estado confuso para distribuidores, porque a FSF trata extensão e engine como um programa combinado. Essa recomendação já valia antes da votação. A troca no core só torna mais estranho insistir na PHP License num pacote novo.
O calendário jurídico não é o PHP 9
O título desta nota fala em PHP 9 porque essa foi a moldura da conversa pública. O texto da RFC, já antes da votação de março, passou a propor vigor na próxima 8.x. Esperar um major para "limpar a licença" mistura dois projetos: a migração de plataforma e a troca de texto legal. O segundo não pede freeze de features nem janela de downtime.
A votação de internals terminava em 4 de abril de 2026, 00:00 UTC, com dois terços. PHP Group e Perforce já tinham consentido por escrito, segundo a RFC. O voto da comunidade ainda era necessário para registrar a vontade do projeto e pedir a execução nos repositórios.
Se passar, o trabalho interno é mundano: atualizar SBOM quando a versão nova do runtime chegar, avisar jurídico, revisar templates de extensão, copiar o LICENSE novo onde ele foi vendored. Se recusar, a zona cinzenta permanece e o questionário continua longo. Em nenhum dos dois desfechos a aplicação precisa de um epic de código.
Há um único ponto em que engenharia e jurídico se encontram de verdade: a data em que a imagem de produção passa a embarcar o texto novo. Até lá, o runtime antigo continua sob as licenças antigas. Planejar "quando formos para o 9" deixa essa data sem dono.
