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 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 por la carga de consideraciones cada vez más complejas de selección de licencias, interacción de licencias y compatibilidad de licencias . [1]
Impacto
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 con 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 con licencias incompatibles. También existe un mayor costo para las empresas que desean evaluar cada licencia de software libre 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 las necesidades reales o percibidas de sus versiones de software.
Compatibilidad de licencia
La proliferación de licencias es un problema especialmente cuando las licencias tienen relaciones de compatibilidad de licencias limitadas o complicadas con otras licencias. Por lo tanto, algunos consideran la compatibilidad con la GNU General Public License (GPL) ampliamente utilizada como una característica importante, por ejemplo, David A. Wheeler [2] [3] y 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 Fundación Apache, por ejemplo, critica el hecho de que, si bien la licencia Apache es compatible con el copyleft GPLv3, la GPLv3 no es compatible con la licencia Apache permisiva; 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]
Licencias de vanidad
Una licencia de vanidad es una licencia escrita por una empresa o persona sin otro motivo que escribir su propia licencia (" síndrome NIH "). [17] Si se crea una nueva licencia que no tiene una mejora o diferencia obvia con respecto a otra licencia de software libre más común, a menudo puede ser criticada 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 el uso de una licencia no estándar puede hacer que ese programa sea casi inútil para otros. [18]
Enfoques de solución
Postura de GitHub
En julio de 2013, GitHub inició un asistente de selección de licencias llamado choosealicense . [19] La página de inicio de Choosealicense de GitHub ofrece como una selección rápida sólo 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] Siguiendo en 2015, aprox. El 77% de todos los proyectos con licencia en GitHub tenían al menos una de estas tres licencias. [21]
Postura de Google
A partir de 2006, Google Code solo aceptó proyectos con las siguientes siete licencias: [22]
- Licencia Apache 2.0
- Nueva licencia BSD
- Licencia MIT
- Licencia pública general GNU 2.0
- Licencia pública general reducida GNU 2.1
- Licencia pública de Mozilla 1.1
- Licencia artística / licencia doble GPL (a menudo utilizada por la comunidad de Perl )
Un año después, alrededor de 2008, se agregó la Licencia Pública General GNU 3.0 y se recomendó encarecidamente junto con la licencia Apache permisiva, [23] se excluyó notablemente la AGPLv3 para reducir la proliferación de licencias. [24]
En 2010, Google eliminó estas restricciones y anunció que permitiría a los proyectos utilizar cualquier licencia aprobada por OSI (consulte 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.
Postura de OSI
Open Source Initiative (OSI) mantiene una lista de licencias aprobadas. [26] Al principio de su historia, la OSI contribuyó a la proliferación de licencias mediante la aprobación de licencias vanidad y no reutilizables. En 2004 se inició un proyecto de proliferación de licencias de OSI [27] y en 2007 se preparó un informe de proliferación de licencias [28]. El informe definía clases de licencias:
- Licencias que son populares y ampliamente utilizadas o con comunidades sólidas
- Licencias internacionales
- Licencias para fines especiales
- Otras / varias licencias
- Licencias que son redundantes con licencias más populares
- Licencias no reutilizables
- Licencias reemplazadas
- Licencias que se han retirado voluntariamente
- Licencias sin categoría
El grupo de licencias "populares" incluye nueve licencias: Apache License 2.0 , New BSD license , GPLv2 , LGPLv2 , MIT license , Mozilla Public License 1.1 , Common Development and Distribution License , Common Public License , Eclipse Public License .
Postura de la FSF
Richard Stallman , ex presidente de FSF, 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 FSF , que insta a los desarrolladores a licenciar su software bajo licencia (s) de software libre compatible con GPL . , aunque se enumeran varias licencias de software libre incompatibles con la GPL con un comentario que indica que no hay problemas para usar y / o trabajar en un software que ya se encuentre bajo las licencias en cuestión, al tiempo que insta a los lectores de la lista a no usar esas licencias en el software. escriben. [29]
Ciarán O'Riordan de FSF Europa sostiene que lo principal que puede hacer la FSF para prevenir la proliferación de licencias es reducir las razones para hacer nuevas licencias en primer lugar, en un editorial titulado Cómo la GPLv3 aborda la proliferación de licencias . [30] En general, la FSF Europa recomienda sistemáticamente el uso de GNU GPL tanto como sea posible, y cuando eso no sea posible, utilizar licencias compatibles con GPL.
Otros
En 2005, Intel retiró voluntariamente su licencia de código abierto de 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 451group 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 documento 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 desesperada? pidió tres cosas como solución: "Un Wizzier Wizzard" (para la selección de licencias), "Mejores prácticas y licencias heredadas" , "Más servicios legales para piratas informáticos" . [33] El OpenSource Software Collaboration Counseling (OSSCC) recomienda, basándose en las nueve licencias OSI recomendadas originalmente, cinco licencias: Apache License 2.0, New BSD License, CDDL, MIT license y, hasta cierto punto, MPL, ya que apoyan la colaboración. , conceder el uso de patentes y ofrecer protección mediante patente. Cabe destacar que falta la GPL, ya que "esta licencia no se puede utilizar dentro de otras obras con una licencia diferente". [34]
Ver también
- Compatibilidad de licencia
- Lenguaje de expresión de derechos
Referencias
- ^ a b OSI y proliferación de licencias en fossbazar.com por Martin Michlmayr "Demasiadas licencias diferentes dificultan la elección de los licenciantes: es difícil elegir una buena licencia para un proyecto porque hay muchas. Algunas licencias no funcionan bien juntas : algunas licencias de código abierto no interactúan bien con otras licencias de código abierto, lo que dificulta la incorporación de código de otros proyectos. Demasiadas licencias dificultan la comprensión de lo que está aceptando en una distribución de múltiples licencias: desde un software libre La aplicación generalmente contiene código con diferentes licencias y la gente usa muchas aplicaciones, cada una de las cuales contiene una o varias licencias, es difícil ver cuáles son sus obligaciones ". (el 21 de agosto de 2008)
- ↑ The Free-Libre / Open Source Software (FLOSS) License Slide por David A. Wheeler el 27 de septiembre de 2007
- ^ "Haga que su software de código abierto sea compatible con la GPL. O bien" . www.dwheeler.com .
- ^ lista de licencias Archivado 2000-08-15 en Wayback Machine de gnu.org
- ^ Laurent, Philippe (24 de septiembre de 2008). "La GPLv3 y los problemas de compatibilidad" (PDF) . Evento europeo de abogados de código abierto 2008 . Universidad de Namur - Bélgica. pag. 7. Archivado desde el original (PDF) el 4 de marzo de 2016 . Consultado el 30 de mayo de 2015 .
El copyleft es la principal fuente de problemas de compatibilidad
- ^ Hanwell, Marcus D. (28 de enero de 2014). "¿Debo usar una licencia permisiva? ¿Copyleft? ¿O algo en el medio?" . opensource.com . Consultado el 30 de mayo de 2015 .
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. Por lo general, la licencia solo pertenece al código fuente que se licencia y no intenta inferir ninguna condición sobre ningún otro componente, por lo que no es necesario definir qué constituye un trabajo derivado. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que todos son compatibles.
- ^ "Compatibilidad e interoperabilidad de licencias" . Software de código abierto: desarrolle, comparta y reutilice software de código abierto para las administraciones públicas . joinup.ec.europa.eu. Archivado desde el original el 17 de junio de 2015 . Consultado el 30 de mayo de 2015 .
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 otras licencias, y toleran fusionar, combinar o mejorar el código cubierto y redistribuirlo bajo muchas licencias (incluidas las no libres o "propietarias ”).
- ^ Fundación Apache (30 de mayo de 2015). "Compatibilidad con GPL" . Consultado el 30 de mayo de 2015 .
Por lo tanto, el software Apache 2 se puede incluir en proyectos GPLv3, porque la licencia GPLv3 acepta nuestro software en trabajos GPLv3. Sin embargo, el software GPLv3 no se puede incluir en los proyectos de Apache. Las licencias son incompatibles en una sola dirección y es el resultado de la filosofía de concesión de licencias de ASF y la interpretación de los autores de la GPLv3 de la ley de derechos de autor.
- ^ "Preguntas frecuentes sobre las licencias GNU: ¿GPLv3 es compatible con GPLv2?" . gnu.org . Consultado el 3 de junio de 2014 .
No. Algunos de los requisitos de GPLv3, como el requisito de proporcionar información de instalación, no existen en GPLv2. Como resultado, las licencias no son compatibles: si intenta combinar código publicado bajo ambas licencias, violaría la sección 6 de GPLv2. Sin embargo, si el código se publica bajo GPL "versión 2 o posterior", eso es compatible con GPLv3 porque GPLv3 es una de las opciones que permite.
- ^ Landley, Rob. "Charla Toybox CELF 2013" . landley.net . Consultado el 21 de agosto de 2013 .
GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
- ^ Asay, Clark D. "Revisión de la ley de tecnología y telecomunicaciones de Michigan Volumen 14 - Edición 22008 La licencia pública general Versión 3.0: Hacer o romper el movimiento Foss" . law.umich.edu.
Al final, GPLv3 constituye la proliferación de licencias.
- ^ Nikolai Bezroukov (2000). "Méritos comparativos de GPL, BSD y licencias artísticas (Crítica de la naturaleza viral de GPL v.2 - o en defensa de la idea de licencia dual)" . Archivado desde el original el 22 de diciembre de 2001.
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 dificultan innecesariamente la vida de los desarrolladores que trabajan en el Entorno Linux (KDE es un buen ejemplo aquí, Python es un ejemplo menos conocido). Creo que estos mezquinos esfuerzos por interpretar la GPL como un "texto sagrado" son una discusión no productiva que no nos lleva a ninguna parte. Y contribuyeron directamente a la proliferación de diferentes licencias de "software libre".
- ^ Byfield, Bruce (22 de noviembre de 2011). "7 razones por las que el software libre está perdiendo influencia: página 2" . Datamation .com . Consultado el 23 de agosto de 2013 .
En ese momento, la decisión parecía sensata frente a un punto muerto. Pero ahora, GPLv2 se utiliza para el 42,5% del software libre y GPLv3 para menos del 6,5%, según Black Duck Software.
- ^ James EJ Bottomley, Mauro Carvalho Chehab, Thomas Gleixner, Christoph Hellwig, Dave Jones, Greg Kroah-Hartman, Tony Luck, Andrew Morton, Trond Myklebust, David Woodhouse (15 de septiembre de 2006). "Posición de los desarrolladores de kernel en GPLv3 - Los peligros y problemas con GPLv3" . LWN.net . Consultado el 11 de marzo de 2015 .
[...] dado que la FSF propone cambiar todos sus proyectos a GPLv3 y presionar a todos los demás proyectos con licencia GPL para que se muevan, prevemos que el lanzamiento de GPLv3 presagia la balcanización de todo el universo de código abierto en el que confiamos.
Mantenimiento de CS1: utiliza el parámetro de autores ( enlace ) - ^ Ronacher, Armin (23 de julio de 2013). "Licencias en un mundo de derechos de autor de publicaciones" . lucumr.pocoo.org . Consultado el 18 de noviembre de 2015 .
El Clusterfuck de compatibilidad de licencias: cuando la GPL está involucrada, las complejidades de la concesión de licencias se convierten en una versión no divertida de un acertijo. Tantas cosas a considerar y tantas interacciones a considerar. Y que las incompatibilidades GPL siguen siendo un problema que afecta activamente a las personas es algo que muchos parecen olvidar. Por ejemplo, uno pensaría que la incompatibilidad de la GPLv2 con la Licencia de software Apache 2.0 debería ser cosa del pasado ahora que todo se actualiza a la GPLv3, pero resulta que suficientes personas están atrapadas solo con GPLv2 o no están de acuerdo con el GPLv3 que algunos proyectos con licencia de Apache Software deben migrar. Por ejemplo, Bootstrap de Twitter está migrando actualmente de ASL2.0 a MIT precisamente porque algunas personas todavía necesitan compatibilidad con GPLv2. Entre los proyectos que se vieron afectados se encuentran Drupal, WordPress, Joomla, MoinMoin Wiki y otros. E incluso ese caso muestra que a la gente ya no le importan mucho las licencias, ya que Joomla 3 solo incluía bootstrap a pesar de que no eran licencias de una manera compatible (GPLv2 vs 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 va bien con la GPL. Esa licencia también sigue siendo incompatible con la GPLv3. Todo el calvario es particularmente interesante ya que algunas partes no tan agradables han comenzado a hacer trolling de licencias a través de licencias GPL.
- ^ ¿Está seguro de que desea utilizar la GPL? de Armin Ronacher (2009)
- ^ Compartir software médico: licencias de FOSS en medicina en freesoftwaremagazine.com por Fred Trotter (14 de junio de 2007)
- ^ "Blog de David A. Wheeler" . dwheeler.com .
- ^ GitHub finalmente se toma en serio las licencias de código abierto en Infoworld por Simon Phipps en julio de 2013
- ^ La elección de una licencia de código abierto no tiene por qué dar miedo. ¿Cuál de las siguientes opciones describe mejor su situación? en choosealicense.com (consultado el 29-11-2015)
- ^ Uso de licencia de código abierto en GitHub.com el 9 de marzo de 2015 por Ben Balter en github.com "MIT 44.69%, [...] GPLv2 12.96%, Apache 11.19%, GPLv3 8.88%"
- ^ Ed Burnette (2 de noviembre de 2006). "Google dice no a la proliferación de licencias" . Archivado desde el original el 24 de febrero de 2007 . Consultado el 11 de septiembre de 2010 .
- ^ Greg Stein (28 de mayo de 2009). "Contra la proliferación de licencias" . Archivado desde el original el 1 de junio de 2008 . Consultado el 11 de septiembre de 2010 .
- ^ Proliferación de licencias: menos es más, uno es mejor el 27 de enero de 2009 por Ernest M. Park "Chris DiBona de Google sufrió los golpes y flechas de la comunidad OSS cuando rechazó la licencia AGPLv3 para el repositorio de Google Code, citando la proliferación de licencias como una de las razones."
- ^ Chris DiBona (10 de septiembre de 2010). "Proyectos de alojamiento y evolución de licencias en Code.Google.Com" . Consultado el 11 de septiembre de 2010 .
- ^ Licencias aprobadas por OSI en opensource.org
- ^ Proyecto de proliferación de licencias en opensource.com (2004)
- ^ Informe de proliferación de licencias archivado el 12 de diciembre de 2012en Wayback Machine en opensource.com (2007)
- ^ La primera versión archivada de la lista de licencias refleja esta posición. Bradley M. Kuhn (15 de agosto de 2000). "Varias licencias y comentarios sobre ellas" . Fundación de Software Libre. págs. 37–39. Archivado desde el original el 15 de agosto de 2000 . Consultado el 29 de noviembre de 2015 .
- ^ Cómo GPLv3 aborda la proliferación de licencias en linuxdevices.com
- ^ Marson, Ingrid (31 de marzo de 2005). "Intel dejará de usar la licencia de código abierto" . cnet.com . CNet . Consultado el 6 de octubre de 2014 .
- ^ El mito de la proliferación de licencias de código abierto en the451group.com
- ^ Proliferación de licencias de código abierto: ¿diversidad útil o confusión desesperada? on law.washington.edu por Robert W. Gomulkiewicz en 2009
- ^ Compatibilidad de licencia en osscc.net
turn.com
enlaces externos
- Proliferación de licencias de código abierto, una visión más amplia de Raymond Nimmer
- Larry Rosen sostiene que diferentes licencias pueden ser algo bueno Larry Rosen
- Cómo obtener licencias por Eric S. Raymond
- Proliferación de licencias para software médico por Fred Trotter Advoca que para software de salud, solo se deben usar los siete de Google.
- Cómo elegir una licencia para su propio trabajo Free Software Foundation