Articulo de referencia

Licencia de código abierto

Entre las licencias de código abierto más populares se incluyen la Licencia Apache , la Licencia MIT , la Licencia Pública General de GNU (GPL), las Licencias BSD , la Licencia ...

Este es un buen artículo. Haz clic aquí para obtener más información.

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 corresponde a licencias con una cuota de mercado inferior al 1% cada una.
Entre las licencias de código abierto más populares se incluyen la Licencia Apache , la Licencia MIT , la Licencia Pública General de GNU (GPL), las Licencias BSD , la Licencia Pública General Reducida de GNU (LGPL) y la Licencia Pública de Mozilla (MPL).

Las licencias de código abierto son licencias de software que permiten usar, modificar y compartir el 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 de software libre y de código abierto utilizan estas estructuras legales existentes con un propósito inverso: otorgan al destinatario el derecho a usar el software, examinar el código fuente , modificarlo y distribuir las modificaciones. Estos criterios se describen en la Definición de Código Abierto (OSD).

Después de 1980, Estados Unidos comenzó a tratar el software como una obra literaria protegida 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 . "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 de copyleft . Ambas otorgan permiso para modificar y distribuir software. Por lo general, requieren atribución y eximen de responsabilidad . Las licencias permisivas provienen del ámbito académico. Las licencias de copyleft provienen del movimiento del software libre. Las licencias de copyleft requieren que las obras derivadas se distribuyan junto 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 respaldado los términos de ambos tipos de licencia. Los desarrolladores de software han presentado demandas por infracción de derechos de autor e incumplimiento de contrato.

Fondo

El jurista Eben Moglen habla sobre la historia de los derechos 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 PI el derecho a restringir el acceso de diversas maneras. [ 3 ] Los propietarios pueden vender, arrendar, donar o licenciar sus propiedades. [ 4 ] Diversos tipos de leyes de PI cubren el software, incluyendo marcas registradas , patentes y derechos de autor . [ 4 ]

La mayoría de los países, incluidos los Estados Unidos (EE. UU.), han creado leyes de derechos de autor en consonancia con el Convenio de Berna, con ligeras variaciones. [ 5 ] Estas leyes otorgan 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, representar públicamente o exhibir públicamente la obra. 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 solo puede distribuirse con el permiso de todos los titulares de los derechos de autor. [ 10 ]

En 1980, el gobierno estadounidense modificó la ley para considerar el software como una obra literaria. El software publicado a partir de entonces quedó sujeto a 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 presenció la fragmentación entre los desarrolladores de software y la atribuyó a la proliferación del software propietario y a los modelos de desarrollo cerrados. 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 Fundación del Software Libre (FSF) y redactó varias licencias de software libre. [ 13 ] La FSF utilizó las leyes de propiedad intelectual existentes para un fin opuesto a su objetivo original de restricción. En lugar de imponer restricciones, el software libre otorgaba explícitamente libertades al usuario. [ 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 Debian Free Software Guidelines (DFSG). [ 18 ] Las DFSG se redactaron para proporcionar un estándar más específico y objetivo para el FOSS que Debian alojaría en sus repositorios. [ 19 ] La OSI adoptó las DFSG y las utilizó como base para su Open Source Definition. [ 20 ] La Free Software Foundation mantiene un conjunto de criterios rival, la Free Software Definition. [ 21 ] Históricamente, estas tres organizaciones y sus conjuntos de criterios han sido las autoridades más destacadas para 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 requieren que las personas que reciben el software cubierto puedan usar, modificar y redistribuir la obra cubierta. [ 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 expandir la comunidad hacker 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 realizaban este trabajo, con el desarrollo de Linux, donde el grupo de probadores incluía potencialmente a todo el mundo. [ 29 ] Resumió esta fortaleza como "Con suficientes ojos, todos los errores son fáciles de detectar". [ 30 ] La OSI logró llevar el desarrollo de código abierto a desarrolladores corporativos, incluyendo Sun Microsystems, IBM , Netscape, Mozilla , Apache , Apple Inc., Microsoft y Nokia. Estas empresas publicaron código bajo licencias existentes y redactaron las suyas propias para su aprobación por 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 el código fuente bajo una licencia similar. Las licencias permisivas no lo requieren, por lo que el código puede utilizarse dentro de software propietario. El copyleft se puede subdividir en fuerte y débil según definan las obras derivadas de forma 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 que poseen 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 de impedir que otros fabriquen, usen, vendan o importen productos basados ​​en la idea. Debido a que las patentes otorgan el derecho de exclusión en lugar del derecho de creación, es posible tener una patente sobre una idea pero aun así no poder implementarla legalmente si la invención depende de otra idea patentada. Por lo tanto, las concesiones de patentes de código abierto solo pueden ofrecer permiso de las 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 licencias copyleft más recientes y la Licencia Apache de 2004 ofrecen concesiones de patentes explícitas y protección limitada contra litigios de patentes. [ 39 ] Estas cláusulas de represalias de patentes protegen a los desarrolladores al rescindir las concesiones para cualquier parte que inicie una demanda de patentes relacionada 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 funcionan igual que cualquier otra marca comercial. [ 40 ] Una marca comercial es un diseño que identifica el origen distintivo de un producto. Debido a que distinguen los productos, los mismos diseños pueden usarse en diferentes campos donde no existe riesgo de confusión entre fuentes similares. [ 41 ] Renunciar al control de una marca comercial resultaría en la pérdida de dicha marca. 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 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 contenido de dominio público como "derechos de autor mutantes". [ 44 ] En Dastar Corp. v. Twentieth Century Fox Film Corp. , la corte "advirtió contra el mal uso 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 código abierto y contenido gratuito vulnerables a una "adquisición hostil" si terceros solicitan marcas registradas para obras derivadas. [ 47 ] Cabe destacar que Andrey Duskin solicitó marcas registradas para la Fundación SCP , un proyecto de escritura colaborativa, al crear obras derivadas basadas en historias de SCP. [ 48 ]

Permisivo

El campus del MIT por la noche.
Las licencias permisivas generalmente se originan en instituciones académicas como el Instituto Tecnológico de Massachusetts (MIT) .

Las licencias permisivas , también conocidas como licencias académicas, [ 49 ] permiten a los destinatarios usar, 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 exenciones de responsabilidad y obligaciones de dar crédito a los autores. Algunas incluyen disposiciones explícitas para patentes, marcas registradas y otras formas de propiedad intelectual. [ 50 ]

La Universidad de California, Berkeley, creó la primera licencia de código abierto al comenzar a distribuir su sistema operativo Berkeley Software Distribution (BSD). La licencia BSD y sus variantes posteriores permiten la modificación y distribución del software cubierto. Estas licencias introdujeron el concepto de libertad académica de ideas en la informática. Los primeros autores de software académico compartían código basándose en promesas implícitas. Berkeley explicitó estos conceptos con claras exenciones de responsabilidad y garantías, junto con condiciones, o cláusulas , para la redistribución. La versión original tenía cuatro cláusulas, pero las versiones posteriores han reducido aún más las restricciones. Por lo tanto, 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 la BSD original. 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 ] Una de las fortalezas del desarrollo de código abierto es el proceso continuo donde los desarrolladores pueden construir sobre 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 rastrear la cadena de autoría. [ 53 ] Las licencias BSD y MIT son plantillas 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 servidor HTTP Apache . 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 colaboradores. [ 57 ] Además, es una de las pocas licencias permisivas con una cláusula de represalia por patentes. [ 58 ] Las cláusulas de represalia por 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 abuso de patentes . [ 59 ]

Copyleft

Una pegatina dice: "Copyleft, letra L rodeada con un círculo".
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 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 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 para crear un sistema operativo libre. En 1984, el programador Don Hopkins envió por correo un manual a Stallman con una pegatina de "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 de GNU (GPL). [ 66 ]

Las licencias de software tradicionales y propietarias se escriben con el objetivo de aumentar las ganancias , pero Stallman escribió la GPL para aumentar el conjunto de software libre disponible. Sus licencias recíprocas ofrecen los derechos para usar, modificar y distribuir la obra con la condición de que las personas deben publicar obras derivadas bajo una licencia que ofrezca estas mismas libertades. El software construido 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 propietario que consume código sin devolverlo. [ 67 ] [ 68 ] Richard Stallman afirmó que "la idea central del copyleft es usar la ley de derechos de autor, pero dándole la vuelta para que sirva al opuesto de 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 la obra cubierta esté disponible con el código fuente y con permiso para su modificación y redistribución. [ 16 ] Hay casos excepcionales en los que solo una de las organizaciones, la FSF o la OSI, acepta una licencia, pero las licencias de software libre más 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 desarrolladores comerciales. Las corporaciones han utilizado y redactado licencias recíprocas con un alcance más limitado que la GPL. [ 74 ] Por ejemplo, Netscape redactó sus propios términos copyleft después de rechazar las licencias permisivas para el proyecto Mozilla. [ 32 ] 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 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 posteriormente adoptó la Licencia Pública de 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 extiende la obligación recíproca de la GPL para cubrir el software disponible a través de una red. [ 74 ] [ 32 ] Se denominan copyleft fuerte en contraste con las licencias copyleft más débiles que suelen usar las corporaciones. El copyleft débil utiliza definiciones más estrictas y explícitas de obras derivadas. [ 75 ] [ 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 LGPL de la FSF se refiere a bibliotecas de software. [ 76 ]

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 conjuntamente 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 complica al trabajar con múltiples terminologías que imponen diferentes requisitos. [ 77 ] Existen muchas licencias poco comunes y algunos proyectos redactan sus propios acuerdos personalizados . Como resultado, esto genera más confusión que otros aspectos legales. Al publicar una colección de aplicaciones, cada licencia puede considerarse por separado. Sin embargo, al intentar combinar software, el código de otro proyecto solo puede incorporarse a la licencia si el proyecto utiliza términos y condiciones compatibles. [ 78 ]

Al combinar bases de código, las licencias originales pueden mantenerse para componentes separados, y el trabajo más grande puede publicarse bajo una licencia compatible. [ 79 ] Esta compatibilidad suele ser unidireccional. El contenido de dominio público puede usarse en cualquier lugar ya que no hay reclamación de derechos de autor, pero el código adquirido bajo casi cualquier conjunto de términos no puede pasarse al dominio público. Las licencias permisivas pueden usarse dentro de obras copyleft, pero el material copyleft no puede publicarse bajo una licencia permisiva. Algunas licencias copyleft débiles pueden usarse bajo la GPL y se dice que son compatibles con la GPL. El software GPL solo puede usarse bajo la GPL o la AGPL. [ 77 ] Las licencias permisivas son ampliamente compatibles porque pueden cubrir partes separadas de un proyecto. Varias licencias, incluidas la GPL y la Licencia Apache, se han revisado para mejorar la compatibilidad. [ 80 ]

Los problemas de traducción, la ambigüedad en los términos de licencia y la incompatibilidad de algunas licencias con la legislación de ciertas jurisdicciones agravan el problema de la compatibilidad de licencias. [ 81 ] 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. [ 82 ] Debido a la cantidad de dependencias de software, los ingenieros que trabajan en proyectos complejos suelen recurrir a software de gestión de licencias para lograr el cumplimiento de los términos de licencia de los componentes de código abierto. [ 83 ] Muchos archivos de software de código abierto no indican la licencia de forma inequívoca, lo que aumenta las dificultades de cumplimiento. [ 82 ]

Aplicación

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

Las licencias de software libre y de código abierto se han hecho cumplir con éxito en los tribunales civiles desde mediados de la década de 2000. [ 85 ] En dos demandas iniciales —Jacobsen v. Katzer en Estados Unidos y Welte v. Sitecom en Alemania— los demandados argumentaron que las licencias de código abierto eran inválidas. [ 86 ] [ 87 ] Sitecom y Katzer argumentaron por separado que las licencias no eran exigibles. Tanto los tribunales estadounidenses como los alemanes rechazaron estas alegaciones. Dictaminaron que los demandados no podían haber distribuido legalmente el software si las licencias no eran exigibles. [ 85 ] [ 84 ]

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

Los desarrolladores suelen lograr el cumplimiento sin litigios. Las presiones sociales, como la posible reacción negativa de la comunidad, suelen ser suficientes. [ 93 ] Las cartas de cese y desistimiento son un método común para que las empresas vuelvan a cumplir con la normativa, especialmente en Alemania. [ 94 ] Se ha desarrollado un proceso estándar en el sistema legal alemán. Los desarrolladores de software libre presentan a las empresas una carta de cese y desistimiento. Estas cartas describen cómo volver a cumplir con la normativa tras una infracción. Los jueces alemanes pueden emitir una orden judicial de cese y desistimiento a las empresas que no respondan. Si estos primeros pasos fracasan, se inician procesos civiles. Las leyes procesales alemanas son claras y favorables a los demandantes. [ 95 ]

Persisten las incertidumbres sobre cómo los distintos tribunales abordarán ciertos aspectos de las licencias. [ 96 ] En el caso del software en general, existen debates sobre qué se puede patentar y qué se puede proteger con derechos de autor. Respecto 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 programas informáticos] no están protegidos por derechos de autor». [ 97 ] En un caso similar de 2021 , la Corte Suprema de los Estados Unidos permitió la recreación de una API en un producto transformador bajo el principio de uso legítimo . [ 98 ]

Un tema largamente debatido dentro de la comunidad FOSS es si las licencias de código abierto son "licencias simples" o contratos . [ 96 ] Una licencia simple es un conjunto de condiciones bajo las cuales se permiten acciones que de otro modo estarían restringidas por las leyes de propiedad intelectual. [ 85 ] Bajo la interpretación de licencia simple, defendida por la FSF, el titular de los derechos de autor presenta una demanda ante los tribunales por infracción de derechos de autor . [ 85 ] Bajo la interpretación de contrato, una parte involucrada puede presentar una demanda ante los tribunales por incumplimiento de contrato . [ 99 ] Los tribunales de EE. UU. y Francia han juzgado casos bajo ambas interpretaciones. [ 100 ] Organizaciones sin fines de lucro como la FSF y la Software Freedom Conservancy ofrecen mantener los derechos de los proyectos de los desarrolladores para garantizar el cumplimiento. [ 95 ]

Software de dominio público

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

Cuando expiran los derechos de autor, la obra pasa a ser de dominio público y está disponible gratuitamente para cualquiera. [ 102 ] Algunas obras creativas no están cubiertas por derechos de autor y pasan directamente al dominio público. En los inicios de la informática, esto se aplicaba al software. [ 11 ] El software de las primeras computadoras a menudo se regalaba con el hardware. [ 103 ] Desarrollado inicialmente en el MIT, el videojuego pionero Spacewar! se utilizó para comercializar y probar la computadora PDP-1 . [ 104 ]

Según el abogado Lawrence Rosen , las leyes de derechos de autor no se redactaron con la expectativa de que los creadores pusieran 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. [ 105 ] [ 106 ]

Una licencia equivalente al dominio público , como la Creative Commons CC0, proporciona una renuncia a los derechos de autor en el dominio público junto con una licencia de software permisiva como alternativa. En las jurisdicciones que no aceptan una renuncia al dominio público, la licencia permisiva entra en vigor. [ 107 ] Las renuncias al dominio público comparten limitaciones con las licencias académicas simples. Esto crea la posibilidad de que un tercero intente controlar una obra de dominio público mediante la ley de patentes o marcas registradas. [ 108 ] Las renuncias al dominio público manejan las garantías de manera diferente a cualquier otro tipo de licencia. Incluso las más permisivas, como la licencia MIT, eximen de garantía y responsabilidad. Cualquier persona que utilice el software libre debe aceptar esta exención de responsabilidad como condición. Dado que el contenido de dominio público está disponible para todos, la renuncia a los derechos de autor no puede imponer una exención de responsabilidad. [ 102 ]

Uso en software propietario

Las licencias de código abierto permiten a otras empresas comercializar el software cubierto. [ 109 ] El trabajo publicado bajo una licencia permisiva puede incorporarse al software propietario. [ 110 ] Las licencias permisivas permiten la adición de nuevos términos, incluidos los propietarios. [ 111 ] [ 112 ] El software propietario tiene código de código abierto ampliamente integrado publicado bajo las licencias Apache, BSD y MIT. [ 113 ] El núcleo abierto es un modelo de negocio donde los desarrolladores publican una pieza central de software como código abierto y monetizan un producto que lo contiene como software propietario. [ 114 ] La GPL de copyleft fuerte está escrita para evitar la distribución dentro del software propietario. [ 115 ] [ 116 ] Las licencias de copyleft débil imponen requisitos específicos a las obras derivadas que pueden permitir que el código cubierto se distribuya dentro del software propietario en ciertas circunstancias. [ 77 ]

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. [ 117 ] 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. [ 118 ] La licencia pública general affero de GNU (AGPL) se activa cuando el código cubierto se aloja o distribuye. [ 119 ] Algunos desarrolladores han adoptado la AGPL, y otros han cambiado a licencias propietarias con características de licencias de código abierto. [ 120 ] Por ejemplo, el desarrollador de código abierto Elastic cambió de la licencia Apache a la licencia pública del lado del servidor "de código fuente disponible" . [ 121 ] El software de código fuente disponible viene con el código fuente como referencia. [ 122 ]

Desde 2010, el modelo de nube ha ganado prominencia. [ 117 ] Los desarrolladores han criticado a las empresas de nube que se benefician del alojamiento de software de código abierto sin contribuir económicamente ni con código al proyecto original, comparando esta práctica con la minería de código abierto . [ 123 ] El líder en 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. [ 123 ] [ 124 ]

Véase también

Notas

  1. Byfield 2008 .
  2. Rosen 2005 , pág. 22.
  3. Rosen 2005 , págs. 22–23.
  4. 1 2 Rosen 2005 , pág. 15.
  5. Smith 2022 , sec. 3.1.2.
  6. Fagundes y Perzanowski 2020 , p. 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. 1 2 Omán 2018 , págs. 641–642.
  12. Williams 2002 , cap. 1.
  13. Williams 2002 , cap. 7.
  14. 1 2 Williams 2002 , cap. 9.
  15. Greenbaum 2016 , sec. IA
  16. 1 2 3 Marrakech 2019 , sec. 2.2.
  17. Carver 2005 , págs. 448–450.
  18. Perens 1999 .
  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 , sec. 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. 1 2 3 Hammerly, Paquin y Walton 1999 .
  33. Smith 2022 , sec. 3.2.
  34. 1 2 Sen, Subramaniam y Nelson 2008 , págs. 211–212.
  35. 1 2 Meeker 2020 , 16:13.
  36. 1 2 Rosen 2005 , págs. 22–24.
  37. Bain & Smith 2022 , sec. 10.4.3.
  38. Bain & Smith 2022 , sec. 10.4.2.
  39. 1 2 Bain & Smith 2022 , sec. 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. v. Twentieth Century Fox Film Corp. , 539 U.S. 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. 1 2 Rosen 2005 , pág. 69.
  50. Rosen 2005 , págs. 101–102.
  51. 1 2 Smith 2022 , sec. 3.2.1.1.
  52. OSI 2023 .
  53. 1 2 Rosen 2005 , págs. 73–90.
  54. OSI 2023 , "La licencia MIT".
  55. Smith 2022 , sec. 3.2.1.2.
  56. Bain & Smith 2022 , sec. 10.4.2.
  57. OSI 2023 , "Licencia Apache, versión 2.0".
  58. Bain & Smith 2022 , cap. 10.
  59. Bain & Smith 2022 , sec. 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. Alegría 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. ^ Tsai 2008 , págs. 564–570.
  75. Sen, Subramaniam y Nelson 2008 , págs. 212–213.
  76. Rosen 2005 , véanse los capítulos correspondientes.
  77. 1 2 3 Smith 2022 , sec. 3.3.
  78. Rosen 2005 , págs. 243–247.
  79. St. Laurent 2004 , págs. 159–163.
  80. Véase Smith 2022 , pág. 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. Véase Smith 2022 , págs. 95-101 para: MPL versión 2.0 en 2012 y EPL versión 2 en 2017.  
  81. Bernelin 2020 , págs. 100, 102.
  82. 1 2 Ombredanne 2020 , pág. 105.
  83. Ombredanne 2020 , pág. 106.
  84. ^ Ballhausen 2022 , sec. 5.3.
  85. 1 2 3 4 Smith 2022 , sec. 3.4.1.
  86. ^ Jacobsen contra Katzer , 535 F.3d 1373 ( Fed. Cir. 2008).
  87. Welte contra Sitecom (Tribunal de Distrito de Múnich 2004), n.º 21 O 6123/04 .
  88. Smith 2022 , pág. 106.
  89. Rosen 2005 , pág. 137.
  90. Rosen 2005 , pág. 138.
  91. Rosen 2005 , cap. 6.
  92. Meeker 2020 , 17:04.
  93. St. Laurent 2004 , págs. 158–159.
  94. Ballhausen 2022 , pág. 127.
  95. ^ Ballhausen 2022 , sec. 5.4.
  96. 1 2 Walden 2022 , sec. 1.1.
  97. Smith 2022 , sec. 3.1.3.
  98. Google LLC v. Oracle America, Inc. , 593 U.S. , 1203 (2021).
  99. Smith 2022 , sec. 3.4.2.
  100. Smith 2022 , sec. 3.4.
  101. Ross 2021 , "Guerra espacial: Fin del desarrollo".
  102. 1 2 Rosen 2005 , pág. 36.
  103. Walden 2022 , pág. 3.
  104. Smith 2019 , págs. 55–56.
  105. Rosen 2005 , págs. 74–77.
  106. St. Laurent 2004 , pág. 98.
  107. Fagundes y Perzanowski 2020 , p. 524.
  108. Alegría 2022 , págs. 1008-1010.
  109. Brock 2022 , sec. 16.3.3.
  110. St. Laurent 2004 , pág. 14.
  111. St. Laurent 2004 , pág. 22.
  112. Onetti y Verma 2009 , pág. 81.
  113. St. Laurent 2004 , pág. 30.
  114. Brock 2022 , sec. 16.4.2.3.
  115. Tsai 2008 , pág. 550.
  116. St. Laurent 2004 , pág. 39.
  117. 1 2 Brock 2022 , sec. 16.5.2.
  118. Brock 2022 , sec. 16.4.2.8.
  119. Brock 2022 , sec. 16.4.2.2.
  120. Brock 2022 , sec. 16.5.3.
  121. Brock 2022 , sec. 16.5.3.8.
  122. Kunert 2022 .
  123. ^ Wakabayashi 2019 .
  124. Brock 2022 , sec. 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. Bibcode : 2019Compr..52f..82B . 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 del código abierto (Segunda  edición). Oxford University Press . doi : 10.1093/oso/9780198862345.001.0001 . ISBN 978-0-19-886234-5.
    • Bain, Malcom; Smith, P McCoy. " Patentes y la 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. " Derechos de autor, contrato y licencias en código abierto ". En Brock (2022) .
    • Walden, Ian. " El código abierto como filosofía, metodología y comercio: usar la ley con actitud ". En Brock (2022) .
  • Byfield, Bruce (4 de marzo de 2008) .Software "gratuito" y "de código abierto": Descifrando los estereotipos . Datamation . Consultado el 6 de junio de 2024 .
  • Carver, Brian W. (2005). "Compartir y compartir por igual: comprender y hacer cumplir las licencias de software libre y de código abierto" . Berkeley Technology Law Journal . 20 (1): 443– 481. ISSN 1086-3818 . JSTOR 24117523 .  
  • Coleman, Gabriella (2004). "El agnosticismo político del software libre y de código abierto y la política inadvertida del contraste" . Anthropological Quarterly . 77 (3): 507– 519. doi : 10.1353/anq.2004.0035 . hdl : 10524/1583 . ISSN 0003-5491 . JSTOR 3318232 .  
  • DiBona, Chris; Stone, Mark; Ockman, Sam, eds. (1999). Open Sources: Voices from the Open Source Revolution . Sebastopol, California: O'Reilly Media . Archivado del original el 27 de enero de 2023. Recuperado el 21 de enero de 2023 .
  • Fagundes, Dave; Perzanowski, Aaron (noviembre de 2020). "Abandonando los derechos de autor". William & Mary Law Review . 62 (2): 487– 569.
  • Fontana, Richard E. (abril de 2010). "Aplicación y cumplimiento 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 la superposición de derechos de propiedad intelectual socava el uso de licencias permisivas». Case Western Reserve Law Review . 72 (4): 977– 1013.
  • Keats, Jonathon (2010). Palabras virtuales: El lenguaje en la frontera de la ciencia y la tecnología . Oxford University Press . doi : 10.1093/oso/9780195398540.003.0017 . ISBN 978-0-19-539854-0Archivado del original el 26 de marzo de 2023. Consultado el 28 de enero de 2023 .
  • Kunert, Paul (8 de septiembre de 2022). "Open Source Biz cambia Akka a Business Source License" . Archivado del original el 31 de octubre de 2022. Recuperado 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 las patentes esenciales para estándares 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 . Recuperado el 7 de diciembre de 2023 .
  • Oman, Ralph (Primavera de 2018). "El software informático como materia protegible por derechos de autor: Oracle contra Google, la intención legislativa y el alcance de los derechos sobre las 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 del software" . Computer . 53 (10): 105– 109. Bibcode : 2020Compr..53j.105O . doi : 10.1109/MC.2020.3011082 .
  • Onetti, Alberto; Verma, Sameer (1 de mayo de 2009). "Licencias de código abierto y modelos de negocio". ICFAI Journal of Knowledge Management . 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-7Archivado del 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 en rústica). Upper Saddle River, NJ: Prentice Hall . ISBN 978-0-13-148787-1Archivado del original el 19 de diciembre de 2022. Consultado el 21 de enero de 2023 .
  • Ross, Heather (4 de enero de 2021). "Guerra espacial: 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). Crean mundos: La historia de las personas y 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). Comprensión del software libre y de código abierto . 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" . The New York Times . Recuperado el 24 de mayo de 2024 .
  • Williams, Sam (2002). Free as in Freedom: Richard Stallman's Crusade for Free Software (Primera  ed.). Sebastopol, California  : Farnham: O'Reilly Media . ISBN 978-0-596-00287-9Archivado del original el 7 de febrero de 2023. Consultado el 6 de febrero de 2023 .