PHP ha sido un proyecto con un pesado "bagaje histórico" en términos de problemas de licencia durante muchos años, y ahora se está preparando para una limpieza importante y exhaustiva: una propuesta liderada por el miembro de la comunidad Ben Ramsey, planea abandonar los dos conjuntos de licencias personalizadas actualmente utilizadas - Licencia PHP 3.01 que cubre la mayor parte del código y Licencia Zend 2.0 para el código del directorio Zend - y adoptar BSD en el futuro versiones. Licencia de tres cláusulas (BSD modificada). Actualmente, la comunidad PHP está votando este RFC de "Actualización de licencia PHP", que durará hasta el 4 de abril de 2026.
En las primeras etapas de desarrollo de PHP, el proyecto cambiaba su licencia con bastante frecuencia: de De 1995 a 2006, PHP experimentó un total de siete cambios de licencia o ajustes de términos. Inicialmente, PHP se lanzó bajo GPLv2; PHP 3, lanzado en 1998, adoptó un método de autorización dual de GPLv2 y la nueva licencia PHP. Esta nueva licencia se basó en la Licencia Apache 1.0 y fue formulada por el fundador de PHP, Rasmus Lerdorf, para hacer que PHP sea más "amigable" para los usuarios comerciales y al mismo tiempo mantener los atributos del software libre. Lerdorf dijo en ese momento que esperaba garantizar que PHP siguiera siendo gratuito para que las empresas comerciales pudieran probar versiones comerciales sin que los principales contribuyentes se sintieran "aprovechados".
Sin embargo, la versión original de la licencia PHP personalizada incluía una cláusula que requería permiso por escrito del equipo de desarrollo de PHP para la redistribución comercial, que resultó difícil de operar en la práctica y finalmente se eliminó en la versión PHP 3.0.14. El archivo de LICENCIA que viene con esta versión ni siquiera indica el número de versión de la licencia.
PHP 4.0, lanzado en mayo de 2000, fue una refactorización importante que introdujo el motor Zend escrito por Zeev Suraski y Andi Gutmans, quienes más tarde fundaron Zend Technologies con la esperanza de comercializar el motor Zend en un camino independiente de PHP. Zend proporciona licencias a proyectos PHP para integrar el motor Zend en PHP y promete que el código relevante permanecerá bajo la Licencia Zend u otras licencias consistentes con la Definición de Código Abierto (OSD), aunque la Licencia Zend en sí no ha sido aprobada oficialmente por la Iniciativa de Código Abierto (OSI). Desde entonces, el código en el directorio Zend en el árbol fuente de PHP ha adoptado la licencia Zend; PHP 4.0 también abandonó por completo la GPLv2 y adoptó la licencia PHP 2.02.
En los años siguientes, la licencia PHP continuó perfeccionándose: la versión PHP 3.0 de la licencia fue aprobada por OSI, pero luego se realizó una modificación menor para formar la licencia PHP 3.01. Esta modificación sólo ajusta el año de copyright y la forma en que se expresa el texto de reconocimiento para PHP y Zend, pero no cambia los derechos de licencia en sí. Sin embargo, OSI nunca volvió a revisar esta nueva versión. Para hacer las cosas más preocupantes, el texto de la licencia aparentemente sólo se aplica al software lanzado por el "Grupo PHP", que en sí mismo no es una entidad legal real sino una lista de diez de los primeros desarrolladores de PHP. Esta ambigüedad ha llevado a algunas personas a creer que el software lanzado por otras entidades no puede usar legalmente la licencia PHP como texto de autorización, causando así problemas prácticos para proyectos como Debian. Ramsey desvela estos antecedentes históricos específicamente en RFC.
En el RFC actual, Ramsey propuso que a partir de la próxima versión principal (originalmente escrita como PHP 9.0, luego actualizada a "la próxima versión de PHP"), la licencia PHP actual y la licencia Zend serán reemplazadas uniformemente por la licencia BSD de tres cláusulas. Dijo que al escribir la propuesta, había trabajado con la presidenta del Comité de Licencias de OSI, Pamela Chestek, para abordar cuestiones y cuestiones legales relevantes.
Ramsey dijo que se ha comunicado con todos los miembros del Grupo PHP y cada miembro ha expresado su apoyo a este cambio. Al mismo tiempo, también adquirió una licencia de Perforce Software: Perforce puso a Zend bajo su paraguas en 2019 mediante la adquisición de Rogue Wave, que adquirió Zend en 2015. Uno podría preguntarse: dado que tantas personas han enviado código a PHP a lo largo de los años, ¿todos los contribuyentes deben estar de acuerdo antes de que se pueda cambiar la licencia? En el RFC, el punto de Ramsey es: No. PHP no requiere que los contribuyentes firmen un CLA que transfiera los derechos de autor al proyecto, por lo que los contribuyentes conservan los derechos de autor de su código contribuido; pero siempre que no establezcan explícitamente otros términos de la licencia, se puede considerar que otorgan al proyecto el derecho a utilizar sus contribuciones bajo la licencia actual del proyecto.
En otras palabras, los contribuyentes poseen los derechos de autor del código que envían, pero si no se especifica otra licencia, sus contribuciones están autorizadas para su uso en el proyecto de acuerdo con la licencia adoptada por el proyecto. Ramsey señaló además que, normalmente, cuando se cambia la licencia de un proyecto de código abierto, se requiere el consentimiento de todos los titulares de derechos de autor, porque la nueva licencia puede cambiar el alcance de los derechos otorgados a los usuarios. Pero en este caso, cambiar a la licencia BSD de tres cláusulas no cambia los derechos otorgados a contribuyentes distintos de PHP Group y Perforce Software. Por lo tanto, cree que los proyectos no necesitan solicitar el permiso explícito de todos los contribuyentes individualmente.
Si bien el RFC señala que el consentimiento individual no es un requisito legal, Ramsey propuso como "cortesía" que el período de discusión se mantenga durante al menos seis meses para garantizar que todas las partes interesadas tengan la oportunidad adecuada de expresar sus puntos de vista. Desde que se propuso el RFC en julio de 2025, ha publicado múltiples actualizaciones y ha recordado a la comunidad que el tema aún está en discusión; Hasta el momento no se han planteado objeciones sustanciales.
Durante el debate también surgieron algunas cuestiones específicas. Por ejemplo, Derick Rethans preguntó por qué era necesario esperar hasta PHP 9 en lugar de realizar cambios en la "próxima versión" después de la 8.5. Ramsey respondió que no hay ninguna razón técnica o legal sólida para esto, es sólo un juicio intuitivo basado en el ritmo de la versión, y si la comunidad considera que es más apropiado completar los cambios en PHP 8.6, no se opondrá. Desde entonces, el RFC ha trasladado la implementación de "PHP 9" a "la próxima versión".
Otro desarrollador, Peter Kokot, sugirió que la compatibilidad con la GPL debería aclararse para reducir las dudas al trabajar con software con licencia GPL en el futuro. Señaló que PHP tiene la opción de vincularse con dos bibliotecas con licencia GPLv3 al compilar: GNU Readline y GNU dbm (GDBM). Espera eliminar gradualmente la opción de vincular estas bibliotecas GPL durante la fase de construcción para que los empaquetadores ya no tengan que preocuparse por posibles incompatibilidades y, finalmente, eliminar por completo la posibilidad de vincularse con GDBM y Readline. Ramsey respondió que bajo la licencia PHP 3.01 existente, debido a algunas restricciones adicionales para los usuarios, la licencia es incompatible con la GPL. Esta incompatibilidad no puede eliminarse actualmente; sin embargo, si en su lugar se utiliza la licencia BSD modificada, siempre que el paquete final se publique bajo los términos de GPL en su totalidad, no habrá problemas de compatibilidad, lo que también simplificará significativamente el trabajo del paquete de distribución.
El 14 de marzo de 2026, Ramsey anunció la apertura oficial de la votación sobre este RFC. Los resultados de la votación se registran públicamente en la página RFC de PHP Wiki. El número total de personas con derecho a voto es actualmente incierto: un recuento de 2019 arrojó un total de 180 desarrolladores elegibles para votar en ese momento. Poco después de comenzar la votación, 47 personas votaron a favor y dos se abstuvieron. Los primeros resultados indican que el sentimiento de la comunidad hacia la propuesta es muy positivo, pero el resultado no puede considerarse una conclusión inevitable hasta que se complete el proceso de votación. Independientemente del resultado final, está claro que este esfuerzo de limpieza y racionalización de permisos no será posible sin la comunicación, coordinación y facilitación detrás de escena de Ramsey durante los últimos años.