Licencia de código abierto

Software license allowing source code to be used, modified, and shared

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 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 libre y de código abierto (FOSS). Las leyes de propiedad intelectual (PI) restringen la modificación y el intercambio de obras creativas. Las licencias libres y de código abierto utilizan estas estructuras legales existentes con un propósito inverso. Otorgan al receptor 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 de software libre en respuesta al auge del software propietario . El término "código abierto" fue utilizado por la Iniciativa de Código Abierto (OSI), fundada por los desarrolladores de software libre Bruce Perens y Eric S. Raymond . "Código abierto" enfatiza las fortalezas del modelo de desarrollo abierto en lugar de 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 las copyleft . Ambas otorgan permiso para modificar y distribuir software. Por lo general, requieren atribución y exención de responsabilidad . Las licencias permisivas provienen del ámbito 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 y por incumplimiento de contrato.

Fondo

El jurista Eben Moglen habla sobre la historia del copyright

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

La mayoría de los países, incluido Estados Unidos (EE. UU.), han creado leyes de derechos de autor en línea con el Convenio de Berna . [5] Estas leyes asignan un derecho de autor siempre que una obra se publica en cualquier formato fijo. [6] Según la ley de derechos de autor de EE. UU., el lanzamiento 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, ejecutar públicamente o exhibir 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 estuviera en el dominio público, una obra derivada solo se puede distribuir con el permiso de cada titular de los derechos de autor. [10]

En 1980, el gobierno de los EE. UU. modificó la ley para tratar el software como una obra literaria. El software publicado 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 propagación del software propietario y los modelos cerrados de desarrollo. Para contrarrestar estas tendencias, Stallman fundó el movimiento del 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 de su objetivo de restricción. En lugar de imponer restricciones, el software libre proporcionó explícitamente libertades al receptor. [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, el término "código abierto" fue acuñado 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 Iniciativa de Código Abierto (OSI). [17] En Debian , Perens había propuesto las Pautas de Software Libre de Debian (DFSG). [18] Las 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ó las DSFG y las utilizó como base para su Definición de Código Abierto. [20] La Free Software Foundation mantiene un conjunto rival de criterios, 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 el software libre y de código abierto. [22] Existe una diversidad significativa entre las licencias individuales, pero poca diferencia entre las definiciones rivales. [16] Las tres definiciones exigen que las personas que reciben el software protegido puedan utilizar, modificar y redistribuir el trabajo protegido. [23]

Eric S. Raymond fue un defensor del término " código abierto " en lugar de "software libre". Consideraba que el código abierto era más atractivo para las empresas y reflejaba mejor las ventajas tangibles del desarrollo de 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] Argumentó que, además 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 la retroalimentación , las pruebas y los informes de errores . [28] Contrastó el modelo propietario, donde pequeños grupos de trabajadores secretos llevaban a cabo este trabajo, con el desarrollo de Linux, donde el grupo de evaluadores incluía potencialmente a todo el mundo. [29] Resumió esta fortaleza como "Dadas suficientes miradas, todos los errores son superficiales". [30] La OSI logró acercar el desarrollo de código abierto a los desarrolladores corporativos, entre ellos Sun Microsystems, IBM , Netscape, Mozilla , Apache , Apple Inc., Microsoft y Nokia. Estas empresas publicaron código bajo licencias existentes y redactaron sus propios códigos para que los aprobara la OSI. [31] [32]

Tipos

Las licencias de código abierto se clasifican como copyleft o permisivas . [33] Las licencias copyleft requieren que las obras derivadas incluyan código fuente bajo una licencia similar. Las licencias permisivas no lo requieren y, por lo tanto, el código puede usarse dentro de software propietario. Las licencias copyleft se pueden dividir en fuertes y débiles 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 PI. [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 en poder de los desarrolladores. [37] Las patentes de software cubren ideas y, en lugar de una implementación específica, cubren cualquier implementación de una reivindicación . Las reivindicaciones de patentes dan al titular el derecho a excluir a otros de fabricar, usar, 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 aún 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 pueden ofrecer permiso solo 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 las patentes directamente y solo ofrecen concesiones de patentes implícitas en sus ofertas para usar o vender material cubierto. [38] Las nuevas licencias copyleft y la Licencia Apache de 2004 ofrecen concesiones explícitas de patentes y protección limitada frente a litigios de patentes. [39] Estas cláusulas de represalia por patentes protegen a los desarrolladores al poner fin a las concesiones para cualquier parte que inicie una demanda de patentes en relación con el software cubierto. [39]

Las marcas comerciales son la única forma de propiedad intelectual que no comparten los programas de software libre y de código abierto. Las marcas comerciales en el software libre y de código abierto funcionan igual que cualquier otra marca comercial. [40] Una marca comercial es un diseño que identifica la fuente distintiva 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] Renunciar al control de una marca comercial resultaría en la pérdida de esa marca comercial. Por lo tanto, ninguna licencia de código abierto ofrece libremente el uso de una marca comercial. [42]

Las restricciones de marcas registradas pueden superponerse a los derechos de autor y afectar a material que de otro modo estaría disponible libremente. [43] La Corte Suprema de los Estados Unidos describió el uso de la ley de marcas registradas para restringir el contenido de dominio público como "derecho de autor mutante". [44] En Dastar Corp. v. Twentieth Century Fox Film Corp. , el tribunal "advirtió contra el uso indebido o la extensión excesiva de la ley de marcas registradas" sin proporcionar una decisión firme sobre esos derechos de autor mutantes. [45] [46] La superposición de marcas registradas puede dejar a los proyectos de contenido libre y de código abierto vulnerables a una "adquisición hostil" si terceros solicitan marcas registradas 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

El 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 de dar crédito a los autores. Unas pocas incluyen disposiciones explícitas para patentes, marcas comerciales y otras formas de propiedad intelectual. [50]

La Universidad de California, Berkeley, creó la primera licencia de código abierto cuando comenzó 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 amparado. Las licencias BSD introdujeron el concepto de libertad académica de ideas en la informática. Los primeros autores de software académico habían compartido código basándose en promesas implícitas. Berkeley hizo explícitos estos conceptos con claras exenciones de responsabilidad y garantía junto con condiciones o cláusulas para la redistribución. La original tenía cuatro cláusulas, pero las versiones posteriores han reducido aún más las restricciones. Como resultado, es común especificar si el software amparado 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 la licencia BSD original. La licencia MIT aclaró las condiciones haciéndolas más explícitas. [53] Por ejemplo, la licencia MIT describe el derecho a sublicenciar. [54] Una de las fortalezas del desarrollo de código abierto es el proceso continuo en el que los desarrolladores pueden construir sobre los trabajos derivados de los demás y combinar sus proyectos en trabajos colectivos. Hacer explícitamente que el código cubierto sea sublicenciable proporciona una ventaja legal al rastrear la cadena de autoría. [53] La licencia BSD y la MIT son licencias modelo que se pueden adaptar a cualquier proyecto. Son ampliamente adaptadas y utilizadas por muchos proyectos FOSS. [51]

La Licencia Apache es más completa y explícita. La Apache Software Foundation la escribió para su Apache HTTP Server . La versión 2, publicada en 2004, ofrece ventajas legales sobre las licencias simples y proporciona concesiones 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 represalia de patentes. [58] Las cláusulas de represalia de patentes, o suspensión de patentes, entran en vigor si un licenciatario inicia un litigio por infracción de patentes sobre el código cubierto. En esa situación, las concesiones de patentes se revocan. Estas cláusulas protegen contra el trolling de patentes . [59]

Copia izquierda

Una pegatina dice: "Letra L en un círculo con 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, renuncian a garantías implícitas. [62]

Copyleft utiliza las restricciones de la ley de propiedad intelectual (contrariamente a su propósito habitual) para obligar a que el código permanezca abierto. [63] El término y su eslogan relacionado, "Todos los derechos revertidos", 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 que decía "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 el lanzamiento de GNU Emacs en 1985. [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 de software privativo tradicionales se escriben con el objetivo de aumentar las ganancias , pero Stallman escribió la GPL para aumentar el cuerpo de software libre disponible. Sus licencias recíprocas ofrecen los derechos de uso, modificación y distribución del trabajo con la condición de que las personas deben publicar trabajos derivados bajo una licencia que ofrezca estas 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 el software privativo 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 de su propósito habitual: en lugar de un medio para privatizar el software, [el copyright] se convierte 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 en lugar de 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 la FSF o la OSI aceptan una licencia, pero las licencias de software libre populares son de código abierto, incluida la GPL . [72]

Retrato de Mitchell Baker
Mitchell Baker redactó la Licencia Pública de Mozilla mientras formaba parte del equipo legal de Netscape. [73]

Los beneficios prácticos de las licencias copyleft han atraído a los desarrolladores comerciales. Las corporaciones han usado y escrito licencias recíprocas con un alcance más estrecho que 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 creado la Licencia Pública General Menor (LGPL) para bibliotecas . Mozilla usa 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 los trabajos derivados cubiertos por las disposiciones recíprocas. La GPL y la Licencia Affero (AGPL) basada en ella, usan un alcance amplio para describir los trabajos afectados. La AGPL extiende la obligación recíproca en la GPL para cubrir el software disponible a través de una red. [74] [32] Se denominan copyleft fuertes 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

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

La compatibilidad de licencias determina cómo se puede distribuir en conjunto el código con diferentes licencias. El objetivo de las licencias de código abierto es hacer que el trabajo esté disponible de forma gratuita, pero esto se complica cuando se trabaja con múltiples terminologías que imponen diferentes requisitos. [78] Hay muchas licencias que se usan de forma poco común y algunos proyectos escriben sus propios acuerdos a medida . 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 se puede licenciar 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 hay 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. Las licencias permisivas se pueden utilizar dentro de trabajos 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. [78] Las licencias permisivas son ampliamente compatibles porque pueden cubrir partes separadas de un proyecto. Se han revisado varias licencias, incluidas la GPL y la Licencia 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 de forma inequívoca 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 de 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 tempranas ( Jacobsen contra Katzer en los 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 no eran ejecutables. Tanto los tribunales estadounidenses como los alemanes rechazaron estas reclamaciones y dictaminaron que los demandados no podrían haber distribuido legalmente el software si las licencias no eran 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 con avisos colocados en el envoltorio retráctil . La distribución en línea puede utilizar el envoltorio de clic , un equivalente digital en el que 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. Estos pueden incluir disposiciones de atribución o disposiciones de código fuente para licencias copyleft. [92] [93]

Los desarrolladores suelen lograr el cumplimiento sin demandas judiciales. Las presiones sociales, como la posible reacción de la comunidad, suelen ser suficientes. [94] Las cartas de cese y desistimiento son un método común para que las empresas vuelvan a cumplir, especialmente en Alemania. [95] Se ha desarrollado un proceso estándar en el sistema legal alemán. Los desarrolladores de FOSS presentan a las empresas una carta de cese y desistimiento. Estas cartas describen cómo volver a cumplir después de una infracción. Los jueces alemanes pueden emitir una orden judicial de cese y desistimiento a las empresas que no responden. Los casos civiles proceden si estos primeros pasos fallan. Las leyes procesales alemanas son claras y favorables a los demandantes. [96]

Sigue habiendo incertidumbre sobre cómo los distintos tribunales manejarán determinados 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. En lo que respecta a una interfaz de programación de aplicaciones (API), el Tribunal de Justicia de la Unión Europea señaló en el caso SAS Institute de 2012 que "las ideas y los principios que subyacen a las interfaces [de los programas informáticos] no están protegidos por derechos de autor". [98] En un caso similar de 2021 , la Corte Suprema de los Estados Unidos permitió la recreación de una API en un producto transformador en virtud del 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 que de otra manera estarían restringidas por las leyes de propiedad intelectual. [86] Bajo la interpretación de la licencia simple, defendida por la FSF, el titular de los derechos de autor lleva un caso a los tribunales como infracción de los derechos de autor . [86] Bajo la interpretación del contrato, una parte involucrada puede llevar un caso a los tribunales como incumplimiento del contrato . [100] Los tribunales estadounidenses y franceses han juzgado casos bajo ambas interpretaciones. [101] Las organizaciones sin fines de lucro como la FSF y Software Freedom Conservancy ofrecen mantener 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 expira un derecho de autor, la obra pasa a ser de dominio público y está disponible de forma gratuita para cualquier persona. [103] Algunas obras creativas no están cubiertas por el derecho de autor y pasan directamente al dominio público. En los inicios de la historia de la informática, esto se aplicaba al software. [11] Los primeros programas informáticos se solían regalar junto con el hardware. [104] El videojuego pionero Spacewar!, desarrollado inicialmente en el MIT, 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 obra en el dominio público. Por lo tanto, las leyes de propiedad intelectual carecen de vías claras para renunciar a los derechos de autor. Las licencias altamente permisivas descritas como "de dominio público" pueden funcionar legalmente como contratos unilaterales que ofrecen algo pero no imponen condiciones. [106] [107]

Una licencia equivalente a la de dominio público , como la Creative Commons CC0, proporciona una exención de derechos de autor en el dominio público junto con una licencia de software permisiva como alternativa. En las jurisdicciones que no aceptan una exención 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 pueda intentar controlar una obra de dominio público a través de la ley de patentes o marcas registradas. [109] Las exenciones de dominio público manejan las garantías de manera diferente a cualquier otro tipo de licencia. Incluso las muy permisivas, como la licencia MIT, renuncian a la garantía y la responsabilidad. Cualquiera que use el software libre debe aceptar esta exención de responsabilidad como condición. Debido a 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 a otras empresas comercializar software cubierto. [110] El trabajo publicado bajo una licencia permisiva puede incorporarse en software propietario. [111] Las licencias permisivas permiten la adición de nuevos términos, incluidos los propietarios. [112] [113] El software propietario tiene un código de fuente abierta muy integrado publicado bajo las licencias Apache, BSD y MIT. [114] El núcleo abierto 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 con copyleft fuerte está escrita para evitar la distribución dentro de software propietario. [116] [117] Las licencias con copyleft débil imponen requisitos específicos a los 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 libre y de código abierto y evita la distribución que activa la mayoría de las licencias. El software en la nube se aloja en lugar de distribuirse. [118] Un proveedor aloja el software en línea y sus usuarios finales no tienen que descargar, acceder o incluso saber acerca del código en uso. [119] La Licencia Pública General Affero GNU copyleft (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 licencias 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 "con código fuente disponible" . [122] El software con código fuente disponible 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 compañías de nube que se benefician de alojar software de código abierto sin contribuir con dinero o código, comparando la práctica con la minería de datos . [124] El líder de computación en nube Amazon Web Services ha declarado que cumple con las licencias y actúa en el mejor interés de sus clientes. [124] [125]

Véase también

Notas

  1. ^ Biobio 2008.
  2. ^ Rosen 2005, pág. 22.
  3. ^ Rosen 2005, págs. 22-23.
  4. ^ desde Rosen 2005, pág. 15.
  5. ^ "Convención de Berna". Wex . Facultad de Derecho de Cornell. Noviembre de 2021.
  6. ^ Fagundes y Perzanowski 2020, pag. 529.
  7. ^ Rosen 2005, pág. 17.
  8. ^ Rosen 2005, págs. 27-28.
  9. ^ Rosen 2005, págs. 28-29.
  10. ^ Rosen 2005, pág. 28.
  11. ^ ab Omán 2018, págs. 641–642.
  12. ^ Williams 2002, cap. 1.
  13. ^ Williams 2002, cap. 7.
  14. ^ desde 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, pág. 1305.
  22. ^ Fontana 2010, pág. 2.
  23. ^ Coleman 2004, "Agnosticismo político".
  24. ^ Raymond 1999, "Memes y creación de mitos".
  25. ^ Meeker 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, pág. 19.
  31. ^ Onetti y Verma 2009, pág. 69.
  32. ^ desde Hammerly, Paquin y Walton 1999.
  33. ^ Smith 2022, § 3.2.
  34. ^ ab Sen, Subramaniam y Nelson 2008, págs. 211–212.
  35. ^Por Meeker 2020, 16:13.
  36. ^ desde Rosen 2005, págs. 22-24.
  37. ^ Bain y Smith 2022, § 10.4.3.
  38. ^ Bain y Smith 2022, § 10.4.2.
  39. ^ Véase Bain & Smith 2022, § 10.4.4.
  40. ^ Chestek 2022, pág. 30.
  41. ^ Chestek 2022, págs. 184-185.
  42. ^ Rosen 2005, pág. 38.
  43. ^ Alegría 2022, pág. 986.
  44. ^ Alegría 2022, pág. 989.
  45. ^ Dastar Corp. contra Twentieth Century Fox Film Corp. , 539 US 23, 34 (2003).
  46. ^ Joy 2022, págs. 987–988.
  47. ^ Joy 2022, págs. 1004–1006.
  48. ^ Alegría 2022, págs. 979, 1002.
  49. ^ desde Rosen 2005, pág. 69.
  50. ^ Rosen 2005, págs. 101-102.
  51. ^ Véase Smith 2022, § 3.2.1.1.
  52. ^ OSI 2023.
  53. ^ desde 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 & Smith 2022, cap. 10.
  59. ^ Bain y Smith 2022, § 10.4.4.
  60. ^ St. Laurent 2004, págs. 38-39.
  61. ^ Ballhausen 2019, pág. 86.
  62. ^ Rosen 2005, pág. 135.
  63. ^ Rosen 2005, págs. 103-106.
  64. ^ Keats 2010, pág. 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. ^ Meeker 2020, 6:00–7:22.
  69. ^ Joy 2022, págs. 990–992.
  70. ^ Onetti y Verma 2009, pág. 71.
  71. ^ St. Laurent 2004, págs. 81–83, 114.
  72. ^ Ballhausen 2019, pág. 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: la licencia Apache versión 2.0 en 2004, la GPL versión 3 en 2007, la LGPL versión 3 en 2007 y la AGPL versión 3 en 2007. Véase Smith 2022, pp. 95-101 para: la MPL versión 2.0 en 2012 y la EPL versión 2 en 2017.
  82. ^ Bernelin 2020, págs. 100, 102.
  83. ^ desde Ombredanne 2020, pág. 105.
  84. ^ Ombredanne 2020, pág. 106.
  85. ^ desde Ballhausen 2022, § 5.3.
  86. ^ abcd Smith 2022, § 3.4.1.
  87. ^ Jacobsen contra Katzer , 535 F.3d 1373 ( Fed. Cir. 2008).
  88. ^ Welte c. Sitecom (Tribunal de Distrito de Múnich 2004), n.º 21 O 6123/04.
  89. ^ Smith 2022, pág. 106.
  90. ^ Rosen 2005, pág. 137.
  91. ^ Rosen 2005, pág. 138.
  92. ^ Rosen 2005, cap. 6.
  93. ^ Meeker 2020, 17:04.
  94. ^ St. Laurent 2004, págs. 158-159.
  95. ^ Ballhausen 2022, pág. 127.
  96. ^ desde Ballhausen 2022, § 5.4.
  97. ^ desde Walden 2022, § 1.1.
  98. ^ Smith 2022, § 3.1.3.
  99. ^ Google LLC contra Oracle America, Inc. , 593 US, 1203 (2021).
  100. ^ Smith 2022, § 3.4.2.
  101. ^ Smith 2022, § 3.4.
  102. ^ Ross 2021, "Spacewar: Fin del desarrollo".
  103. ^ desde Rosen 2005, pág. 36.
  104. ^ Walden 2022, pág. 3.
  105. ^ Smith 2019, págs. 55–56.
  106. ^ Rosen 2005, págs. 74–77.
  107. ^ San Laurent 2004, pág. 98.
  108. ^ Fagundes y Perzanowski 2020, pag. 524.
  109. ^ Joy 2022, págs. 1008–1010.
  110. ^ Brock 2022, § 16.3.3.
  111. ^ St. Laurent 2004, pág. 14.
  112. ^ St. Laurent 2004, pág. 22.
  113. ^ Onetti y Verma 2009, pág. 81.
  114. ^ St. Laurent 2004, pág. 30.
  115. ^ Brock 2022, § 16.4.2.3.
  116. ^ Tsai 2008, pág. 550.
  117. ^ St. Laurent 2004, pág. 39.
  118. ^ Véase 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. ^ desde Wakabayashi 2019.
  125. ^ Brock 2022, § 16.5.3.2.

Referencias

  • Ballhausen, Miriam (junio de 2019). "Explicación de las licencias de software libre y de código abierto". Computer . 52 (6): 82–86. doi : 10.1109/MC.2019.2907766 .
  • Bernelin, Margo (2020). "La compatibilidad de las licencias abiertas/libres: un embrollo legal". Revista Internacional de Derecho y Tecnología de la Información . 28 (2): 93–111. doi :10.1093/ijlit/eaaa010.
  • Brock, Amanda, ed. (2022). Derecho, política y práctica de código abierto (segunda edición). Oxford University Press . doi : 10.1093/oso/9780198862345.001.0001 . ISBN . 978-0-19-886234-5Archivado del original el 26 de marzo de 2023 . Consultado el 29 de enero de 2023 .
    • Bain, Malcom; Smith, P McCoy. "Patentes y respuesta defensiva". En Brock (2022).
    • Ballhausen, Miriam. "Cumplimiento de los derechos de autor". En Brock (2022).
    • Chestek, Pamela. “Marcas comerciales”. En Brock (2022).
    • Smith, P McCoy. "Copyright, contrato y licencias en código abierto". En Brock (2022).
    • Walden, Ian. "El código abierto como filosofía, metodología y comercio: usar el derecho con actitud". En Brock (2022).
  • Byfield, Bruce (4 de marzo de 2008). «Software «libre» y «de código abierto»: cómo sortear los dogmas». Datamation . Consultado el 6 de junio de 2024 .
  • Carver, Brian W. (2005). "Compartir y compartir de la misma manera: comprensión y aplicación de las licencias de software libre y de código abierto". Berkeley Technology Law Journal . 20 (1): 443–481. ISSN  1086-3818.
  • Coleman, Gabriella (2004). "El agnosticismo político del software libre y de código abierto y la política involuntaria del contraste". Anthropological Quarterly . 77 (3): 507–519. ISSN  0003-5491.
  • DiBona, Chris; Stone, Mark; Ockman, Sam, eds. (1999). "La definición de código abierto". Fuentes abiertas: voces de la revolución del código abierto. Sebastopol, California: O'Reilly Media . Archivado desde el original el 27 de enero de 2023. Consultado el 21 de enero de 2023 .
    • Hammerly, Jim; Paquin, Tom; Walton, Susan. "Liberando el código fuente: la historia de Mozilla". En DiBona, Stone y Ockman (1999).
    • Perens, Bruce. "La definición de código abierto". En DiBona, Stone y Ockman (1999).
    • Raymond, Eric S. "La venganza de los hackers". En DiBona, Stone & Ockman (1999).
  • Fagundes, Dave; Perzanowski, Aaron (noviembre de 2020). “Abandono del derecho de autor”. William & Mary Law Review . 62 (2): 487–569.
  • Fontana, Richard E. (abril de 2010). "Cumplimiento y aplicación de licencias de código abierto". The Computer and Internet Lawyer . 27 (4). Aspen.
  • Greenbaum, Eli (abril de 2016). "El principio de no discriminación en las licencias de código abierto" (PDF) . Cardoza Law Review . 37 (4).
  • Joy, Reagan (2022). “La tragedia de Creative Commons: un análisis de cómo los derechos de propiedad intelectual superpuestos socavan el uso de licencias permisivas”. Case Western Reserve Law Review . 72 (4): 977–1013.
  • Keats, Jonathon (2010). "Copyleft". Palabras virtuales: lenguaje al borde de la ciencia y la tecnología . Oxford University Press . doi :10.1093/oso/9780195398540.003.0017. ISBN 978-0-19-539854-0Archivado desde el original el 26 de marzo de 2023 . Consultado el 28 de enero de 2023 .
  • Kunert, Paul (8 de septiembre de 2022). «Open source biz shifts Akka to Business Source License». Archivado desde el original el 31 de octubre de 2022. Consultado el 25 de enero de 2023 .
  • Maracke, Catharina (julio de 2019). "Software libre y de código abierto y licencias de patentes basadas en FRAND: cómo mediar entre la patente esencial estándar y el software libre y de código abierto". The Journal of World Intellectual Property . 22 (3–4): 78–102. doi : 10.1111/jwip.12114 .
  • Meeker, Heather (enero de 2020). Conceptos básicos de licencias de software de código abierto para usuarios corporativos. Licencias de software de código abierto . Consultado el 7 de diciembre de 2023 .
  • Oman, Ralph (primavera de 2018). "Software informático como materia susceptible de protección por derechos de autor: Oracle vs. Google, intención legislativa y alcance de los derechos en obras digitales". Harvard Journal of Law & Technology . 31 (2): 639–652.
  • Ombredanne, Philippe (2020). "Cumplimiento de licencias de software libre y de código abierto: herramientas para el análisis de la composición de software". Computer . 53 (10): 105–109. doi :10.1109/MC.2020.3011082.
  • Onetti, Alberto; Verma, Sameer (1 de mayo de 2009). "Licencias de código abierto y modelos de negocio". Revista ICFAI de Gestión del Conocimiento . 7 (1): 68–94.
  • OSI (febrero de 2023). «Licencias aprobadas por OSI». opensource.org . Iniciativa de código abierto . Consultado el 23 de diciembre de 2023 .
  • Raymond, Eric S. (2001). La catedral y el bazar: reflexiones sobre Linux y el código abierto de un revolucionario accidental (edición revisada). Sebastopol, California: O'Reilly Media . ISBN 978-0-596-00108-7. Archivado desde el original el 24 de abril de 2003 . Consultado el 28 de enero de 2023 .
  • Rosen, Lawrence (2005). Licencias de código abierto: libertad de software y derecho de propiedad intelectual (edición de bolsillo). Upper Saddle River, NJ: Prentice Hall . ISBN 978-0-13-148787-1Archivado desde el original el 19 de diciembre de 2022 . Consultado el 21 de enero de 2023 .
  • Ross, Heather (4 de enero de 2021). «Spacewar: guía, historia, origen y más». History-Computer . Consultado el 23 de diciembre de 2023 .
  • Sen, Ravi; Subramaniam, Chandrasekar; Nelson, Matthew L. (invierno de 2008). "Determinantes de la elección de la licencia de software de código abierto". Journal of Management Information Systems . 25 (3): 207–239. doi :10.2753/MIS0742-1222250306.
  • Smith, Alexander (2019). They Create Worlds: The Story of the People and Companies That Shaped the Video Game Industry (Ellos crean mundos: la historia de las personas y las empresas que dieron forma a la industria de los videojuegos ). Vol. 1: 1971 – 1982. Boca Raton, Florida: CRC Press . ISBN 978-1-138-38990-8.
  • St. Laurent, Andrew M. (2004). Entender el código abierto y las licencias de software libre. Sebastopol, California: O'Reilly Media . ISBN 978-0596005818.
  • Tsai, John (2008). "Para bien o para mal: presentación de la Licencia Pública General GNU versión 3". Berkeley Technology Law Journal . 23 (1): 547–581.
  • Wakabayashi, Daisuke (15 de diciembre de 2019). «Prime Leverage: How Amazon Wields Power in the Technology World» (Apalancamiento de primera: cómo Amazon ejerce el poder en el mundo de la tecnología). The New York Times . Archivado desde el original el 30 de octubre de 2023. Consultado el 24 de mayo de 2024 .}
  • Williams, Sam (2002). Libre como en libertad: la cruzada de Richard Stallman por el software libre (Primera edición). Sebastopol, California: Farnham: O'Reilly Media . ISBN 978-0-596-00287-9Archivado desde el original el 7 de febrero de 2023 . Consultado el 6 de febrero de 2023 .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Open-source_license&oldid=1238802896"