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 de software y paquetes de software en el ecosistema FOSS . La proliferación de licencias afecta negativamente a todo el ecosistema FOSS por la carga de la selección de licencias cada vez más compleja, la interacción de 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) quiera fusionar software que está disponible bajo licencias incompatibles. También hay un mayor costo para las empresas que desean evaluar cada licencia FOSS para los paquetes de software que utilizan. [1]En rigor, 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 las necesidades reales o percibidas de sus versiones de software.
La proliferación de licencias es especialmente un problema cuando las licencias solo tienen relaciones de compatibilidad limitadas o complicadas con otras licencias. Por lo tanto, algunos consideran que la compatibilidad con la GNU General Public License (GPL) ampliamente utilizada 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] ElApache Foundation, por ejemplo, critica el hecho de que, si bien la licencia Apache es compatible con la GPLv3 copyleft, la GPLv3 no es compatible con la licencia permisiva de Apache: el software Apache se puede incluir en el software GPLv3, pero no al revés. [8] Como otro ejemplo relevante, la GPLv2 en sí misma no es compatible con la GPLv3 . [9] La GPLv3 lanzada 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 escrita por una empresa o una persona por el único motivo de escribir su propia licencia (" síndrome NIH "). [17] Si se crea una nueva licencia que no tiene ninguna mejora o diferencia obvia con respecto a otra licencia FOSS más común, a menudo se la puede criticar como una licencia vanidosa. 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 el uso de 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 de 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 . Algunas licencias adicionales se ofrecen en subpáginas y mediante enlaces. [20] A partir de 2015, aprox. El 77 % de todos los proyectos con licencia en GitHub tenían al menos una de estas tres licencias. [21]
Un año más tarde, alrededor de 2008, se agregó la Licencia Pública General GNU 3.0 y se recomendó encarecidamente junto con la licencia permisiva de Apache, [23] se excluyó notablemente la AGPLv3 para reducir la proliferación de licencias. [24]