La proliferación de licencias es el fenómeno de la abundancia de licencias de software ya existentes y la creación continua de nuevas licencias para software y paquetes de software en el ecosistema de software libre . La proliferación de licencias afecta negativamente a todo el ecosistema de software libre debido a la complejidad cada vez mayor que supone la selección de licencias, la interacción entre licencias y las consideraciones de compatibilidad de licencias . [1]
A menudo, cuando un desarrollador de software desea fusionar partes de diferentes programas de software, no puede hacerlo porque las licencias son incompatibles . Cuando el software bajo dos licencias diferentes se puede fusionar en un trabajo de software más grande, se dice que las licencias son compatibles. A medida que aumenta el número de licencias, aumenta la probabilidad de que un desarrollador de software libre y de código abierto (FOSS) desee fusionar software que está disponible bajo licencias incompatibles. También existe un mayor costo para las empresas que desean evaluar cada licencia FOSS para los paquetes de software que utilizan. [1] Estrictamente hablando, nadie está a favor de la proliferación de licencias. Más bien, el problema surge de la tendencia de las organizaciones a escribir nuevas licencias para abordar necesidades reales o percibidas para sus lanzamientos de software.
La proliferación de licencias es especialmente un problema cuando las licencias tienen relaciones de compatibilidad de licencias limitadas o complicadas con otras licencias. Por lo tanto, algunos consideran que la compatibilidad con la ampliamente utilizada Licencia Pública General GNU (GPL) es una característica importante, por ejemplo David A. Wheeler [2] [3] como también la Free Software Foundation (FSF), que mantiene una lista de las licencias que son compatibles con la GPL. [4] Por otro lado, algunos recomiendan licencias permisivas , en lugar de licencias copyleft , [5] debido a la mejor compatibilidad con más licencias. [6] [7] La Apache Foundation , por ejemplo, critica el hecho de que mientras que la Licencia Apache es compatible con la GPLv3 copyleft, la GPLv3 no es compatible con la licencia permisiva Apache: el software Apache puede incluirse en el software GPLv3, pero no al revés. [8] Como otro ejemplo relevante, la GPLv2 por sí misma no es compatible con la GPLv3 . [9] La GPLv3 publicada en 2007 fue criticada por varios autores por agregar otra licencia incompatible en el ecosistema FOSS. [10] [11] [12] [13] [14] [15] [16]
Una licencia de vanidad es una licencia que escribe una empresa o persona sin ningún otro motivo que escribir su propia licencia (" síndrome NIH "). [17] Si se crea una nueva licencia que no presenta ninguna mejora o diferencia obvia con respecto a otra licencia FOSS más común, a menudo se la puede criticar como una licencia de vanidad. A partir de 2008, muchas personas crean una nueva licencia personalizada para su programa recién lanzado, sin conocer los requisitos para una licencia FOSS y sin darse cuenta de que usar una licencia no estándar puede hacer que ese programa sea casi inútil para otros. [18]
En julio de 2013, GitHub inició un asistente de selección de licencias llamado choosealicense . [19] La página principal choosealicense de GitHub ofrece como una selección rápida solo tres licencias: la Licencia MIT , la Licencia Apache y la Licencia Pública General GNU . Se ofrecen algunas licencias adicionales en subpáginas y mediante enlaces. [20] A partir de 2015, aproximadamente el 77% de todos los proyectos con licencia en GitHub tenían licencia bajo al menos una de estas tres licencias. [21]
A partir de 2006, Google Code sólo aceptó proyectos con licencia bajo las siguientes siete licencias: [22]
Un año después, alrededor de 2008, se agregó la Licencia Pública General GNU 3.0 y se recomendó enfáticamente junto con la licencia permisiva Apache, [23] notablemente excluida fue la AGPLv3 para reducir la proliferación de licencias. [24]
En 2010, Google eliminó estas restricciones y anunció que permitiría que los proyectos utilizaran cualquier licencia aprobada por OSI (ver la postura de OSI a continuación), [25] pero con la limitación de que los proyectos de dominio público solo se permiten como decisión de caso único.
La Iniciativa de Código Abierto (OSI) mantiene una lista de licencias aprobadas. [26] Al principio de su historia, la OSI contribuyó a la proliferación de licencias al aprobar licencias de vanidad y no reutilizables. En 2004 se inició un Proyecto de Proliferación de Licencias de la OSI [27] y en 2007 se preparó un Informe de Proliferación de Licencias . [28] El informe definió las clases de licencias:
El grupo de licencias "populares" incluye nueve licencias: Licencia Apache 2.0 , Licencia New BSD , GPLv2 , LGPLv2 , Licencia MIT , Licencia Pública Mozilla 1.1 , Licencia Común de Desarrollo y Distribución , Licencia Pública Común y Licencia Pública Eclipse .
Richard Stallman , ex presidente de la Free Software Foundation , y Bradley M. Kuhn , ex director ejecutivo, han argumentado en contra de la proliferación de licencias desde 2000, cuando instituyeron la lista de licencias de la FSF , que insta a los desarrolladores a licenciar su software bajo licencias de software libre compatibles con la GPL , aunque se enumeran múltiples licencias de software libre incompatibles con la GPL con un comentario que indica que no hay problema en usar y/o trabajar en un software que ya está bajo las licencias en cuestión, al tiempo que insta a los lectores de la lista a no usar esas licencias en el software que escriben. [29]
Ciarán O'Riordan de la FSF Europa sostiene que lo principal que la FSF puede hacer para prevenir la proliferación de licencias es reducir las razones para crear nuevas licencias en primer lugar, en un editorial titulado Cómo la GPLv3 aborda la proliferación de licencias . [30] Generalmente la FSF Europa recomienda consistentemente el uso de la GPL de GNU tanto como sea posible, y cuando eso no sea posible, utilizar licencias compatibles con la GPL.
En 2005, Intel retiró voluntariamente su Licencia de Código Abierto Intel de la lista OSI de licencias de código abierto y también dejó de usar o recomendar esta licencia para reducir la proliferación de licencias. [31]
El grupo 451 creó en junio de 2009 un informe de proliferación llamado El mito de la proliferación de licencias de código abierto . [32] Un artículo de 2009 de la Facultad de Derecho de la Universidad de Washington titulado Proliferación de licencias de código abierto: ¿diversidad útil o confusión sin esperanza? pedía tres cosas como solución: "Un mago más ingenioso" (para la selección de licencias), "Mejores prácticas y licencias heredadas" , "Más servicios legales para hackers" . [33] La OpenSource Software Collaboration Counseling (OSSCC) recomienda, basándose en las nueve licencias OSI recomendadas originalmente, cinco licencias: la licencia Apache 2.0, la licencia New BSD, la CDDL, la licencia MIT y, hasta cierto punto, la MPL, ya que apoyan la colaboración, otorgan el uso de patentes y ofrecen protección de patentes. Notablemente, falta la GPL ya que "esta licencia no se puede usar dentro de otras obras bajo una licencia diferente". [34]
El copyleft es la principal fuente de problemas de compatibilidad.
Las licencias permisivas simplifican las cosas Una de las razones por las que el mundo empresarial, y cada vez más desarrolladores [...], favorecen las licencias permisivas es la simplicidad de la reutilización. La licencia normalmente solo se refiere al código fuente que está licenciado y no intenta inferir ninguna condición sobre ningún otro componente, y debido a esto no hay necesidad de definir qué constituye un trabajo derivado. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que todas son compatibles.
Las licencias para distribuir software libre o de código abierto (FOSS) se dividen en dos familias: permisivas y copyleft. Las licencias permisivas (BSD, MIT, X11, Apache, Zope) son generalmente compatibles e interoperables con la mayoría de las demás licencias, tolerando la fusión, combinación o mejora del código cubierto y su redistribución bajo muchas licencias (incluidas las no libres o "propietarias").
Sin embargo, el software GPLv3 no puede incluirse en proyectos Apache. Las licencias son incompatibles en una sola dirección, y es el resultado de la filosofía de licencias de ASF y la interpretación de la ley de derechos de autor por parte de los autores de GPLv3.
No. Algunos de los requisitos de la GPLv3, como el requisito de proporcionar información de instalación, no existen en la GPLv2. Como resultado, las licencias no son compatibles: si intentara combinar código publicado bajo ambas licencias, violaría la sección 6 de la GPLv2. Sin embargo, si el código se publica bajo la GPL "versión 2 o posterior", es compatible con la GPLv3 porque la GPLv3 es una de las opciones que permite.
La GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
En definitiva, la GPLv3 constituye una proliferación de licencias.
La propiedad viral estimula la proliferación de licencias y contribuye a la "pesadilla impuesta por la GPL" - una situación en la que muchas otras licencias son lógicamente incompatibles con la GPL y hacen la vida innecesariamente difícil para los desarrolladores que trabajan en el entorno Linux (KDE es un buen ejemplo en este caso, Python es un ejemplo menos conocido). Creo que estos mezquinos esfuerzos por interpretar la GPL como un "texto sagrado" son una discusión improductiva que no nos lleva a ninguna parte. Y contribuyeron directamente a la proliferación de diferentes licencias de "software libre".
En su momento, la decisión parecía sensata ante un punto muerto. Pero ahora, la GPLv2 se utiliza para el 42,5% del software libre y la GPLv3 para menos del 6,5%, según Black Duck Software.
[...] Dado que la FSF está proponiendo cambiar todos sus proyectos a la GPLv3 y presionar a todos los demás proyectos con licencia GPL para que lo hagan, prevemos que el lanzamiento de la GPLv3 presagia la
balcanización
de todo el universo de código abierto en el que nos apoyamos.
El lío de la compatibilidad de licencias: cuando se trata de la GPL, las complejidades de las licencias se convierten en una versión nada divertida de un acertijo. Hay tantas cosas que considerar y tantas interacciones que considerar. Y que las incompatibilidades de la GPL siguen siendo un problema que afecta activamente a las personas es algo que muchos parecen olvidar. Por ejemplo, uno podría pensar que la incompatibilidad de la GPLv2 con la Licencia de Software Apache 2.0 debería ser algo del pasado ahora que todo se actualiza a la GPLv3, pero resulta que hay suficientes personas que están atascadas solo con la GPLv2 o que no están de acuerdo con la GPLv3, por lo que algunos proyectos con licencia de software Apache deben migrar. Por ejemplo, Bootstrap de Twitter está migrando actualmente de ASL2.0 a MIT precisamente porque algunas personas aún necesitan compatibilidad con la GPLv2. Entre los proyectos afectados se encuentran Drupal, WordPress, Joomla, la Wiki MoinMoin y otros. Y hasta ese caso demuestra que a la gente ya no le importan tanto las licencias, ya que Joomla 3 simplemente incluyó bootstrap a pesar de que no eran licencias compatibles (GPLv2 frente a ASL 2.0). El otro caso tradicional de cosas que no son compatibles con la GPL es el proyecto OpenSSL, que tiene una licencia que no se lleva bien con la GPL. Esa licencia también sigue siendo incompatible con la GPLv3. Todo este calvario es particularmente interesante, ya que algunas partes no tan agradables han comenzado a trollear las licencias a través de las licencias GPL.