stringtranslate.com

Licencia 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 populares incluyen la licencia Apache , la licencia MIT , la licencia pública general GNU (GPL), las licencias BSD , la licencia pública general reducida GNU (LGPL) y la licencia pública Mozilla (MPL).

Las licencias de código abierto son licencias de software que permiten utilizar, modificar y compartir contenido. Facilitan el desarrollo de software gratuito y de código abierto (FOSS). Las leyes de propiedad intelectual (PI) restringen la modificación y el intercambio de obras creativas. Las licencias gratuitas y de código abierto utilizan estas estructuras legales existentes para un propósito inverso. Otorgan al destinatario los derechos para utilizar el software, examinar el código fuente , modificarlo y distribuir las modificaciones. Estos criterios se describen en la Definición de código abierto .

Después de 1980, Estados Unidos comenzó a tratar el software como una obra literaria cubierta por la ley de derechos de autor. Richard Stallman fundó el movimiento del software libre en respuesta al auge del software propietario . El término "código abierto" fue utilizado por la Open Source Initiative (OSI), fundada por los desarrolladores de software libre Bruce Perens y Eric S. Raymond . El "código abierto" enfatiza las fortalezas del modelo de desarrollo abierto más que las libertades del software. Si bien los objetivos detrás de los términos son diferentes, las licencias de código abierto y las licencias de software libre describen el mismo tipo de licencias. [1]

Las dos categorías principales de licencias de código abierto son las permisivas y copyleft . Ambos otorgan permiso para cambiar y distribuir software. Por lo general, requieren atribución y exención de responsabilidad . Las licencias permisivas provienen del mundo académico. Las licencias copyleft provienen del movimiento del software libre. Las licencias copyleft requieren que las obras derivadas se distribuyan con el código fuente y bajo una licencia similar. Desde mediados de la década de 2000, los tribunales de varios países han confirmado los términos de ambos tipos de licencia. Los desarrolladores de software han presentado casos por infracción de derechos de autor e incumplimiento de contrato.

Fondo

El jurista Eben Moglen sobre la historia del derecho de autor

La propiedad intelectual (PI) es una categoría legal que trata la producción creativa como propiedad, comparable a la propiedad privada . [2] Los sistemas legales otorgan al propietario de una propiedad intelectual el derecho de restringir el acceso de muchas maneras. [3] Los propietarios pueden vender, arrendar, regalar o licenciar sus propiedades. [4] Múltiples tipos de leyes de propiedad intelectual cubren software, incluidas marcas comerciales , patentes y derechos de autor . [4]

La mayoría de los países, incluido Estados Unidos (EE.UU.), han creado leyes de derechos de autor de acuerdo con el Convenio de Berna . [5] Estas leyes asignan derechos de autor cada vez que una obra se publica en cualquier formato fijo. [6] Según la ley de derechos de autor de EE. UU., la publicación inicial se considera una obra original . [7] El creador, o su empleador, posee los derechos de autor de esta obra original y, por lo tanto, tiene el derecho exclusivo de hacer copias, publicar versiones modificadas, distribuir copias, actuar públicamente o mostrar la obra públicamente. Las versiones modificadas de la obra original son obras derivadas . [8] Cuando un creador modifica una obra existente, posee los derechos de autor de sus modificaciones. [9] A menos que la obra original sea de dominio público, una obra derivada sólo puede distribuirse con el permiso de cada titular de derechos de autor. [10]

En 1980, el gobierno de Estados Unidos modificó la ley para tratar el software como una obra literaria. El software lanzado después de este punto estaba restringido por las leyes de propiedad intelectual. [11] En ese momento, el activista y programador estadounidense Richard Stallman trabajaba como estudiante de posgrado en el Laboratorio de Ciencias de la Computación e Inteligencia Artificial del MIT . Stallman fue testigo de la fragmentación entre los desarrolladores de software. Culpó a la difusión del software propietario y a los modelos cerrados de desarrollo. Para contrarrestar estas tendencias, Stallman fundó el movimiento de software libre . [12] A lo largo de la década de 1980, inició el Proyecto GNU para crear un sistema operativo libre, escribió ensayos sobre la libertad, fundó la Free Software Foundation (FSF) y escribió varias licencias de software libre. [13] La FSF utilizó las leyes de propiedad intelectual existentes para el objetivo opuesto a su objetivo de restricción. En lugar de imponer restricciones, el software libre otorgaba explícitamente libertades al destinatario. [14]

Fotografía de Bruce Perens en una conferencia
Bruce Perens , autor de la definición de código abierto

En los años 90, se acuñó el término "código abierto" como una etiqueta alternativa para el software libre y se establecieron criterios específicos para determinar qué licencias cubrían el software libre y de código abierto. [15] [16] Dos miembros activos de la comunidad de software libre, Bruce Perens y Eric S. Raymond , fundaron la Open Source Initiative (OSI). [17] En Debian , Perens había propuesto las Directrices de software libre de Debian (DFSG). [18] Los DFSG se redactaron para proporcionar un estándar más específico y objetivo para el software libre que Debian alojaría en sus repositorios. [19] La OSI adoptó el DSFG y lo utilizó como base para su definición de código abierto. [20] La Free Software Foundation mantiene un conjunto de criterios rival, la Definición de Software Libre. [21] Históricamente, estas tres organizaciones y sus conjuntos de criterios han sido las autoridades notables a la hora de determinar si una licencia cubre software libre y de código abierto. [22] Existe una diversidad significativa entre las licencias individuales, pero poca diferencia entre las definiciones rivales. [16] Cada una de las tres definiciones requiere que las personas que reciben software cubierto puedan utilizar, modificar y redistribuir el trabajo cubierto. [23]

Eric S. Raymond fue un defensor del término " código abierto " en lugar de "software libre". Consideró que el código abierto era más atractivo para las empresas y reflejaba mejor las ventajas tangibles del desarrollo del software libre. Uno de los objetivos de Raymond era ampliar la comunidad de hackers existente para incluir a grandes desarrolladores comerciales. [24] En La catedral y el bazar , Raymond comparó el desarrollo de código abierto con el bazar , un mercado público al aire libre. [25] Sostuvo que, aparte de la ética, el modelo abierto proporcionaba ventajas que el software propietario no podía replicar. [26] [27] Raymond se centró en gran medida en comentarios , pruebas e informes de errores . [28] Contrastó el modelo propietario en el que pequeños grupos de trabajadores secretos llevaban a cabo este trabajo con el desarrollo de Linux, en el que el grupo de evaluadores incluía potencialmente a todo el mundo. [29] Resumió esta fortaleza como "Con suficientes ojos, todos los errores son superficiales". [30] La OSI logró llevar el desarrollo de código abierto a desarrolladores corporativos, incluidos Sun Microsystems, IBM , Netscape, Mozilla , Apache , Apple Inc., Microsoft y Nokia. Estas empresas publicaron código bajo licencias existentes y redactaron el suyo propio para ser aprobado por la OSI. [31] [32]

Tipos

Las licencias de código abierto se clasifican en copyleft o permisivas . [33] Las licencias Copyleft requieren que los trabajos derivados incluyan el código fuente bajo una licencia similar. Las licencias permisivas no lo hacen y, por lo tanto, el código se puede utilizar dentro del software propietario. El copyleft se puede dividir en fuerte y débil dependiendo de si definen las obras derivadas de manera amplia o restringida. [34] [35]

Las licencias se centran en la ley de derechos de autor, pero el código también está cubierto por otras formas de propiedad intelectual. [36] Las principales licencias de código abierto escritas desde finales de la década de 1990 contienen concesiones de patentes. Estas concesiones de patentes de código abierto cubren las patentes de los desarrolladores. [37] Las patentes de software cubren ideas y, más que una implementación específica, cubren cualquier implementación de una reivindicación . Las reclamaciones de patente otorgan al titular el derecho de excluir a otros de fabricar, utilizar, vender o importar productos basados ​​en la idea. Debido a que las patentes otorgan el derecho a excluir en lugar del derecho a crear, es posible tener una patente sobre una idea pero aun así no poder implementarla legalmente si la invención se basa en otra idea patentada. Por lo tanto, las concesiones de patentes de código abierto sólo pueden ofrecer permiso de patentes cubiertas. No pueden garantizar que un tercero no haya patentado ningún concepto incorporado en el código. [36] Las licencias permisivas más antiguas no discuten directamente las patentes y sólo ofrecen concesiones de patentes implícitas en sus ofertas para utilizar o vender material cubierto. [38] Las licencias copyleft más nuevas y la licencia Apache de 2004 ofrecen concesiones explícitas de patentes y protección limitada contra litigios sobre patentes. [39] Estas cláusulas de represalias en materia de patentes protegen a los desarrolladores al rescindir las concesiones para cualquier parte que inicie una demanda de patentes con respecto al software cubierto. [39]

Las marcas comerciales son la única forma de propiedad intelectual que no comparte el software gratuito y de código abierto. Las marcas comerciales en FOSS funcionan igual que cualquier otra marca comercial. [40] Una marca registrada es un diseño que identifica la fuente distinta de un producto. Debido a que distinguen productos, los mismos diseños pueden usarse en diferentes campos donde no hay riesgo de confundir fuentes similares. [41] Ceder el control de una marca daría lugar a la pérdida de esa marca. Por tanto, ninguna licencia de código abierto ofrece gratuitamente el uso de una marca. [42]

Las restricciones de marcas comerciales pueden superponerse a los derechos de autor y afectar material que de otro modo estaría disponible gratuitamente. [43] La Corte Suprema de Estados Unidos describió el uso de la ley de marcas para restringir el contenido de dominio público como "derecho de autor mutante". [44] En Dastar Corp. contra Twentieth Century Fox Film Corp. , el tribunal "advirtió contra el uso indebido o la extensión excesiva de la ley de marcas" sin proporcionar una decisión firme sobre esos derechos de autor mutantes. [45] [46] La superposición de marcas puede dejar a los proyectos de código abierto y de contenido gratuito vulnerables a una "adquisición hostil" si partes externas solicitan marcas en trabajos derivados. [47] En particular, Andrey Duskin solicitó marcas registradas en la Fundación SCP , un proyecto de escritura colaborativa, al crear trabajos derivados basados ​​en historias de SCP. [48]

Permisivo

Campus del MIT de noche
Las licencias permisivas generalmente se originan en instituciones académicas como el Instituto Tecnológico de Massachusetts .

Las licencias permisivas , también conocidas como licencias académicas, [49] permiten a los destinatarios utilizar, modificar y distribuir software sin obligación de proporcionar el código fuente. Las instituciones crearon estas licencias para distribuir sus creaciones al público. [49] Las licencias permisivas suelen ser breves, a menudo de menos de una página de texto. Imponen pocas condiciones. La mayoría incluye renuncias de garantía y obligaciones para dar crédito a los autores. Algunos incluyen disposiciones explícitas sobre patentes, marcas registradas y otras formas de propiedad intelectual. [50]

La Universidad de California en Berkeley creó la primera licencia de código abierto cuando comenzaron a distribuir su sistema operativo Berkeley Software Distribution (BSD). La licencia BSD y sus variaciones posteriores permiten la modificación y distribución del software cubierto. Las licencias BSD llevaron el concepto de libertad académica de ideas a la informática. Los primeros autores de software académico habían compartido código basado en promesas implícitas. Berkeley hizo explícitos estos conceptos con claras exenciones de responsabilidad y garantía junto con condiciones o cláusulas de redistribución. El original tenía cuatro cláusulas, pero las versiones posteriores redujeron aún más las restricciones. Como resultado, es común especificar si el software cubierto utiliza una versión de 2 o 3 cláusulas. [51] [52]

El Instituto Tecnológico de Massachusetts (MIT) creó una licencia académica basada en el original BSD. La licencia del MIT aclaró las condiciones haciéndolas más explícitas. [53] Por ejemplo, la licencia del MIT describe el derecho a sublicenciar. [54] Uno de los puntos fuertes del desarrollo de código abierto es el proceso continuo en el que los desarrolladores pueden aprovechar los trabajos derivados de otros y combinar sus proyectos en trabajos colectivos. Hacer explícitamente que el código cubierto sea sublicenciable proporciona una ventaja legal al realizar un seguimiento de la cadena de autoría. [53] BSD y MIT son licencias modelo que se pueden adaptar a cualquier proyecto. Están ampliamente adaptados y utilizados por muchos proyectos FOSS. [51]

La licencia Apache es más completa y explícita. La Apache Software Foundation lo escribió para su servidor Apache HTTP . La versión 2, publicada en 2004, ofrece ventajas legales sobre las licencias simples y proporciona subvenciones similares. [55] Mientras que las licencias BSD y MIT ofrecen una concesión de patente implícita, [56] la licencia Apache incluye una sección sobre patentes con una concesión explícita de los contribuyentes. [57] Además, es una de las pocas licencias permisivas con una cláusula de retorsión de patentes. [58] Las cláusulas de represalia o suspensión de patentes entran en vigor si un licenciatario inicia un litigio por infracción de patente sobre un código cubierto. En esa situación, se revocan las concesiones de patentes. Estas cláusulas protegen contra el trolling de patentes . [59]

Copyleft

Una pegatina dice: "Letra L en un círculo de Copyleft".
La pegatina Copyleft de un sobre que Don Hopkins envió por correo a Richard Stallman en 1984

Las licencias Copyleft requieren que el código fuente se distribuya con el software y que el código fuente esté disponible bajo una licencia similar. [34] [60] Al igual que las licencias permisivas, la mayoría de las licencias copyleft requieren atribución. [61] La mayoría, incluida la GPL, rechazan las garantías implícitas. [62]

Copyleft utiliza las restricciones de la ley de propiedad intelectual (contrariamente a su propósito habitual) para exigir que el código permanezca abierto. [63] El término y su eslogan relacionado, "Todos los derechos invertidos", habían sido utilizados previamente de manera lúdica por Principia Discordia y Tiny BASIC ; El uso moderno comienza con los esfuerzos de Richard Stallman por crear un sistema operativo libre. En 1984, el programador Don Hopkins envió por correo un manual a Stallman con una pegatina "Copyleft Ⓛ". Stallman, que estaba trabajando en el sistema operativo GNU, adoptó el término. [64] Una versión temprana de la licencia copyleft se utilizó para la versión de 1985 de GNU Emacs . [14] [65] El término se asoció con las licencias recíprocas posteriores de la FSF, en particular la Licencia Pública General GNU (GPL). [66]

Las licencias tradicionales de software propietario se escriben con el objetivo de aumentar las ganancias , pero Stallman escribió la GPL para aumentar el volumen de software libre disponible. Sus licencias recíprocas ofrecen los derechos de uso, modificación y distribución de la obra con la condición de que las personas deban publicar obras derivadas bajo una licencia que ofrezca esas mismas libertades. El software creado sobre una base copyleft debe venir con el código fuente, y el código fuente debe estar disponible bajo la misma licencia o una similar. Esto ofrece protección contra software propietario que consume código sin dar nada a cambio. [67] [68] Richard Stallman afirmó que "la idea central del copyleft es utilizar la ley de derechos de autor, pero darle la vuelta para que sirva al propósito opuesto a su propósito habitual: en lugar de un medio para privatizar el software, [los derechos de autor] se convierten en un medio para mantener el software libre." [69] Las licencias de software libre también son licencias de software de código abierto. [70] Los términos separados software libre y software de código abierto reflejan valores diferentes más que una diferencia legal. [71] Ambos movimientos y sus definiciones formales requieren que el trabajo cubierto esté disponible con el código fuente y con permiso para su modificación y redistribución. [16] Hay casos extremos ocasionales en los que solo una de las FSF u OSI acepta una licencia, pero las licencias de software libre populares son de código abierto, incluida la GPL . [72]

retrato de mitchell panadero
Mitchell Baker redactó la licencia pública de Mozilla mientras estaba en el equipo legal de Netscape. [73]

Los beneficios prácticos de las licencias copyleft han atraído a los desarrolladores comerciales. Las corporaciones han utilizado y redactado licencias recíprocas con un alcance más limitado que el de la GPL. [74] Por ejemplo, Netscape redactó sus propios términos copyleft después de rechazar licencias permisivas para el proyecto Mozilla. [75] La GPL sigue siendo la licencia más popular de este tipo, pero hay otros ejemplos significativos. La FSF ha elaborado la Licencia Pública General Reducida (LGPL) para bibliotecas . Mozilla utiliza la licencia pública de Mozilla (MPL) para sus lanzamientos, incluido Firefox . IBM redactó la Licencia Pública Común (CPL) y luego adoptó la Licencia Pública Eclipse (EPL). Una diferencia entre la GPL y otras licencias recíprocas es cómo definen las obras derivadas cubiertas por las disposiciones recíprocas. La GPL y la licencia Affero (AGPL) basada en ella utilizan un alcance amplio para describir las obras afectadas. La AGPL amplía la obligación recíproca de la GPL para cubrir el software disponible a través de una red. [74] [32] Se les llama copyleft fuerte en contraste con las licencias copyleft más débiles que suelen utilizar las corporaciones. El copyleft débil utiliza definiciones más estrictas y explícitas de obras derivadas. [76] [35] La MPL utiliza una definición basada en archivos, la CPL y la EPL utilizan una definición basada en módulos y la propia LGPL de la FSF se refiere a bibliotecas de software. [77]

Compatibilidad

Tabla de compatibilidad de licencias, detalles completos en la sección.
Licencias de software de código abierto y cómo interactúan

La compatibilidad de licencias determina cómo se puede distribuir juntos el código con diferentes licencias. El objetivo de las licencias de código abierto es que el trabajo esté disponible gratuitamente, pero esto se vuelve complicado cuando se trabaja con múltiples terminologías que imponen diferentes requisitos. [78] Hay muchas licencias de uso poco común y algunos proyectos redactan sus propios acuerdos personalizados . Como resultado, esto causa más confusión que otros aspectos legales. Al lanzar una colección de aplicaciones, cada licencia se puede considerar por separado. Sin embargo, al intentar combinar software, el código de otro proyecto solo puede tener licencia si el proyecto utiliza términos y condiciones compatibles. [79]

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. [80] 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. [78] Las licencias permisivas son ampliamente compatibles porque pueden cubrir partes separadas de un proyecto. Se han revisado varias licencias, incluidas GPL y Apache, para mejorar la compatibilidad. [81]

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 de la compatibilidad de las licencias. [82] Descargar un módulo de código abierto es sencillo, pero cumplir con los términos de la licencia puede ser más difícil. [83] Debido a la cantidad de dependencias de software, los ingenieros que trabajan en proyectos complejos a menudo dependen del software de gestión de licencias para lograr el cumplimiento de los términos de licencia de los componentes de código abierto. [84] Muchos archivos de software de código abierto no indican inequívocamente la licencia, lo que aumenta las dificultades de cumplimiento. [83]

Aplicación

Retrato de Harald Welte
Las primeras victorias legales del programador Harald Welte sentaron un precedente para los litigios sobre software de código abierto en Alemania. [85]

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. [86] En un par de demandas iniciales (Jacobsen contra Katzer en Estados Unidos y Welte contra Sitecom en Alemania), los demandados argumentaron que las licencias de código abierto no eran válidas. [87] [88] Sitecom y Katzer argumentaron por separado que las licencias eran inaplicables. Tanto los tribunales estadounidenses como los alemanes rechazaron estas afirmaciones. Dictaminaron que los demandados no podrían haber distribuido legalmente el software si las licencias no fueran ejecutables. [86] [85]

Los tribunales han determinado que la distribución de software indica la aceptación de los términos de la licencia. [89] Las versiones físicas de software pueden obtener el consentimiento del consumidor mediante avisos colocados en un envoltorio retráctil . La distribución online puede utilizar clickwrap , un equivalente digital donde el usuario debe hacer clic para aceptar. [90] El software de código abierto tiene un mecanismo de aceptación adicional. Sin el permiso del titular de los derechos de autor, la ley prohíbe la redistribución. [91] Por lo tanto, los tribunales tratan la redistribución como la aceptación de los términos de la licencia. Estas pueden incluir disposiciones de atribución o disposiciones de código fuente para licencias copyleft. [92] [93]

Los desarrolladores normalmente logran el cumplimiento sin demandas. Las presiones sociales, como la posibilidad de una reacción comunitaria, suelen ser suficientes. [94] 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. [95] En el sistema jurídico alemán se ha desarrollado un proceso estándar. Los desarrolladores de software libre presentan a las empresas una carta de cese y desistimiento. Estas cartas describen cómo volver a cumplir con una infracción. Los jueces alemanes pueden emitir una orden judicial de cese y desistimiento a las empresas que no responden. Los casos civiles continúan si estos primeros pasos fallan. Las leyes procesales alemanas son claras y favorables a los demandantes. [96]

Sigue habiendo incertidumbre sobre cómo los diferentes tribunales manejarán ciertos aspectos de la concesión de licencias. [97] En el caso del software en general, existen debates sobre qué se puede patentar y qué se puede proteger con derechos de autor. Con respecto a una interfaz de programación de aplicaciones (API), el Tribunal de Justicia de la Unión Europea señaló en el caso del Instituto SAS de 2012 que "las ideas y principios que subyacen a las interfaces [de programas informáticos] no están protegidos por derechos de autor". [98] En un caso similar de 2021 , la Corte Suprema de Estados Unidos permitió la recreación de un API en un producto transformador bajo uso legítimo . [99]

Un tema largamente debatido dentro de la comunidad FOSS es si las licencias de código abierto son "licencias simples" o contratos . [97] Una licencia simple es un conjunto de condiciones bajo las cuales se permiten acciones restringidas por las leyes de propiedad intelectual. [86] Según la interpretación de la simple licencia, defendida por la FSF, el titular de los derechos de autor lleva un caso ante los tribunales como infracción de derechos de autor . [86] Según la interpretación del contrato, una parte involucrada puede llevar un caso ante los tribunales como incumplimiento de contrato . [100] Los tribunales estadounidenses y franceses han juzgado casos conforme a ambas interpretaciones. [101] Organizaciones sin fines de lucro como FSF y Software Freedom Conservancy ofrecen conservar los derechos de los proyectos de los desarrolladores para hacer cumplir el cumplimiento. [96]

Software de dominio público

Naves espaciales y estrellas en un monitor redondo.
Los primeros programas informáticos, como el videojuego pionero Spacewar! son de dominio público. [102]

Cuando un derecho de autor expira, la obra pasa al dominio público y está disponible gratuitamente para cualquier persona. [103] Algunas obras creativas no están cubiertas por el derecho de autor y pasan directamente al dominio público. En la historia temprana de la informática, esto se aplicaba al software. [11] Los primeros programas informáticos a menudo se regalaban junto con el hardware. [104] Desarrollado inicialmente en el MIT, el videojuego pionero Spacewar! se utilizó para comercializar y probar la computadora PDP-1 . [105]

Según el abogado Lawrence Rosen , las leyes de derechos de autor no se redactaron con la expectativa de que los creadores colocaran su trabajo en el dominio público. Por lo tanto, las leyes de propiedad intelectual carecen de caminos claros para renunciar a los derechos de autor. Las licencias altamente permisivas descritas como "dominio público" pueden funcionar legalmente como contratos unilaterales que ofrecen algo pero no imponen condiciones. [106] [107]

Una licencia equivalente a un dominio público , como Creative Commons CC0, proporciona una exención de reclamos de derechos de autor en el dominio público junto con una licencia de software permisiva como alternativa. En jurisdicciones que no aceptan una renuncia de dominio público, la licencia permisiva entra en vigor. [108] Las exenciones de dominio público comparten limitaciones con las licencias académicas simples. Esto crea la posibilidad de que una parte externa intente controlar una obra de dominio público a través de la ley de patentes o marcas. [109] Las renuncias de dominio público manejan las garantías de manera diferente a cualquier tipo de licencia. Incluso las muy permisivas, como la licencia MIT, renuncian a garantías y responsabilidades. Cualquiera que utilice el software gratuito debe aceptar este descargo de responsabilidad como condición. Dado que el contenido de dominio público está disponible para todos, la exención de derechos de autor no puede imponer una exención de responsabilidad. [103]

Uso en software propietario

Las licencias de código abierto permiten que otras empresas comercialicen software cubierto. [110] El trabajo publicado bajo una licencia permisiva puede incorporarse a software propietario. [111] Las licencias permisivas permiten la adición de nuevos términos, incluidos los de propiedad. [112] [113] El software propietario tiene un código de fuente abierta muy integrado publicado bajo las licencias Apache, BSD y MIT. [114] Open core es un modelo de negocio en el que los desarrolladores lanzan una pieza central de software como código abierto y monetizan un producto que lo contiene como software propietario. [115] La GPL copyleft estricta está escrita para evitar la distribución dentro del software propietario. [116] [117] Las licencias copyleft débiles imponen requisitos específicos sobre trabajos derivados que pueden permitir que el código cubierto se distribuya dentro de software propietario en determinadas circunstancias. [78]

La computación en la nube se basa en software gratuito y de código abierto y evita la distribución que genera la mayoría de las licencias. El software en la nube está alojado en lugar de distribuido. [118] Un proveedor aloja el software en línea y sus usuarios finales no tienen que descargar, acceder ni siquiera conocer el código en uso. [119] La licencia pública general copyleft GNU Affero (AGPL) se activa cuando se aloja o distribuye el código cubierto. [120] Algunos desarrolladores han adoptado la AGPL y otros han cambiado a licencias propietarias con características de licencia de código abierto. [121] Por ejemplo, el desarrollador de núcleo abierto Elastic cambió de la licencia Apache a la licencia pública del lado del servidor "disponible en la fuente" . [122] El software disponible en código fuente viene con el código fuente como referencia. [123]

Desde 2010, el modelo de nube ha ganado importancia. [118] Los desarrolladores han criticado a las empresas de la nube que se benefician del alojamiento de software de código abierto sin contribuir con dinero o código, comparando la práctica con la minería a cielo abierto . [124] El líder de computación en la nube, Amazon Web Services, ha declarado que cumple con las licencias y actúa en el mejor interés de sus clientes. [124] [125]

Ver también

Notas

  1. ^ Byfield 2008.
  2. ^ Rosen 2005, pag. 22.
  3. ^ Rosen 2005, págs. 22-23.
  4. ^ ab Rosen 2005, pág. 15.
  5. ^ "Convenio de Berna". Wex . Facultad de Derecho de Cornell. Noviembre de 2021.
  6. ^ Fagundes y Perzanowski 2020, pag. 529.
  7. ^ Rosen 2005, pag. 17.
  8. ^ Rosen 2005, págs. 27-28.
  9. ^ Rosen 2005, págs. 28-29.
  10. ^ Rosen 2005, pag. 28.
  11. ^ ab Omán 2018, págs. 641–642.
  12. ^ Williams 2002, cap. 1.
  13. ^ Williams 2002, cap. 7.
  14. ^ ab Williams 2002, cap. 9.
  15. ^ Greenbaum 2016, § IA
  16. ^ abc Maracke 2019, § 2.2.
  17. ^ Carver 2005, págs. 448–450.
  18. ^ Perens 1999, ¶ 16.
  19. ^ Greenbaum 2016, págs. 1302-1303.
  20. ^ Greenbaum 2016, págs. 1304-1305.
  21. ^ Greenbaum 2016, pag. 1305.
  22. ^ Fontana 2010, pag. 2.
  23. ^ Coleman 2004, "Agnosticismo político".
  24. ^ Raymond 1999, "Memes y creación de mitos".
  25. ^ Más manso 2020, 2:33–3:06.
  26. ^ Raymond 2001, "La Catedral y el Bazar".
  27. ^ Brock 2022, § 16.3.4.
  28. ^ Raymond 2001.
  29. ^ Raymond 2001, "El contexto social del software de código abierto".
  30. ^ Raymond 2001, pag. 19.
  31. ^ Onetti y Verma 2009, pag. 69.
  32. ^ ab Hammerly, Paquin y Walton 1999.
  33. ^ Smith 2022, § 3.2.
  34. ^ ab Sen, Subramaniam y Nelson 2008, págs.
  35. ^ ab Meeker 2020, 16:13.
  36. ^ ab Rosen 2005, págs. 22-24.
  37. ^ Bain y Smith 2022, § 10.4.3.
  38. ^ Bain y Smith 2022, § 10.4.2.
  39. ^ ab Bain & Smith 2022, § 10.4.4.
  40. ^ Chestek 2022, pag. 30.
  41. ^ Chestek 2022, págs. 184-185.
  42. ^ Rosen 2005, pag. 38.
  43. ^ Alegría 2022, pag. 986.
  44. ^ Alegría 2022, pag. 989.
  45. ^ Dastar Corp. contra Twentieth Century Fox Film Corp. , 539 US 23, 34 (2003).
  46. ^ Alegría 2022, págs. 987–988.
  47. ^ Alegría 2022, págs. 1004-1006.
  48. ^ Alegría 2022, págs.979, 1002.
  49. ^ ab Rosen 2005, pág. 69.
  50. ^ Rosen 2005, págs. 101-102.
  51. ^ ab Smith 2022, § 3.2.1.1.
  52. ^ OSI 2023.
  53. ^ ab Rosen 2005, págs. 73–90.
  54. ^ OSI 2023, "La licencia MIT".
  55. ^ Smith 2022, § 3.2.1.2.
  56. ^ Bain y Smith 2022, § 10.4.2.
  57. ^ OSI 2023, "Licencia Apache, versión 2.0".
  58. ^ Bain y Smith 2022, cap. 10.
  59. ^ Bain y Smith 2022, § 10.4.4.
  60. ^ St. Laurent 2004, págs. 38-39.
  61. ^ Ballhausen 2019, pag. 86.
  62. ^ Rosen 2005, pag. 135.
  63. ^ Rosen 2005, págs. 103-106.
  64. ^ Keats 2010, pag. 64.
  65. ^ "Texto completo del aviso de permiso de copia de GNU Emacs". 1985.
  66. ^ Keats 2010, págs. 63–67.
  67. ^ Rosen 2005, págs. 103-109.
  68. ^ Más manso 2020, 6:00 a 7:22.
  69. ^ Alegría 2022, págs. 990–992.
  70. ^ Onetti y Verma 2009, pag. 71.
  71. ^ St. Laurent 2004, págs. 81–83, 114.
  72. ^ Ballhausen 2019, pag. 82.
  73. ^ St. Laurent 2004, págs.68, 75.
  74. ^ ab Tsai 2008, págs. 564–570.
  75. ^ Hammerly, Paquin y Walton 1999, ¶ 23.
  76. ^ Sen, Subramaniam y Nelson 2008, págs. 212-213.
  77. ^ Rosen 2005, consulte los capítulos correspondientes.
  78. ^ abc Smith 2022, § 3.3.
  79. ^ Rosen 2005, págs. 243-247.
  80. ^ St. Laurent 2004, págs. 159-163.
  81. ^ Véase Smith 2022, p. 102 para: Licencia Apache versión 2.0 en 2004, GPL versión 3 en 2007, LGPL versión 3 en 2007 y AGPL versión 3 en 2007. Consulte Smith 2022, págs. 95-101 para: MPL versión 2.0 en 2012 y EPL versión 2 en 2017.
  82. ^ Bernelin 2020, págs.100, 102.
  83. ^ ab Ombredanne 2020, pag. 105.
  84. ^ Ombredanne 2020, pag. 106.
  85. ^ ab Ballhausen 2022, § 5.3.
  86. ^ abcd Smith 2022, § 3.4.1.
  87. ^ Jacobsen contra Katzer , 535 F.3d 1373 ( Fed. Cir. 2008).
  88. ^ Welte contra Sitecom (Tribunal de Distrito de Múnich 2004), núm. 21 O 6123/04.
  89. ^ Smith 2022, pag. 106.
  90. ^ Rosen 2005, pag. 137.
  91. ^ Rosen 2005, pag. 138.
  92. ^ Rosen 2005, cap. 6.
  93. ^ Más manso 2020, 17:04.
  94. ^ St. Laurent 2004, págs. 158-159.
  95. ^ Ballhausen 2022, pag. 127.
  96. ^ ab Ballhausen 2022, § 5.4.
  97. ^ ab Walden 2022, § 1.1.
  98. ^ Smith 2022, § 3.1.3.
  99. ^ Google LLC contra Oracle America, Inc. , 593 EE. UU., 1203 (2021).
  100. ^ Smith 2022, § 3.4.2.
  101. ^ Smith 2022, § 3.4.
  102. ^ Ross 2021, "Guerra espacial: fin del desarrollo".
  103. ^ ab Rosen 2005, pág. 36.
  104. ^ Walden 2022, pag. 3.
  105. ^ Smith 2019, págs. 55–56.
  106. ^ Rosen 2005, págs. 74–77.
  107. ^ San Lorenzo 2004, pág. 98.
  108. ^ Fagundes y Perzanowski 2020, pag. 524.
  109. ^ Alegría 2022, págs. 1008-1010.
  110. ^ Brock 2022, § 16.3.3.
  111. ^ San Lorenzo 2004, pág. 14.
  112. ^ San Lorenzo 2004, pág. 22.
  113. ^ Onetti y Verma 2009, pag. 81.
  114. ^ San Lorenzo 2004, pág. 30.
  115. ^ Brock 2022, § 16.4.2.3.
  116. ^ Tsai 2008, pag. 550.
  117. ^ San Lorenzo 2004, pág. 39.
  118. ^ ab Brock 2022, § 16.5.2.
  119. ^ Brock 2022, § 16.4.2.8.
  120. ^ Brock 2022, § 16.4.2.2.
  121. ^ Brock 2022, § 16.5.3.
  122. ^ Brock 2022, § 16.5.3.8.
  123. ^ Kunert 2022.
  124. ^ ab Wakabayashi 2019.
  125. ^ Brock 2022, § 16.5.3.2.

Referencias