stringtranslate.com

Licencia de software

Diagrama de software bajo varias 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 lo tanto en su mayoría ortogonales , "descarga gratuita" ( Freeware ).

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

Desde la década de 1970, los derechos de autor del software han sido reconocidos 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 imponer condiciones de redistribución más estrictas. Muy pocos compradores leen alguna parte de la licencia, inicialmente contratos retractilados y ahora más comúnmente encontrados como clickwrap o browserwrap . La aplicabilidad de este tipo de licencia es motivo de controversia y está limitada en algunas jurisdicciones. Los acuerdos de nivel de servicio son otro tipo de licencia de software en el que el proveedor se compromete a proporcionar un nivel de servicio al comprador, a menudo respaldado por sanciones financieras.

Copyleft es un tipo de licencia gratuita que exige la licencia de obras derivadas . Los otros tipos de licencia gratuita carecen de este requisito: para las licencias permisivas , la atribución suele ser el único requisito y las licencias equivalentes a 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: permitir la redistribución y trabajos derivados bajo la misma licencia, acceso sin restricciones al código fuente y no discriminación entre diferentes usos; en particular, permitir 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 de computadora está protegido por la ley de derechos de autor que confiere 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 secretos comerciales y se ocultan mediante métodos como los acuerdos de confidencialidad . [10] Los derechos de autor del software han sido reconocidos 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 licencia de software de prueba beta breve y escrita emitida por Macromedia en 1995

La tendencia a licenciar software propietario , en lugar de venderlo, data del período anterior a su existencia, entonces el alcance de la protección de los derechos de autor del software era 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 compró una licencia perpetua para utilizar una versión particular del software. [14] Los proveedores de software como servicio (SaaS), que tienen la participación mayoritaria en el mercado de software de aplicaciones a partir de 2023 [15] , rara vez ofrecen licencias perpetuas. [16] Las licencias SaaS suelen ser temporales y se cobran mediante pago por uso o suscripción, [17] aunque también se utilizan otros modelos de ingresos como freemium . [18] Para los clientes, las ventajas de las licencias temporales incluyen un costo inicial reducido, una 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 acuerdos de licencia de usuario final (EULA) se imprimían en el embalaje retráctil que recubría el producto (consulte el contrato de embalaje retráctil ) o en una hoja de papel. La licencia a menudo estipulaba que el cliente aceptaba si no devolvía el producto dentro de un intervalo específico. [20] Más recientemente, los EULA se encuentran más comúnmente como clickwrap o browserwrap, donde los clics del usuario o la navegación continua se toman como una señal de acuerdo. Como resultado del fin de las limitaciones físicas, la longitud aumentó. [21] La mayoría de los EULA han sido diseñados 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 el acceso, muy pocos consumidores leen alguna parte del acuerdo de licencia. [22] [23] La mayoría asume que los términos son inobjetables o apenas se dan cuenta de que están de acuerdo al instalar el software. [24] Las empresas aprovechan 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 de software derivado y la ingeniería inversa suelen estar explícitamente prohibidos. [26] Muchos EULA permiten al proveedor recopilar información sobre el usuario y utilizarla sin restricciones. [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 renuncia a cualquier responsabilidad por los daños causados ​​por el producto [30] e impide que el comprador acceda al sistema judicial para buscar una reparación. [31] Además, muchos EULA permiten al proveedor cambiar los términos en cualquier momento y el cliente debe elegir entre aceptar o dejar de usar el producto, sin recibir un reembolso. [32] Es común que los EULA permitan la rescisión unilateral por parte del proveedor por varias razones vagas o ninguna en absoluto. [33]

Los EULA, que casi siempre se ofrecen bajo la modalidad de tómalo o déjalo como 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 acuerdan sus propios términos. Libre albedrío. [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 browserwrap no se consideraban vinculantes, pero desde entonces lo han sido con frecuencia. [36] [21] Según la Nueva Directiva de Contenidos Digitales vigente en la Unión Europea, los EULA solo son ejecutables en la medida en que no violen 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 propiedad de contenido digital. [37] Muchos EULA contienen estipulaciones que probablemente no se puedan hacer cumplir dependiendo de 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 para responder a un problema planteado por el cliente. Muchos estipulan sanciones económicas si el servicio no alcanza el nivel acordado. [39] Los SLA a menudo cubren aspectos tales como disponibilidad, confiabilidad, precio y seguridad utilizando 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 administrados por diferentes empresas. [41] Los SLA en computación en la nube son un área bajo investigación activa a partir de 2024 . [42]

Licencias de software gratuitas 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] La concesión de licencias 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 cumplan 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 como 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 las siguientes 1% de cuota de mercado cada uno.
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 software, las licencias Creative Commons exclusivamente no comerciales se han vuelto populares entre algunos artistas que desean evitar que otros se beneficien excesivamente de su trabajo. [51] Sin embargo, el software que está disponible únicamente para uso no comercial no se considera de código abierto. [8] La licencia de investigación Java no comercial exclusiva de Sun Microsystems fue rechazada por la comunidad de código abierto y, en 2006, la empresa lanzó la mayor parte de Java bajo la GPL. [8]

Compatibilidad

Tabla de compatibilidad para algunas licencias de software de código abierto

Desde 1989, [43] se han creado una variedad de licencias de software de código abierto . [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 sencillo, cumplir con los términos de la licencia puede resultar 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 el 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 inequívocamente 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 existe ningún reclamo de derechos de autor, pero el código adquirido bajo casi cualquier conjunto de términos no se puede transferir al dominio público. Se pueden utilizar licencias permisivas en 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 sólo se puede utilizar bajo GPL o AGPL. [62]

Aplicabilidad

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 normalmente logran el cumplimiento sin demandas. Las presiones sociales, como la posibilidad de una reacción comunitaria, 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 simple licencia es un conjunto de condiciones bajo las cuales se permiten acciones restringidas por las leyes de propiedad intelectual . [63] Según la interpretación de la licencia simple, defendida por la Free Software Foundation (FSF), el titular de los derechos de autor lleva un caso ante los tribunales como infracción de derechos de autor . [63] Según la interpretación del contrato, una parte involucrada puede llevar un caso ante los tribunales como incumplimiento de contrato . [68] Los tribunales estadounidenses y franceses han juzgado casos conforme a ambas interpretaciones. [69]

Valor

Más del 90 por ciento de las empresas utilizan software de código abierto como 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, suele ser una decisión empresarial pragmática. [71] [72] Cuando el software propietario compite directamente con una alternativa de código abierto, la investigación ha 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 convertido en su modelo de negocio el servicio de un producto de software de código abierto para usuarios empresariales. 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]

Ver también

Referencias

  1. ^ abc O'Regan 2022, pag. 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 y col. 2012, Licencia de software libre y de código abierto (FOSS).
  5. ^ ab O'Regan 2022, pag. 394.
  6. ^ O'Regan 2022, pag. 396.
  7. ^ Fagundes y Perzanowski 2020, pag. 524.
  8. ^ abcd Dávila 2015, pag. 6.
  9. ^ ab Boyle 2003, pág. 45.
  10. ^ O'Regan 2022, págs. 394–396.
  11. ^ Larry Troan (2005). "Código abierto desde una perspectiva patentada" (PDF) . Cumbre RedHat 2006 Nashville . redhat.com. pag. 10. Archivado desde el original (PDF) el 22 de enero de 2014 . Consultado el 29 de diciembre de 2015 .
  12. ^ ab Terasaki 2013, pag. 469.
  13. ^ Terasaki 2013, págs. 469–470.
  14. ^ ab Clohessy y col. 2020, págs. 40–41.
  15. ^ Vatio 2023, pag. 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. ^ ab Corbett 2019, pag. 455.
  21. ^ ab Kim 2016, págs.12, 21.
  22. ^ Bakos y col. 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 y col. 2012, Licencias de propiedad.
  27. ^ Carpintero 2023, págs. 485–486.
  28. ^ Ahuja 2016, pag. 381.
  29. ^ Corbett 2019, pag. 456.
  30. ^ Carpintero 2023, págs. 480–481.
  31. ^ Carpintero 2023, págs. 481–482.
  32. ^ Carpintero 2023, pag. 485.
  33. ^ Carpintero 2023, págs. 482–483.
  34. ^ Carpintero 2023, pag. 478.
  35. ^ Corbett 2019, pag. 460.
  36. ^ Terasaki 2013, pag. 471.
  37. ^ Oprysk y Sein 2020, págs.
  38. ^ Corbett 2019, pag. 461.
  39. ^ O'Regan 2022, págs.151, 219, 224, 405.
  40. ^ Qazi y col. 2024, Parámetros de evaluación del desempeño.
  41. ^ Rana y Ziegler 2010, pag. 188.
  42. ^ Qazi y col. 2024, Conclusión.
  43. ^ ab Bernelin 2020, pag. 96.
  44. ^ abcdef Sen, Subramaniam y Nelson 2008, p. 209.
  45. ^ Morin y col. 2012, Código abierto versus código cerrado.
  46. ^ abc Morin y col. 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, pag. 5.
  51. ^ ab Dávila 2015, págs. 5-6.
  52. ^ Alegría 2022, págs. 990–992.
  53. ^ Sen, Subramaniam y Nelson 2008, pág. 208.
  54. ^ Alamoudi y col. 2020, pág. 537.
  55. ^ Bernelín 2020, pag. 94.
  56. ^ ab Morin y col. 2012, Compatibilidad, Proliferación, Fragmentación y Direccionalidad.
  57. ^ Bernelín 2020, pag. 98.
  58. ^ Bernelin 2020, págs.100, 102.
  59. ^ ab Ombredanne 2020, pag. 105.
  60. ^ Ombredanne 2020, pag. 106.
  61. ^ St. Laurent 2004, págs. 159-163.
  62. ^ Smith 2022, § 3.3.
  63. ^ abc Smith 2022, § 3.4.1.
  64. ^ Smith 2022, pag. 106.
  65. ^ St. Laurent 2004, págs. 158-159.
  66. ^ Ballhausen 2022, pag. 127.
  67. ^ Walden 2022, § 1.1.
  68. ^ Smith 2022, § 3.4.2.
  69. ^ Smith 2022, § 3.4.
  70. ^ Mayordomo y col. 2022, pág. 1.
  71. ^ Mayordomo y col. 2022, pág. 11152.
  72. ^ Dávila 2015, pag. 7.
  73. ^ Zhou y Choudhary 2022, pag. 731.
  74. ^ Agosto y otros. 2021, págs. 1-2.
  75. ^ Agosto y col. 2021, pág. 1.

Fuentes

Otras lecturas

enlaces externos