stringtranslate.com

Licencia de software

Diagrama de software bajo distintas licencias según la FSF y su Definición de Software Libre : en el lado izquierdo “ software libre ”, en el lado derecho “ software propietario ”. En ambos lados, y por tanto mayoritariamente ortogonales , “descarga gratuita” ( Freeware ).

Una licencia de software es un instrumento legal que rige el uso o la redistribución del software.

Desde la década de 1970, los derechos de autor del software se reconocen en los Estados Unidos. A pesar de que se reconocen los derechos de autor, la mayoría de las empresas prefieren vender licencias en lugar de copias del software porque les permite aplicar condiciones más estrictas en la redistribución. Muy pocos compradores leen alguna parte de la licencia, inicialmente contratos de envoltura retráctil y ahora más comúnmente encontrados como clickwrap o browsewrap . La exigibilidad de este tipo de licencia es un tema de controversia y está limitada en algunas jurisdicciones. Los acuerdos de nivel de servicio son otro tipo de licencia de software en la que el vendedor acepta proporcionar un nivel de servicio al comprador, a menudo respaldado por sanciones económicas.

Copyleft es un tipo de licencia libre que obliga a licenciar las obras derivadas . Los otros tipos de licencia libre carecen de este requisito: en el caso de las licencias permisivas , la atribución suele ser el único requisito, y las licencias equivalentes al dominio público no tienen restricciones. La proliferación de licencias de código abierto ha agravado los problemas de compatibilidad de licencias , pero todas comparten algunas características: permiten la redistribución y las obras derivadas bajo la misma licencia, el acceso sin restricciones al código fuente y la no discriminación entre diferentes usos, en particular, permiten el uso comercial.

Derechos de autor del software

El código fuente (o los binarios compilados en forma de código objeto ) [9] de un programa informático está protegido por la ley de derechos de autor que otorga al propietario el derecho exclusivo de copiar el código. Las ideas o algoritmos subyacentes no están protegidos por la ley de derechos de autor, pero a menudo se tratan como un secreto comercial y se ocultan mediante métodos como los acuerdos de confidencialidad . [10] Los derechos de autor del software se reconocen desde mediados de la década de 1970 y pertenecen a la empresa que fabrica el software, no a los empleados o contratistas que lo escribieron. [1]

Licencias de software propietario

Una breve licencia de software de prueba beta escrita emitida por Macromedia en 1995

La tendencia a licenciar software propietario , en lugar de venderlo, data del período de tiempo anterior a la existencia, cuando el alcance de la protección de los derechos de autor del software estaba claro . Estas licencias han seguido utilizándose después de que los derechos de autor del software fueran reconocidos en los tribunales, y se considera que otorgan a la empresa una protección adicional en comparación con la ley de derechos de autor. [12] Según la ley federal de los Estados Unidos , una empresa puede restringir las partes a las que vende, pero no puede impedir que un comprador revenda el producto. Los acuerdos de licencia de software suelen prohibir la reventa, lo que permite a la empresa maximizar los ingresos. [13]

Tradicionalmente, el software se distribuía en forma de código objeto binario que el usuario no podía entender ni modificar [9] , pero que podía descargarse y ejecutarse. El usuario compraba una licencia perpetua para utilizar una versión particular del software [14] . Los proveedores de software como servicio (SaaS), que tienen la mayor participación de mercado en el software de aplicación a partir de 2023 [15], rara vez ofrecen licencias perpetuas [16] . Las licencias SaaS suelen ser temporales y se cobran por uso o suscripción [17] , aunque también se utilizan otros modelos de ingresos como el freemium [18] . Para los clientes, las ventajas de las licencias temporales incluyen un costo inicial reducido, mayor flexibilidad y un costo general más bajo en comparación con una licencia perpetua [14] . En algunos casos, el elevado costo único exigido por los vendedores de software tradicional estaba fuera del alcance de las empresas más pequeñas , pero los modelos SaaS de pago por uso hacen que el software sea asequible [19] .

Acuerdo de licencia de usuario final (EULA)

Inicialmente, los contratos de licencia de usuario final (EULA) se imprimían en el envoltorio retráctil que envolvía el producto (ver contrato de envoltorio retráctil ) o en un trozo de papel. La licencia a menudo estipulaba que el cliente aceptaba si no devolvía el producto dentro de un intervalo especificado. [20] Más recientemente, los EULA se encuentran más comúnmente como clickwrap o browsewrap donde los clics del usuario o la navegación continua se toman como una señal de acuerdo. Como resultado del fin de las restricciones físicas, la longitud aumentó. [21] La mayoría de los EULA se han diseñado de manera que sea muy difícil leerlos y comprenderlos, pero fácil aceptar los términos de la licencia sin leerlos. [12] [20] Independientemente de lo fácil que sea acceder a ellos, muy pocos consumidores leen alguna parte del contrato de licencia. [22] [23] La mayoría asume que los términos son inobjetables o apenas notan la aceptación mientras instalan el software. [24] Las empresas se aprovechan de la falta de atención de los consumidores para insertar disposiciones en los EULA. [25]

El software propietario suele ofrecerse bajo una licencia restrictiva que prohíbe la copia y la reutilización y, a menudo, limita al comprador a utilizar el software en una sola computadora. [5] [26] El código fuente rara vez está disponible. Los trabajos derivados del software y la ingeniería inversa suelen estar prohibidos explícitamente. [26] Muchos EULA permiten al vendedor recopilar información sobre el usuario y utilizarla de forma ilimitada. [27] Algunos EULA restringen la capacidad de los usuarios de ejercer los derechos de autor sobre trabajos derivados realizados con el software, como creaciones creativas en los mundos virtuales de los videojuegos . [28] [29]

La mayoría de los EULA rechazan cualquier responsabilidad por los daños causados ​​por el producto, [30] e impiden al comprador acceder al sistema judicial para buscar una solución. [31] Además, muchos EULA permiten al vendedor cambiar los términos en cualquier momento y el cliente debe elegir entre aceptar o dejar de usar el producto, sin obtener un reembolso. [32] Es común que los EULA permitan la rescisión unilateral por parte del vendedor por cualquier cantidad de razones vagas o ninguna en absoluto. [33]

Los EULA, que casi siempre se ofrecen en condiciones de "tómalo o déjalo" como una condición no negociable para usar el software, [34] están muy lejos del contrato prototípico en el que ambas partes entienden completamente los términos y los aceptan por su propia voluntad. [35] Ha habido un debate sustancial sobre hasta qué punto los acuerdos pueden considerarse vinculantes. Antes de 1996 en los Estados Unidos, las licencias clickwrap o browsewrap no se consideraban vinculantes, pero desde entonces a menudo lo han sido. [36] [21] Según la Nueva Directiva de Contenido Digital en vigor en la Unión Europea, los EULA solo son exigibles en la medida en que no infrinjan las expectativas razonables de los consumidores. La brecha entre las expectativas y el contenido de los EULA es especialmente amplia cuando se trata de restricciones a la copia y transferencia de la propiedad de contenido digital. [37] Muchos EULA contienen estipulaciones que probablemente no sean exigibles según la jurisdicción. Los proveedores de software mantienen estas disposiciones inaplicables en los acuerdos, tal vez porque los usuarios rara vez recurren al sistema legal para impugnarlas. [38]

Acuerdo de nivel de servicio (SLA)

Los acuerdos de nivel de servicio se utilizan a menudo para el software empresarial y garantizan un nivel de servicio, como el rendimiento del software o el tiempo de respuesta a un problema planteado por el cliente. Muchos estipulan sanciones económicas si el servicio no cumple con el estándar acordado. [39] Los SLA suelen cubrir aspectos como la disponibilidad, la fiabilidad, el precio y la seguridad mediante métricas cuantificables. [40] Los SLA de varios niveles son comunes en la computación en la nube debido al uso de diferentes servicios informáticos que pueden ser gestionados por diferentes empresas. [41] Los SLA en la computación en la nube son un área en investigación activa a partir de 2024. [ 42]

Licencias de software libre y de código abierto

Antes del movimiento de código abierto en la década de 1980, casi todo el software era propietario y no revelaba su código fuente . [43] El licenciamiento de código abierto tiene como objetivo maximizar la apertura y minimizar las barreras al uso, la difusión y la innovación posterior del software. [4]

Las licencias de código abierto comparten una serie de características clave: [44]

La Iniciativa de Código Abierto examina y aprueba nuevas licencias de código abierto que cumplen con su Definición de Código Abierto . [44]

Tipos de licencias de código abierto

Un gráfico circular muestra las licencias de código abierto más utilizadas: Apache con un 30%, MIT con un 26%, GPL con un 18%, BSD con un 8%, LGPL con un 3%, MPL con un 2% y el 13% restante como licencias con una participación de mercado inferior al 1% cada una.
Las licencias de código abierto más populares a partir de 2022 son la licencia Apache (permisiva), la licencia MIT (permisiva) y la GPL (copyleft).

Fuera del ámbito del software, las licencias Creative Commons exclusivamente para uso no comercial se han vuelto populares entre algunos artistas que desean evitar que otros se beneficien excesivamente de su trabajo. [51] Sin embargo, el software que se pone a disposición únicamente para uso no comercial no se considera de código abierto. [8] La licencia de investigación Java exclusivamente para uso no comercial de Sun Microsystems fue rechazada por la comunidad de código abierto y, en 2006, la compañía lanzó la mayor parte de Java bajo la GPL. [8]

Compatibilidad

Cuadro de compatibilidad de algunas licencias de software de código abierto

Desde 1989, [43] se han creado diversas licencias de código abierto para software. [53] Elegir una licencia de software de código abierto se ha vuelto cada vez más difícil debido a la proliferación de licencias , [54] [55] muchas de las cuales son sólo trivialmente distintas. [56] Muchas licencias son incompatibles entre sí, lo que obstaculiza los objetivos del movimiento del software libre. [57] Los problemas de traducción, la ambigüedad en los términos de las licencias y la incompatibilidad de algunas licencias con la ley en ciertas jurisdicciones agravan el problema. [58]

Aunque descargar un módulo de código abierto es rápido y fácil, cumplir con los términos de la licencia puede ser más difícil. [59] La cantidad de dependencias de software significa que los ingenieros que trabajan en proyectos complejos a menudo deben confiar en software de gestión de licencias de software para ayudarlos a lograr el cumplimiento de los términos de licencia de los componentes de código abierto. [60] Muchos archivos de software de código abierto no indican de forma inequívoca la licencia, lo que aumenta las dificultades de cumplimiento. [59] Al combinar bases de código, las licencias originales se pueden mantener para componentes separados y el trabajo más grande se puede publicar bajo una licencia compatible. [61] Esta compatibilidad es a menudo unidireccional. El contenido de dominio público se puede utilizar en cualquier lugar ya que no hay reclamo de derechos de autor, pero el código adquirido bajo casi cualquier conjunto de términos no se puede dejar pasar al dominio público. Las licencias permisivas se pueden utilizar dentro de obras copyleft, pero el material copyleft no se puede publicar bajo una licencia permisiva. Algunas licencias copyleft débiles se pueden utilizar bajo la GPL y se dice que son compatibles con la GPL. El software GPL solo se puede utilizar bajo la GPL o AGPL. [62]

Ejecutividad

Las licencias de software libre y de código abierto se han aplicado con éxito en los tribunales civiles desde mediados de la década de 2000. [63] Los tribunales han determinado que la distribución de software indica la aceptación de los términos de la licencia. [64] Sin embargo, los desarrolladores suelen lograr el cumplimiento sin demandas judiciales. Las presiones sociales , como la posibilidad de una reacción negativa de la comunidad, suelen ser suficientes. [65] Las cartas de cese y desistimiento son un método común para que las empresas vuelvan a cumplir con las normas, especialmente en Alemania. [66]

Un tema largamente debatido dentro de la comunidad FOSS es si las licencias de código abierto son "licencias simples" o contratos . [67] Una licencia simple es un conjunto de condiciones bajo las cuales se permiten acciones que de otra manera estarían restringidas por las leyes de propiedad intelectual . [63] Bajo la interpretación de la licencia simple, defendida por la Free Software Foundation (FSF), un caso es llevado a la corte por el titular de los derechos de autor como infracción de los derechos de autor . [63] Bajo la interpretación del contrato, un caso puede ser llevado a la corte por una parte involucrada como incumplimiento del contrato . [68] Los tribunales de Estados Unidos y Francia han juzgado casos bajo ambas interpretaciones. [69]

Valor

Más del 90 por ciento de las empresas utilizan software de código abierto como un componente de su software propietario. [70] La decisión de utilizar software de código abierto, o incluso participar en proyectos de código abierto para mejorar el software de código abierto existente, es típicamente una decisión empresarial pragmática. [71] [72] Cuando el software propietario compite directamente con una alternativa de código abierto, las investigaciones han encontrado resultados contradictorios sobre el efecto de la competencia en el precio y la calidad del producto propietario. [73]

Durante décadas, algunas empresas han hecho del mantenimiento de un producto de software de código abierto para usuarios empresariales su modelo de negocio. Estas empresas controlan un producto de software de código abierto y, en lugar de cobrar por la licencia o el uso, cobran por las mejoras, la integración y otros servicios. [74] Los productos de software como servicio (SaaS) basados ​​en componentes de código abierto son cada vez más comunes. [75]

Se prefiere el software de código abierto para aplicaciones científicas porque aumenta la transparencia y ayuda en la validación y aceptación de los resultados científicos. [56]

Véase también

Referencias

  1. ^ abc O'Regan 2022, pág. 403.
  2. ^ ab "Licencias". Iniciativa de código abierto . 16 de septiembre de 2022 . Consultado el 12 de mayo de 2024 .
  3. ^ abcde Sen, Subramaniam y Nelson 2008, pág. 212.
  4. ^ abc Morin et al. 2012, Licencias de software libre y de código abierto (FOSS).
  5. ^ desde O'Regan 2022, pág. 394.
  6. ^ O'Regan 2022, pág. 396.
  7. ^ Fagundes y Perzanowski 2020, pag. 524.
  8. ^ abcd Dávila 2015, pág. 6.
  9. ^ desde Boyle 2003, pág. 45.
  10. ^ O'Regan 2022, págs. 394–396.
  11. ^ Larry Troan (2005). "Open Source from a Proprietary Perspective" (PDF) . RedHat Summit 2006 Nashville . redhat.com. pág. 10. Archivado desde el original (PDF) el 22 de enero de 2014. Consultado el 29 de diciembre de 2015 .
  12. ^ desde Terasaki 2013, pág. 469.
  13. ^ Terasaki 2013, págs. 469–470.
  14. ^ desde Clohessy et al. 2020, págs. 40–41.
  15. ^ Watt 2023, pág. 4.
  16. ^ Dempsey y Kelliher 2018, pag. 48.
  17. ^ Dempsey y Kelliher 2018, págs.48, 57.
  18. ^ Dempsey y Kelliher 2018, págs. 61–63.
  19. ^ Dempsey y Kelliher 2018, pag. 2.
  20. ^ desde Corbett 2019, pág. 455.
  21. ^ ab Kim 2016, págs. 12, 21.
  22. ^ Bakos y otros, 2014, pág. 1.
  23. ^ Ben-Shahar y Schneider 2014, pág. 68.
  24. ^ Terasaki 2013, págs. 485–486.
  25. ^ Corbett 2019, págs. 456–457.
  26. ^ ab Morin et al. 2012, Licencias de propiedad.
  27. ^ Carpenter 2023, págs. 485–486.
  28. ^ Ahuja 2016, pág. 381.
  29. ^ Corbett 2019, pág. 456.
  30. ^ Carpenter 2023, págs. 480–481.
  31. ^ Carpenter 2023, págs. 481–482.
  32. ^ Carpintero 2023, pág. 485.
  33. ^ Carpenter 2023, págs. 482–483.
  34. ^ Carpintero 2023, pág. 478.
  35. ^ Corbett 2019, pág. 460.
  36. ^ Terasaki 2013, pág. 471.
  37. ^ Oprysk y Sein 2020, págs. 620–621.
  38. ^ Corbett 2019, pág. 461.
  39. ^ O'Regan 2022, págs.151, 219, 224, 405.
  40. ^ Qazi et al. 2024, Parámetros de evaluación del desempeño.
  41. ^ Rana y Ziegler 2010, pag. 188.
  42. ^ Qazi y col. 2024, Conclusión.
  43. ^ desde Bernelin 2020, pág. 96.
  44. ^ abcdef Sen, Subramaniam y Nelson 2008, pág. 209.
  45. ^ Morin et al. 2012, Código abierto versus código cerrado.
  46. ^ abc Morin et al. 2012, Permisivo versus Copyleft.
  47. ^ Smith 2022, § 3.2.1.1.
  48. ^ Sen, Subramaniam y Nelson 2008, págs. 211-212.
  49. ^ St. Laurent 2004, págs. 38-39.
  50. ^ Dávila 2015, pág. 5.
  51. ^Ab Davila 2015, págs. 5–6.
  52. ^ Joy 2022, págs. 990–992.
  53. ^ Sen, Subramaniam y Nelson 2008, pág. 208.
  54. ^ Alamoudi y col. 2020, pág. 537.
  55. ^ Bernelin 2020, pág. 94.
  56. ^ ab Morin et al. 2012, Compatibilidad, proliferación, fragmentación y direccionalidad.
  57. ^ Bernelin 2020, pág. 98.
  58. ^ Bernelin 2020, págs. 100, 102.
  59. ^ desde Ombredanne 2020, pág. 105.
  60. ^ Ombredanne 2020, pág. 106.
  61. ^ St. Laurent 2004, págs. 159-163.
  62. ^ Smith 2022, § 3.3.
  63. ^abc Smith 2022, § 3.4.1.
  64. ^ Smith 2022, pág. 106.
  65. ^ St. Laurent 2004, págs. 158-159.
  66. ^ Ballhausen 2022, pág. 127.
  67. ^ Walden 2022, § 1.1.
  68. ^ Smith 2022, § 3.4.2.
  69. ^ Smith 2022, § 3.4.
  70. ^ Butler y otros. 2022, pág. 1.
  71. ^ Mayordomo y col. 2022, pág. 11152.
  72. ^ Dávila 2015, pág. 7.
  73. ^ Zhou y Choudhary 2022, pág. 731.
  74. ^ Agosto y otros. 2021, págs. 1-2.
  75. ^ Agosto et al. 2021, pág. 1.

Fuentes

Lectura adicional

Enlaces externos