PHP propone cambiar su licencia a BSD 3-Clause

• El proyecto PHP está debatiendo un RFC para unificar la compleja e incompatible licencia propia de PHP y la licencia de Zend Engine bajo BSD 3-Clause (licencia BSD modificada)
• La nueva licencia se aplicaría a partir de PHP 9.0, y BSD 3-Clause se reflejaría en el código fuente, encabezados y documentación en general, eliminando cláusulas especiales del pasado y restricciones relacionadas con la marca
• Con ello se logra claridad legal gracias a la aprobación de OSI y FSF, además de compatibilidad con GPL, y se garantizan los mismos derechos actuales para contribuidores y usuarios
• Para cambiar la licencia se requiere el consentimiento oficial de PHP Group y Perforce Software (antes Zend), y tras la discusión comunitaria se seguirá un proceso de debate y votación de más de 6 meses
• Este cambio también recomienda a proyectos externos como PECL/extensiones elegir BSD 3-Clause, y desaconseja el uso de la “licencia PHP”

---

Resumen general

• Durante mucho tiempo, el proyecto PHP ha mantenido confusión y controversia debido a su propia licencia de código abierto y a la licencia de Zend Engine
• En particular, la Zend Engine License aplicada al código fuente del directorio Zend añade complejidad porque no es una licencia aprobada por la OSI
• Este RFC propone una simplificación práctica de licencias que preserva el copyright de todos los contribuidores de PHP y al mismo tiempo otorga a los usuarios los mismos derechos que las licencias actuales
• El objetivo es adoptar BSD 3-Clause (licencia BSD modificada) como nueva licencia oficial para mantener los derechos y condiciones de uso, mientras se reduce la complejidad y los malentendidos

Propuesta y cambios principales

• La esencia del problema es publicar una nueva versión de la PHP License y de la Zend Engine License para adoptar oficialmente la Modified BSD License (BSD-3-Clause, aprobada tanto por OSI como por FSF)
• La PHP License actual (version 3.01) y la Zend Engine License (version 2.00) son prácticamente iguales a la Modified BSD salvo por algunas cláusulas especiales, por lo que no hay cambios sustanciales en los permisos
• Después de la actualización de licencia:
  • No habrá cambios en los derechos otorgados a contribuidores y usuarios
  • En colaboración con PHP Group y Perforce Software, se eliminarán cláusulas específicas de ciertos grupos
  • PHP y Zend Engine se ofrecerán bajo licencias aprobadas por OSI y compatibles con GPL
• El uso de la antigua PHP License y la Zend Engine License deja de recomendarse
• El archivo LICENSE y los encabezados de licencia dentro del código fuente también se reemplazarán por un nuevo formato

Resumen del texto de la licencia

• BSD 3-Clause permite copiar, modificar y redistribuir libremente, siempre que se mantengan los avisos de copyright y exención de responsabilidad, así como la prohibición de uso no autorizado de nombres y marcas
• BSD-3-Clause es una licencia de software libre aprobada tanto por la OSI (Open Source Initiative) como por la FSF, y además es compatible con GPL

Proceso de cambio y aprobación

• El RFC se definirá mediante votación tras una discusión pública en la comunidad, y su aplicación avanzará después del consentimiento oficial y la votación
• El cambio de licencia requiere el consentimiento oficial de PHP Group y Perforce Software
• Los derechos de contribuidores del código fuente histórico se mantienen intactos, y el cambio no vulnera los derechos existentes
• Se dará a la comunidad un período de discusión de más de 6 meses antes de definirlo por votación
• El cambio se reflejaría oficialmente en PHP 9.0

Antecedentes y contexto histórico

• En sus inicios, PHP 1 y 2 usaban GPL, y después evolucionó pasando por la licencia Apache y una licencia basada en BSD personalizada
• Zend Engine mantuvo una licencia separada, pero hoy se considera en la práctica parte de un solo proyecto inseparable
• Las restricciones de uso del nombre y las cláusulas de protección de marca de la licencia PHP existente han provocado de forma continua problemas de compatibilidad y distribución frente a otros proyectos de código abierto

Impacto en código existente, extensiones y documentación

• Este RFC se aplicaría a todo php-src (excepto el código con una licencia separada explícita), y también recomienda adoptar BSD 3-Clause para PECL y extensiones
• Afecta a todo el código dentro de los repositorios de PHP, tanto nuevo como existente, que use la PHP License o la Zend Engine License
• Las licencias existentes (p. ej., código con licencia separada como timelib) no están sujetas a este cambio
• El manual de PHP seguirá manteniendo la licencia Creative Commons Attribution 3.0 o superior
• Los módulos de extensión y el software existentes tendrán la opción de aplicar PHP License v4 (Modified BSD)
• Para futuras extensiones y nuevos proyectos, se recomienda usar licencias reconocidas actuales como BSD o Apache

Conclusión

• Se espera que la estructura de licencias de PHP y Zend Engine se simplifique a BSD de 3 cláusulas, reforzando la claridad, compatibilidad, uso comercial y seguridad jurídica dentro del ecosistema de código abierto
• Si esta propuesta se aprueba y aplica, los usuarios podrán usar libremente PHP y Zend Engine bajo los términos de BSD-3-Clause
• Está previsto que se aplique oficialmente una vez que se completen el consenso de contribuidores, la comunidad y las empresas clave, junto con el proceso de votación

[GN⁺]

Opiniones en Hacker News

• Señalan que el lenguaje que usa Meta no es PHP sino Hack, pero mencionan que el empaquetado, la documentación y la disponibilidad de Hack dejan mucho que desear; la razón sería que no es una parte visible dentro de Meta y por eso no cuenta para la evaluación de desempeño, además de que ocultar conocimiento interno se conecta con la seguridad laboral. También indican que, desde el punto de vista de licencias, grandes empresas de TI como Meta, Google, Microsoft y Apple prohíben estrictamente el uso de software con AGPL, porque no quieren asumir el riesgo legal derivado de la ambigüedad de la cláusula “Remote Network Interaction”. Añaden que, si de verdad quieres que las grandes empresas o los negocios comunes jamás puedan usar tu código, elijas AGPL. Referencia: documento de política de AGPL de Google
  • Enfatizan que muchas empresas sí usan internamente software con AGPL (por ejemplo, Grafana, Mastodon, Mattermost, etc.), aunque mencionan que se usa menos para servicios dirigidos a clientes externos de pago. Como desarrollador, dice que le importan más las libertades de los usuarios de su software que las preocupaciones excesivas de las megacorporaciones.
  • Aclaran que no son “todos los negocios”, sino solo las empresas que ofrecen servicios de red privativos con su software las que se ven afectadas por la AGPL; explican que esa es precisamente la intención central de la AGPL. También señalan que la base de la política de Google deja claro esto porque habla específicamente de proveedores de red. Añaden que para la mayoría de las empresas no técnicas no tiene ningún efecto y ni siquiera necesitan preocuparse.
  • Si eres una startup de open source, recomiendan AGPL + doble licencia comercial (con un CLA de cesión de propiedad intelectual incluido) para evitar que megaclouds como AWS se queden con todo.
  • Explican que muchas grandes empresas usan software AGPL porque permite el doble licenciamiento; es decir, se promociona como open source bajo AGPL, pero con una licencia comercial se puede cobrar a los clientes por su uso.
  • Comenta que últimamente ha pensado que se usa mucho Go, y le quedó la impresión de que muchos paquetes fueron reescritos en Go.
• Comenta que le gustó mucho que todo lo relacionado con la licencia de PHP y su historia esté recopilado en un solo lugar, sin marketing ni contenido generado por IA.
  • Añade con humor que el contenido generado por IA en realidad no aporta información adicional, y que la palabrería inútil siempre ha existido, así que en esencia no hay nada nuevo.
• Recuerda que, hace 25 años, cuando estudió directamente el código fuente del Zend Engine de PHP, fue la primera vez en su vida que se topó con un puntero triple (zval***). Desde entonces hizo muchas cosas con PHP, e incluso en la preparatoria participó en una competencia de programación usando PHP en entorno CLI, pero lo descalificaron porque el staff no estaba familiarizado con el lenguaje ni con el entorno; aun así, agradece las posibilidades que PHP le permitió en esa época.
  • Dice que la historia le pareció divertida y comparte que él usó Perl en su proyecto de graduación.
  • Comenta que le cuesta encontrar un punto de apoyo lógico para aceptar punteros triples “desnudos”; antes incluso del rendimiento, la complejidad de la indirección implícita es difícil de explicar. Por ejemplo, entiende algo claro como un miembro de un struct, pero agregar complejidad porque sí le parece irracional. Recuerda que un conocido suyo decía seguido: “¿por qué no es simple?”.
• Existe preocupación de que, si no se obtiene el consentimiento de todos los contribuidores, un contribuidor malicioso pueda causar problemas. Comentan que en lugares como Estados Unidos siempre es posible presentar demandas maliciosas para hostigar, y como cada quien tiene que defenderse con su propio dinero, al final se crea una cultura de atención excesiva a la defensa legal. También mencionan, de paso, la anécdota clásica sobre Richard Stallman, el uso de GPL en PHP y cómo eso llevó a la suspensión del doble licenciamiento.
  • Explican que, gracias a la cláusula “or later”, PHP Group puede modificar el contenido de la licencia y publicar una nueva versión sin necesidad de obtener un acuerdo separado de los contribuidores.
  • Señalan que la anécdota de licencias con Stallman mencionada en el material principal en realidad se parece más al cambio de MySQL hacia GPL y al efecto que eso tuvo sobre la licencia de PHP, y expresan que no les convence la idea de abandonar GPL solo porque a Stallman no le gustara.
• El contexto relacionado puede consultarse en el documento de antecedentes del cambio de licencia en el wiki de PHP.
• Recomiendan esta página como lectura obligada para quien quiera construir conocimiento especializado sobre licencias de software y sus modificaciones. También subrayan que este cambio de licencia es una noticia que no nos exige cambios ni recertificación; no hay impacto ni para contribuidores ni para usuarios.
  • Expresa con humor una cautela realista, poniendo como ejemplo el caso del 787MAX y MCAS, donde noticias de que “no habrá grandes cambios” terminaron acompañadas de cambios enormes.
  • Explican en detalle que lo que realmente cambió fue la eliminación de frases relacionadas con las marcas registradas PHP/Zend y el proceso de unificar ambos proyectos bajo una sola licencia. Es decir, antes para usar los nombres “PHP”, “Zend” y “Zend Engine” se requería aprobación separada en cada caso, pero ahora eso cambia para aplicarse de forma unificada a los nombres de titulares de copyright y contribuidores. También indican punto por punto que se eliminan las cláusulas de mención, revisión, certificación y aviso (4 a 6).
• Se preguntan por qué en los documentos de licencia todas las partes importantes se escriben en mayúsculas completas (ALL CAPS).
  • Explican que, en el derecho estadounidense, las cláusulas de exención de garantía o responsabilidad deben ser “conspicuous” (visibles o notorias), y que en texto plano la forma más fácil de marcarlo es usar mayúsculas.
  • Dicen que también es una manera de eliminar la discusión sobre qué estaba enfatizado y qué no; si todas las palabras están en mayúsculas, todo queda enfatizado y se reduce la confusión.
  • Añaden que, según disposiciones del derecho mercantil (UCC), debe estar redactado de forma que una persona razonable necesariamente lo note, y una forma de hacerlo es que el título aparezca grande y en mayúsculas. Por eso, si todo está en mayúsculas, un tribunal puede considerar que su importancia era claramente “notoria”.
• Piden que alguien que entienda bien el cambio lo explique en nivel ELI5, y preguntan si está cambiando la licencia de todo PHP.
  • Responden preguntando qué significa exactamente “todo PHP”, y explican que este cambio se aplica al lenguaje en sí, es decir, al intérprete, el runtime y la biblioteca estándar.
• Comenta que la licencia MIT es mucho más simple y se pregunta por qué no usan esa.
  • Replica preguntando si de verdad la diferencia entre MIT y BSD de 3 cláusulas es lo bastante simple como para sentirse significativa en la práctica, y cuestiona si hay una diferencia realmente importante entre la licencia MIT y la licencia BSD de 3 cláusulas desde un punto de vista sustancial.