PHP Internals abrió una votación para sustituir PHP License 3.01 y Zend Engine License 2.0 por la licencia BSD de tres cláusulas a partir de PHP 9.0. El cambio aborda una incoherencia jurídica que sobrevivió cerca de 25 años.
La licencia actual de PHP es reconocida como open source por OSI, mientras la de Zend Engine no. Ambos cuerpos de código están tan entrelazados que tratarlos como componentes separables dejó de ser práctico. La ambigüedad genera preguntas repetidas en revisiones de compliance, sobre todo acerca de compatibilidad con obras GPL.
BSD-3 está reconocida por OSI y FSF y es compatible con GPL. PHP Group, Zend/Perforce y los abogados ya habían aprobado el texto antes de la votación, abierta hasta el 4 de abril. Los derechos cotidianos de usar, modificar y distribuir PHP permanecen. La organización recibe una licencia conocida en vez de explicar una división histórica.
La auditoría quiere un SPDX conocido
El problema que describe la RFC es de reconocimiento. PHP License 3.01 tuvo aprobación OSI por un proceso legado: el texto ya estaba en uso amplio cuando el comité lo evaluó. Zend Engine License 2.00 no es OSI Approved. Ninguna de las dos es compatible con GPL según la FSF. Después de 25 años en el mismo repositorio, tratar Zend/ como producto separable dejó de ser realista. Juntos forman la implementación de referencia del lenguaje.
BSD-3-Clause, identificador SPDX BSD-3-Clause, está reconocida por OSI y FSF y es compatible con GPL. La RFC argumenta que las cláusulas extra de las licencias actuales son específicas de PHP Group y Zend/Perforce: restricción al nombre "PHP", derecho de republicar la licencia, acknowledgement obligatorio, advertising de Zend. Quitadas esas cláusulas, el texto coincide con BSD-3. Los derechos de uso, modificación y distribución permanecen. El copyright de cada contribuidor permanece con el contribuidor.
Para un equipo de compliance, la pregunta deja de ser "explique PHP License y Zend Engine License, y por qué el engine tiene texto propio" y pasa a ser "el runtime declara BSD-3-Clause". Eso acorta el cuestionario de vendor, el SBOM y la revisión de uso junto a código GPL.
La RFC también depreca PHP License y Zend Engine License para proyectos nuevos. Seguir publicando una biblioteca interna "bajo PHP License 3.01" después del cambio es elegir un texto que el propio proyecto pide no usar.
El PHP de la aplicación no cambia de comportamiento
No hay cambio de semántica, opcode o API. composer update de su código no tiene que esperar la licencia. Extensiones, SAPI y ABI siguen el ciclo normal de la versión. Los tests de regresión de la aplicación no son el lugar de esta decisión. El lugar es el paquete legal: LICENSE en el tarball, headers en los archivos de php-src, eliminación de Zend/LICENSE, el texto de php --version.
Los equipos que copian el LICENSE de PHP a un paquete interno necesitan copiar el archivo nuevo, no el viejo. Los que citan "PHP License 3.01" en una política de software aprobado necesitan actualizar la lista cuando llegue la versión nueva del runtime. Sin ese paso, ingeniería actualiza la imagen y jurídico sigue respondiendo el cuestionario con la fórmula anterior.
El código de terceros dentro de php-src con licencia propia, como timelib en ext/date/lib/, no entra en el recambio. El manual sigue bajo Creative Commons. El recorte es el software del repositorio que hoy está bajo PHP License o Zend Engine License.
Yo trataría esto como un ítem de release notes para jurídico y para quien genera el SBOM, no como un ítem de refactor. Si el equipo no tiene SBOM del runtime, el cambio de licencia es un buen pretexto para empezar a tenerlo. El identificador SPDX cabe en una línea. La historia de las dos licencias no.
PECL, vendor y el opt-in de la versión 4
Mucha extensión PECL todavía declara PHP License 3.01. La cláusula 5 de la 3.01 ya permite al usuario tratar el código cubierto bajo una versión posterior publicada por PHP Group. Si la versión 4 es BSD-3, quien consume la extensión puede elegir esos términos. El maintainer puede migrar header y composer.json. El SPDX que recomienda la RFC es BSD-3-Clause, no un nombre nuevo "PHP License 4", justamente para no proliferar otro texto.
Inventario útil, en una planilla corta:
- runtime PHP en producción, CLI, FPM e imágenes de job;
- extensiones PECL y el
licenseque declara cada una; - paquetes internos que copiaron la PHP License;
- política de la empresa que lista "PHP License" como opción aprobada o bloqueada.
Jurídico actualiza la lista. Ingeniería señala las versiones. Sin los dos, el equipo sigue llenando el cuestionario con la respuesta vieja y descubre el desajuste en una due diligence.
La RFC recomienda, para software nuevo, Apache-2.0, BSD-2, BSD-3, LGPLv3, MIT, MPL-2.0 o Unlicense, entre otras. GPL en una extensión PHP sigue siendo un estado confuso para distribuidores, porque la FSF trata extensión y engine como un programa combinado. Esa recomendación ya valía antes de la votación. El recambio en el core solo vuelve más extraño insistir en PHP License en un paquete nuevo.
El calendario jurídico no es PHP 9
El título de esta nota habla de PHP 9 porque esa fue la moldura de la conversación pública. El texto de la RFC, ya antes de la votación de marzo, pasó a proponer vigencia en la próxima 8.x. Esperar un major para "limpiar la licencia" mezcla dos proyectos: la migración de plataforma y el recambio de texto legal. El segundo no pide freeze de features ni ventana de downtime.
La votación de internals terminaba el 4 de abril de 2026, 00:00 UTC, con dos tercios. PHP Group y Perforce ya habían consentido por escrito, según la RFC. El voto de la comunidad todavía era necesario para registrar la voluntad del proyecto y pedir la ejecución en los repositorios.
Si pasa, el trabajo interno es mundano: actualizar el SBOM cuando llegue la versión nueva del runtime, avisar a jurídico, revisar templates de extensión, copiar el LICENSE nuevo donde estaba vendored. Si se rechaza, la zona gris permanece y el cuestionario sigue largo. En ninguno de los dos desenlaces la aplicación necesita un epic de código.
Hay un solo punto en el que ingeniería y jurídico se encuentran de verdad: la fecha en que la imagen de producción empieza a embarcar el texto nuevo. Hasta entonces, el runtime viejo sigue bajo las licencias viejas. Planear "cuando vayamos al 9" deja esa fecha sin dueño.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
