Licencia de software permisiva

Licencia con restricciones mínimas

Una licencia de software permisiva , a veces también llamada licencia similar a BSD o licencia estilo BSD , [1] es una licencia de software libre que, en lugar de protecciones copyleft , conlleva solo restricciones mínimas sobre cómo se puede usar, modificar y redistribuir el software, que generalmente incluyen una exención de responsabilidad de garantía . Algunos ejemplos incluyen la Licencia totalmente permisiva de GNU , la Licencia MIT , las licencias BSD , la Licencia de código público de Apple y la licencia Apache . A partir de 2016, la licencia de software libre más popular es la licencia permisiva MIT . [2] [3][actualizar]

Tabla comparativa

Dominio público y equivalentesLicencia permisivaCopyleft (licencia de protección)Licencia no comercialLicencia propietariaSecreto comercial
DescripciónOtorga todos los derechosOtorga derechos de uso, no prohíbe casi nada (permite propiedad, compatibilidad de licencias )Otorga derechos de uso, prohíbe la propiedadOtorga derechos únicamente para uso no comercial. No se puede combinar con copyleft.Uso tradicional de los derechos de autor ; no es necesario conceder derechosNo se ha hecho pública ninguna información
SoftwarePD, CC0BSD , MIT , ApacheLicencia GPL , Licencia AGPLJRL , AFPLsoftware propietario , sin licencia públicasoftware privado interno
Otras obras creativasPD, CC0CC BYCC BY-SA , Licencia de Arte LibreCC BY-NC , CC BY-NC-SADerechos de autor , sin licencia públicainédito

Ejemplo

El siguiente es el texto completo de la licencia GNU totalmente permisiva :

Derechos de autor <AÑO>, <AUTORES>

Se permite la copia y distribución de este archivo, con o sin modificaciones, en cualquier medio sin regalías, siempre que se conserve el aviso de derechos de autor y este aviso. Este archivo se ofrece tal como está, sin garantía alguna.

Definiciones

La Iniciativa de Código Abierto define una licencia de software permisiva como una "licencia sin copyleft que garantiza las libertades de usar, modificar y redistribuir". [6] El sitio web choosealicense de GitHub describe la licencia permisiva MIT como "[permitir] que las personas hagan lo que quieran con su código siempre que le proporcionen la atribución y no lo hagan responsable ". [7] newmediarights.com de la Facultad de Derecho de California Western las definió de la siguiente manera: "Las licencias 'similares a BSD' como las licencias BSD, MIT y Apache son extremadamente permisivas, y requieren poco más que atribuir las partes originales del código licenciado a los desarrolladores originales en su propio código y/o documentación". [1]

Comparación con copyleft

Las licencias copyleft generalmente exigen la publicación recíproca del código fuente de cualquier versión modificada bajo la licencia copyleft de la obra original. [8] [9] Las licencias permisivas, por el contrario, no intentan garantizar que las versiones modificadas del software seguirán siendo gratuitas y disponibles públicamente, y generalmente sólo exigen que se conserve el aviso de copyright original. [1] Como resultado, las obras derivadas, o versiones futuras, de software con licencia permisiva pueden publicarse como software propietario. [10]

Sin embargo, definir cuán liberal es una licencia no es algo fácilmente cuantificable y a menudo depende de los objetivos de los usuarios finales. Si estos últimos son desarrolladores, para algunos puede ser valioso tener el derecho a modificar y explotar el código fuente escrito por otros y posiblemente incorporarlo a código propietario y ganar dinero con él (y por lo tanto, estos ven las licencias permisivas como una forma de ofrecerles un "derecho"), [11] mientras que para otros desarrolladores puede ser más valioso saber que nadie capitalizará nunca lo que ha sido en gran parte su trabajo (y por lo tanto estos ven las licencias copyleft como una forma de ofrecerles un "derecho"). Además, los usuarios finales pueden no ser desarrolladores en absoluto, y en este caso las licencias copyleft les ofrecen el derecho eterno de acceder a un software como software libre, asegurando que nunca se convertirá en código cerrado, mientras que las licencias permisivas no ofrecen ningún derecho a los usuarios finales no desarrolladores, y el software publicado con una licencia permisiva podría, en teoría, convertirse de un día para otro en un malware de código cerrado sin que el usuario lo sepa.

Las licencias permisivas ofrecen una compatibilidad de licencias más amplia que las licencias copyleft, que generalmente no se pueden combinar ni mezclar libremente, porque sus requisitos de reciprocidad entran en conflicto entre sí. [12] [13] [14] [15] [16]

Comparación con el dominio público

En Computer Associates Int'l v. Altai se utilizó el término "dominio público" para referirse a obras que se han compartido y distribuido ampliamente con permiso, en lugar de obras que se han puesto deliberadamente en el dominio público. Sin embargo, las licencias permisivas no son en realidad equivalentes a publicar una obra en el dominio público .

Las licencias permisivas suelen estipular algunos requisitos limitados, como que se debe dar crédito a los autores originales ( atribución ). Si una obra es verdaderamente de dominio público, esto no suele ser un requisito legal, pero un registro de derechos de autor en los Estados Unidos exige divulgar material que se haya publicado previamente [17] y la atribución puede seguir considerándose un requisito ético en el ámbito académico .

Los defensores de las licencias permisivas a menudo recomiendan no intentar publicar software en el dominio público, con el argumento de que esto puede ser legalmente problemático en algunas jurisdicciones. [18] [19] Las licencias equivalentes al dominio público son un intento de resolver este problema, proporcionando una licencia permisiva de respaldo para los casos en que la renuncia de los derechos de autor no es legalmente posible y, a veces, también incluyen una exención de garantías similar a la mayoría de las licencias permisivas.

Compatibilidad de licencias

Compatibilidad de licencias entre licencias de software libre y de código abierto (FOSS) según David A. Wheeler (2007): las flechas vectoriales indican una compatibilidad unidireccional, por lo tanto, mejor compatibilidad en el lado izquierdo ("licencias permisivas") que en el lado derecho ("licencias copyleft"). [20]

En general, las licencias permisivas tienen una buena compatibilidad con la mayoría de las demás licencias de software en la mayoría de las situaciones. [12] [13]

Debido a su falta de restricciones, la mayoría de las licencias de software permisivas son compatibles incluso con las licencias copyleft, que son incompatibles con la mayoría de las demás licencias. Algunas licencias permisivas más antiguas, como la licencia BSD de 4 cláusulas , la licencia PHP y la licencia OpenSSL , tienen cláusulas que exigen que los materiales publicitarios den crédito al titular de los derechos de autor, lo que las hace incompatibles con las licencias copyleft. Sin embargo, las licencias permisivas modernas populares, como la licencia MIT , la licencia BSD de 3 cláusulas y la licencia zlib , no incluyen cláusulas publicitarias y, en general, son compatibles con las licencias copyleft.

Algunas licencias no permiten que las obras derivadas agreguen una restricción que indique que un redistribuidor no puede agregar más restricciones. Algunos ejemplos son la CDDL y la MsPL . Sin embargo, dichas restricciones también hacen que la licencia sea incompatible con las licencias de software libre permisivas. [ cita requerida ]

Recepción y adopción

Si bien se han utilizado desde mediados de la década de 1980, [21] varios autores notaron un aumento en la popularidad de las licencias permisivas durante la década de 2010. [22] [23] [24] [25]

A partir de 2015, [actualizar]la Licencia MIT , una licencia permisiva, es la licencia de software libre más popular, seguida por la GPLv2 . [2] [3]

Otros términos

Sin copyleft

Una licencia "permisiva" es simplemente una licencia de código abierto sin copyleft.

En ocasiones la palabra “permisivo” se considera demasiado ambigua, porque todas las licencias de software libre son “permisivas”, en el sentido de que todas permiten modificar y redistribuir el código fuente. En la mayoría de los casos la verdadera oposición se da entre licencias copyleft y no copyleft, por lo que algunos autores prefieren utilizar el término “no copyleft” en lugar de “permisivo”. [27] [28] [26]

Centro de copiado

Berkeley tenía lo que llamábamos "centro de copias", que es "llévalo al centro de copias y haz tantas copias como quieras".

—Mariscal  Kirk McKusick , [29]

Copycenter es un término utilizado originalmente para explicar la licencia BSD modificada , una licencia de software libre permisiva. El término fue presentado por el científico informático y colaborador de Berkeley Software Distribution (BSD) Marshall Kirk McKusick en una conferencia de BSD en 1999. Es un juego de palabras entre copyright , copyleft y copy center . [29] [30]

Licencia para personas que se dejan llevar

Las llamamos “licencias fáciles de aceptar” porque no pueden decir “no” cuando un usuario intenta negar la libertad a otros”.

—  Richard Stallman , fundador del sistema operativo GNU [31]

En la guía de la Free Software Foundation sobre compatibilidad de licencias y relicenciamiento, Richard Stallman define las licencias permisivas como "licencias fáciles de aceptar", comparándolas con aquellas de personas que "no pueden decir que no", porque se las considera como una concesión de un derecho a "negar la libertad a otros". [31] La Fundación recomienda licencias fáciles de aceptar sólo para programas pequeños, de menos de 300 líneas de código, donde "los beneficios proporcionados por el copyleft son normalmente demasiado pequeños para justificar el inconveniente de asegurarse de que una copia de la licencia siempre acompañe al software". [32]

Véase también

Referencias

  1. ^ abc New Media Rights (12 de septiembre de 2008). "Guía de licencias de código abierto". Facultad de Derecho de California Occidental .
  2. ^ ab "Top 20 licenses". Black Duck Software. 19 de noviembre de 2015. Archivado desde el original el 19 de julio de 2016. Consultado el 19 de noviembre de 2015. 1. Licencia MIT 24%, 2. Licencia pública general GNU (GPL) 2.0 23%, 3. Licencia Apache 16%, 4. Licencia pública general GNU (GPL) 3.0 9%, 5. Licencia BSD 2.0 (3 cláusulas, nueva o revisada) 6%, 6. Licencia pública general reducida GNU (LGPL) 2.1 5%, 7. Licencia artística (Perl) 4%, 8. Licencia pública general reducida GNU (LGPL) 3.0 2%, 9. Licencia pública Microsoft 2%, 10. Licencia pública Eclipse (EPL) 2%
  3. ^ ab Balter, Ben (9 de marzo de 2015). "Uso de licencias de código abierto en GitHub.com". github.com . Consultado el 21 de noviembre de 2015 ."1 MIT 44,69 %, 2 Otros 15,68 %, 3 GPLv2 12,96 %, 4 Apache 11,19 %, 5 GPLv3 8,88 %, 6 BSD 3 cláusulas 4,53 %, 7 Sin licencia 1,87 %, 8 BSD 2 cláusulas 1,70 %, 9 LGPLv3 1,30 %, 10 AGPLv3 1,05 %
  4. ^ Free Software Foundation, Varias licencias y comentarios sobre ellas, Licencia GNU totalmente permisiva
  5. ^ Información para mantenedores de software GNU, Avisos de licencia para otros archivos
  6. ^ permisivo en opensource.org "Una licencia "permisiva" es simplemente una licencia de código abierto sin copyleft: una que garantiza las libertades de usar, modificar y redistribuir, pero que permite derivados propietarios ".
  7. ^ Elegir una licencia de código abierto no tiene por qué ser aterrador en choosealicense.com "¿Cuál de las siguientes opciones describe mejor su situación? – La quiero simple y permisiva".
  8. ^ "¿Qué es Copyleft?". GNU . Consultado el 21 de abril de 2011 .
  9. ^ "Categorías de software libre y no libre". gnu.org.
  10. ^ Amadeo, Ron (21 de julio de 2018). "El férreo control de Google sobre Android: controlar el código abierto por todos los medios necesarios". Ars Technica .
  11. ^ Con esto en mente, el proyecto FreeBSD aboga por licencias permisivas para empresas y casos de uso comercial: dicen que imponen sólo "restricciones mínimas sobre el comportamiento futuro" y argumentan que las licencias copyleft son "bombas de tiempo legales" . Véase Montague, Bruce (2013-11-13). "Por qué debería usar una licencia estilo BSD para su proyecto de código abierto". FreeBSD . Consultado el 28 de noviembre de 2015 . 9. Ventajas y desventajas de la GPL [..] 12. Conclusión A diferencia de la GPL, que está diseñada para evitar la comercialización propietaria de código abierto, la licencia BSD impone restricciones mínimas sobre el comportamiento futuro. Esto permite que el código BSD siga siendo de código abierto o se integre en soluciones comerciales, a medida que cambian las necesidades de un proyecto o una empresa. En otras palabras, la licencia BSD no se convierte en una bomba de tiempo legal en ningún momento del proceso de desarrollo. Además, como la licencia BSD no tiene la complejidad legal de las licencias GPL o LGPL, permite a los desarrolladores y empresas dedicar su tiempo a crear y promover buen código en lugar de preocuparse si ese código viola la licencia.


  12. ^ ab "Compatibilidad de licencias". Licencia pública de la Unión Europea . 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 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").
  13. ^ ab Hanwell, Marcus D. (28 de enero de 2014). "¿Debería utilizar una licencia permisiva? ¿Copyleft? ¿O algo intermedio?". 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. 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.
  14. ^ "Preguntas frecuentes sobre las licencias GNU: ¿es compatible la GPLv3 con la GPLv2?". gnu.org . Consultado el 3 de junio de 2014 . 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.
  15. ^ Landley, Rob. "CELF 2013 Toybox talk". landley.net . Consultado el 21 de agosto de 2013. La GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
  16. ^ "Interpretación, aplicación y modificación de la GPL de GNU, tal como se aplica a la combinación de Linux y ZFS". fsf.org . Consultado el 8 de junio de 2020 .
  17. ^ Formulario CO de la Oficina de Derechos de Autor de Estados Unidos; véase también Ashton-Tate v. Fox
  18. ^ "Política de derechos de autor de OpenBSD". El proyecto OpenBSD . Consultado el 9 de junio de 2020 . En algunas jurisdicciones, es dudoso que sea legalmente posible colocar voluntariamente el propio trabajo en el dominio público. Por esa razón, para liberar cualquier cuerpo sustancial de código, es preferible indicar los derechos de autor y colocarlo bajo una licencia ISC o BSD en lugar de intentar liberarlo en el dominio público.
  19. ^ Hipp, D. Richard. "Por qué SQLite tuvo éxito como base de datos". El registro de cambios. Además, en ese momento no me di cuenta, ya que había vivido toda mi vida en los Estados Unidos, que es, ya sabes, un país con derecho consuetudinario británico, donde el dominio público es algo reconocido. No me di cuenta de que había muchas jurisdicciones en el mundo donde es difícil o imposible para alguien colocar sus obras en el dominio público. No lo sabía. Así que eso es una complicación.
  20. ^ Diapositiva sobre la licencia de software libre/de código abierto (FLOSS) por David A. Wheeler el 4 de octubre de 2021
  21. ^ Haff, Gordon. "La misteriosa historia de la licencia MIT". opensource.com . Consultado el 8 de junio de 2020. [ Hay] un buen argumento para afirmar que la licencia MIT, también llamada Consorcio X o Licencia X11 en ese momento, cristalizó con X11 en 1987, y esa es la mejor fecha para usar. Se podría argumentar que se creó en 1985 con posibles ajustes en los próximos años.
  22. ^ Vaughan-Nichols, Steven J. "La caída de la GPL y el auge de las licencias de código abierto permisivas". ZDNet . Consultado el 28 de noviembre de 2015. La GPL sigue siendo la licencia de código abierto más popular del mundo, pero su uso está disminuyendo, mientras que las licencias permisivas están ganando más seguidores y algunos desarrolladores están optando por publicar código sin licencia alguna.
  23. ^ Ronacher, Armin (23 de julio de 2013). "Licencias en un mundo posterior al copyright". lucumr.pocoo.org . Consultado el 18 de noviembre de 2015 .
  24. ^ Aslett, Matthew (6 de junio de 2011). "La tendencia hacia las licencias permisivas". the451group.com. Archivado desde el original el 13 de octubre de 2015. Consultado el 28 de noviembre de 2015 .
  25. ^ ¿Su código necesita una licencia? Publicado el 2 de mayo de 2013 por Jason Hibbets "P: ¿Existen empresas de desarrollo de software que prefieran una determinada licencia de código abierto en lugar de otra? ¿Cuál es la tendencia en la comunidad? R: Definitivamente estamos viendo algunas tendencias que se alejan de las licencias copyleft, principalmente hacia licencias permisivas"
  26. ^ ab "Preguntas frecuentes | Iniciativa de código abierto". Iniciativa de código abierto . Consultado el 9 de agosto de 2022 . Una licencia "permisiva" es simplemente una licencia de código abierto sin copyleft
  27. ^ "Licencias copyleft versus no copyleft en software libre/de código abierto". Qoppa Software . 2014-11-21 . Consultado el 2022-08-09 .
  28. ^ Sen, Ravi; Subramaniam, Chandrasekar; Nelson, Matthew L. (2011). "Licencias de software de código abierto: ¿copyleft fuerte, no copyleft o algo intermedio?". Decision Support Systems . 52 (1): 199–206. doi :10.1016/j.dss.2011.07.004. ISSN  0167-9236 . Consultado el 9 de agosto de 2022 .
  29. ^ ab "Añadir el comentario de Kirk sobre "copycenter"; es demasiado bueno para dejarlo pasar". Base de datos histórica fortune(6) de FreeBSD . Consultado el 8 de junio de 2020 .
  30. ^ Raymond, Eric S. "copycenter". El archivo de jerga.
  31. ^ ab Stallman, Richard (8 de febrero de 2016). "Compatibilidad de licencias y renovación de licencias". Free Software Foundation . Consultado el 29 de septiembre de 2019. En general, las licencias permisivas laxas ( BSD modificado , X11 , Expat , Apache , Python , etc.) son compatibles entre sí. Esto se debe a que no tienen requisitos sobre otro código que se agrega al programa. Incluso permiten colocar el programa completo (quizás con cambios) en un producto de software propietario; por lo tanto, las llamamos "licencias fáciles de aceptar" porque no pueden decir "no" cuando un usuario intenta negar la libertad a otros.
  32. ^ Cómo elegir una licencia para tu propio trabajo – Free Software Foundation
Obtenido de "https://es.wikipedia.org/w/index.php?title=Licencia_de_software_permisiva&oldid=1248568845"