stringtranslate.com

Licencia de software libre

El espectro de licencias de software libre y algunos ejemplos de programas bajo esas licencias [1]

Una licencia de software libre es un aviso que otorga al receptor de un software amplios derechos para modificar y redistribuir ese software. Estas acciones suelen estar prohibidas por la ley de derechos de autor , pero el titular de los derechos (normalmente el autor) de un software puede eliminar estas restricciones acompañando el software con una licencia de software que le otorga al receptor estos derechos. El software que utiliza dicha licencia es software libre (o software libre y de código abierto ) según lo confiere el titular de los derechos de autor. Las licencias de software libre se aplican al software en código fuente y también en forma de código objeto binario , ya que la ley de derechos de autor reconoce ambas formas. [2]

Comparación

Las licencias de software libre brindan mitigación de riesgos frente a diferentes amenazas legales o comportamientos que los desarrolladores consideran potencialmente dañinos:

Historia

Antes de 1980

En los primeros tiempos del software, compartir software y código fuente era algo común en ciertas comunidades, por ejemplo, las instituciones académicas. Antes de que la Comisión de los Estados Unidos sobre Nuevos Usos Tecnológicos de Obras con Derechos de Autor (CONTU) decidiera en 1974 que "los programas informáticos, en la medida en que incorporan la creación original de un autor, son materia adecuada de derechos de autor", [3] [4] el software no se consideraba susceptible de derechos de autor. Por lo tanto, el software no tenía licencias adjuntas y se compartía como software de dominio público . La decisión de la CONTU y las decisiones judiciales como Apple v. Franklin en 1983 por el código objeto aclararon que la Ley de Derechos de Autor dio a los programas informáticos el estatus de derechos de autor de las obras literarias e inició el licenciamiento de software .

Las licencias de software libre anteriores a finales de los años 1980 eran, por lo general, avisos informales escritos por los propios desarrolladores. Estas primeras licencias eran del tipo " permisivo ".

Década de 1980

A mediados de los años 1980, el proyecto GNU produjo licencias de software libre con copyleft para cada uno de sus paquetes de software. Una de esas primeras licencias (la "Aviso de permiso de copia de GNU Emacs") se utilizó para GNU Emacs en 1985, [5] que se revisó y se convirtió en la "Licencia pública general de GNU Emacs" a fines de 1985, y se clarificó en marzo de 1987 y febrero de 1988. [6] [7] [8] De la misma manera, la Licencia pública general GCC similar se aplicó a la Colección de compiladores de GNU , que se publicó inicialmente en 1987. [9] [10] La licencia BSD original es también una de las primeras licencias de software libre, que data de 1988. En 1989, se publicó la versión  1 de la Licencia pública general de GNU  (GPL). La versión 2 de la GPL, lanzada en 1991, se convirtió en la licencia de software libre más utilizada. [11] [12] [13]

De los años 1990 a los años 2000

A partir de mediados de la década de 1990 y hasta mediados de la década de 2000, el movimiento de código abierto impulsó y enfocó la idea del software libre en la percepción más amplia del público y las empresas. [14] En la época de la burbuja puntocom , la decisión de Netscape Communications de lanzar su navegador web bajo una licencia FOSS en 1998, [15] [16] inspiró a muchas otras empresas a adaptarse al ecosistema FOSS. [17] En esta tendencia, las empresas y los nuevos proyectos ( Mozilla , Apache Foundation y Sun , consulte también esta lista ) escribieron sus propias licencias FOSS o adaptaron licencias existentes. Esta proliferación de licencias se reconoció más tarde como un problema para el ecosistema libre y de código abierto debido a la mayor complejidad de las consideraciones de compatibilidad de licencias . [18] Si bien la creación de nuevas licencias se desaceleró más tarde, la proliferación de licencias y su impacto se consideran un desafío serio y continuo para el ecosistema libre y de código abierto.

De las licencias de software libre, la GPL GNU versión  2 ha sido puesta a prueba en los tribunales, primero en Alemania en 2004 y después en los EE.UU. En el caso alemán, el juez no discutió explícitamente la validez de las cláusulas de la GPL, pero aceptó que la GPL debía ser respetada: "Si las partes no hubieran acordado la GPL, el demandado no tendría los derechos necesarios para copiar, distribuir y poner a disposición del público el software 'netfilter/iptables'". Como el demandado no cumplía con la GPL, tuvo que dejar de utilizar el software. [19] El caso estadounidense ( MySQL vs. Progress) se resolvió antes de que se llegara a un veredicto, pero en una audiencia inicial, el juez Saris "no vio ninguna razón" para que la GPL no fuera ejecutable. [20]

Alrededor de 2004, el abogado Lawrence Rosen argumentó en el ensayo Por qué el dominio público no es una licencia que el software no podía realmente ser renunciado al dominio público y no puede interpretarse como una licencia FOSS muy permisiva, [21] una posición que enfrentó la oposición de Daniel J. Bernstein y otros. [22] En 2012, la disputa finalmente se resolvió cuando Rosen aceptó la CC0 como licencia de código abierto , al tiempo que admitió que, contrariamente a sus afirmaciones anteriores, los derechos de autor pueden renunciarse, respaldados por las decisiones del Noveno Circuito . [23]

En 2007, después de años de discusión de borradores, se publicó la GPLv3 como actualización principal de la GPLv2. El lanzamiento fue controvertido [24] debido al alcance significativamente extendido de la licencia, que la hacía incompatible con la GPLv2. [25] Varios proyectos FOSS importantes ( núcleo Linux , [26] [27] MySQL , [28] BusyBox , [29] [30 ] Blender , [31] reproductor multimedia VLC [32] ) decidieron no adoptar la GPLv3. Por otro lado, en 2009, dos años después del lanzamiento de la GPLv3, el gerente de la oficina de programas de código abierto de Google, Chris DiBona, informó que el número de proyectos de código abierto con software con licencia que habían migrado a GPLv3 desde GPLv2 era del 50%, contando los proyectos alojados en Google Code . [33]

Década de 2010

En 2011, cuatro años después del lanzamiento de la GPLv3, el 6,5% de todos los proyectos con licencia de código abierto eran GPLv3, mientras que el 42,5% todavía eran GPLv2, según los datos de Black Duck Software. [27] [34] Posteriormente, en 2011, el analista de 451 Group, Matthew Aslett, argumentó en una publicación de blog que las licencias copyleft entraron en declive y las licencias permisivas aumentaron, según las estadísticas de Black Duck Software. [35] [36]

En 2015, según las estadísticas de Black Duck Software [37] y GitHub , [38] la licencia permisiva MIT destronó a la GPLv2 como la licencia de software libre más popular y la colocó en segundo lugar, mientras que la licencia permisiva Apache ya ocupaba el tercer lugar. En junio de 2016, un análisis de los paquetes del Proyecto Fedora reveló que las licencias más utilizadas eran la GPL, MIT, BSD y la LGPL . [39]

Definiciones

Licencias de código abierto aprobadas por OSI

El grupo Open Source Initiative (OSI) define y mantiene una lista de licencias de código abierto aprobadas . OSI está de acuerdo con la FSF en todas las licencias de software libre ampliamente utilizadas, pero difiere de la lista de la FSF, ya que aprueba según la Definición de Código Abierto en lugar de la Definición de Software Libre . Considera que el grupo de licencias Free Software Permissive es una implementación de referencia de una licencia de Software Libre. [ cita requerida ] [ aclaración necesaria ] Por lo tanto, sus requisitos para aprobar licencias son diferentes.

Licencias de software libre aprobadas por la FSF

La Free Software Foundation , el grupo que mantiene la Definición de Software Libre , mantiene una lista no exhaustiva de licencias de software libre. [40]

La Free Software Foundation prefiere las licencias de software libre con copyleft ( share-alike ) en lugar de las licencias de software libre permisivas para la mayoría de los propósitos. Su lista distingue entre licencias de software libre que son compatibles o incompatibles con la Licencia Pública General GNU con copyleft de la FSF .

Condiciones en las licencias de software libre

Existe un debate en curso dentro de la comunidad de software libre sobre la delgada línea que separa qué restricciones se pueden aplicar y seguir siendo considerados "libres". [ cita requerida ]

Sólo el " software de dominio público " y el software con una licencia similar a la del dominio público están libres de restricciones. [ cita requerida ] Ejemplos de licencias similares a las del dominio público son, por ejemplo, la WTFPL y la licencia CC0 . Las licencias permisivas pueden conllevar pequeñas obligaciones como la atribución del autor pero permiten prácticamente todos los casos de uso del código. Ciertas licencias, en concreto las licencias copyleft , incluyen restricciones intencionadamente más fuertes (especialmente en la distribución/distribuidor) para obligar a los proyectos derivados a garantizar derechos específicos que no se pueden quitar.

Copia izquierda

Las licencias de software libre de uso compartido por igual, escritas por Richard Stallman a mediados de los años 80, fueron pioneras en un concepto conocido como "copyleft". Las cláusulas de copyleft posteriores establecían que, cuando se distribuyeran versiones modificadas de software libre, debían distribuirse bajo los mismos términos que el software original. Por eso se las denominaba "compartir y compartir por igual " o " quid pro quo ". Esto hace que el nuevo software también sea de código abierto. Dado que el copyleft garantiza que las generaciones posteriores del software concedan la libertad de modificar el código, se trata de "software libre". Las licencias sin copyleft no garantizan que las generaciones posteriores del software sigan siendo libres.

Los desarrolladores que utilizan código GPL en sus productos deben poner el código fuente a disposición de cualquier persona cuando comparten o venden el código objeto . En este caso, el código fuente también debe contener todos los cambios que los desarrolladores hayan podido realizar. Si se utiliza código GPL pero no se comparte ni se vende, no es necesario que el código esté disponible y todos los cambios pueden permanecer privados. Esto permite a los desarrolladores y organizaciones utilizar y modificar código GPL para fines privados (es decir, cuando el código o el proyecto no se vende ni se comparte de otro modo) sin necesidad de poner sus cambios a disposición del público.

Los partidarios de la GPL sostienen que al obligar a que las obras derivadas permanezcan bajo la GPL, se fomenta el crecimiento del software libre y se exige la participación igualitaria de todos los usuarios. Los opositores a la GPL sostienen [41] que "ninguna licencia puede garantizar la disponibilidad futura del software" y que las desventajas de la GPL superan [42] a sus ventajas. Algunos también sostienen que restringir la distribución hace que la licencia sea menos libre, mientras que los defensores argumentarían que no preservar la libertad durante la distribución la haría menos libre. Por ejemplo, una licencia sin copyleft no otorga al autor la libertad de ver versiones modificadas de su obra si se publica públicamente, mientras que una licencia con copyleft sí otorga esa libertad.

Represalias por patentes

Durante la década de 1990, las licencias de software libre comenzaron a incluir cláusulas, como la de represalias por patentes , para protegerse contra casos de litigios por patentes de software , un problema que no existía anteriormente. Esta nueva amenaza fue una de las razones para escribir la versión  3 de la GPL de GNU en 2006. [43] En los últimos años, un término acuñado, tivoización, describe un proceso en el que se utilizan restricciones de hardware para evitar que los usuarios ejecuten versiones modificadas del software en ese hardware, en el que el dispositivo TiVo es un ejemplo. La FSF lo ve como una forma de convertir el software libre en no libre, y es por eso que ha decidido prohibirlo en la GPLv3 . [44] La mayoría de las licencias de software libre escritas recientemente desde fines de la década de 1990 incluyen algún tipo de cláusulas de represalias por patentes. Estas medidas estipulan que los derechos de uno bajo la licencia (como la redistribución) pueden terminar si uno intenta hacer cumplir las patentes relacionadas con el software licenciado, bajo ciertas circunstancias. Por ejemplo, la licencia de código público de Apple puede poner fin a los derechos de un usuario si este inicia un proceso judicial en su contra debido a un litigio de patentes. Las represalias por patentes surgieron como respuesta a la proliferación y el abuso de las patentes de software .

Atribución, exenciones de responsabilidad y avisos

La mayoría de las licencias de software libre exigen que el software modificado no afirme que no ha sido modificado. Algunas licencias también exigen que se reconozca a los titulares de los derechos de autor. Un ejemplo de ello es la versión  2 de la GPL de GNU, que exige que los programas interactivos que imprimen información sobre la garantía o la licencia no puedan tener estos avisos eliminados de las versiones modificadas destinadas a ser distribuidas.

Problemas prácticos con las licencias

Compatibilidad de licencias

Compatibilidad de licencias entre licencias de software FOSS comunes según David A. Wheeler (2007): las flechas vectoriales denotan una compatibilidad unidireccional, por lo tanto mejor compatibilidad en el lado izquierdo ("licencias permisivas") que en el lado derecho ("licencias copyleft"). [45]

Las licencias de paquetes de software que contienen requisitos contradictorios hacen imposible combinar el código fuente de dichos paquetes para crear nuevos paquetes de software. [46] La compatibilidad de licencias entre una licencia copyleft y otra licencia a menudo es solo una compatibilidad unidireccional. [47] Esta característica de "compatibilidad unidireccional" es, por ejemplo, criticada por la Apache Foundation , que proporciona la licencia Apache más permisiva que no tiene esta característica. [48] Las licencias que no son copyleft, como las licencias permisivas FOSS , tienen una interacción de licencia menos complicada y normalmente muestran una mejor compatibilidad de licencias. [49] [50] Por ejemplo, si una licencia dice "las versiones modificadas deben mencionar a los desarrolladores en cualquier material publicitario", y otra licencia dice "las versiones modificadas no pueden contener requisitos de atribución adicionales", entonces, si alguien combinara un paquete de software que usa una licencia con un paquete de software que usa la otra, sería imposible distribuir la combinación porque estos requisitos contradictorios no se pueden cumplir simultáneamente. Por lo tanto, estos dos paquetes serían incompatibles en cuanto a licencias. En lo que respecta a las licencias de software copyleft , no son inherentemente compatibles con otras licencias copyleft, incluso la GPLv2, por sí misma, no es compatible con la GPLv3. [25] [51]

Finalidad de uso

Las restricciones al uso de un software ("restricciones de uso") son generalmente inaceptables según la FSF, OSI , Debian o las distribuciones basadas en BSD. Algunos ejemplos incluyen prohibir que el software se use para aplicaciones no privadas, para propósitos militares, para comparación o evaluación comparativa, para un buen uso, [ aclaración necesaria ] para fines éticamente cuestionables, [52] o en organizaciones comerciales. [53] Si bien algunas restricciones a la libertad del usuario, por ejemplo, las relacionadas con la guerra nuclear, parecen disfrutar del apoyo moral entre la mayoría de los desarrolladores de software libre, [54] generalmente se cree que tales agendas no deberían ser atendidas a través de licencias de software; entre otras cosas debido a aspectos prácticos como las incertidumbres legales resultantes y los problemas con la aplicabilidad de criterios vagos, amplios y/o subjetivos o porque los fabricantes de herramientas generalmente no son responsables del uso que otras personas hacen de sus herramientas. Sin embargo, algunos proyectos incluyen peticiones legalmente no vinculantes al usuario, de manera destacada SQLite . [55] Entre los repetidos intentos [56] [57] [58] de los desarrolladores para regular el comportamiento del usuario a través de la licencia que provocaron un debate más amplio se encuentran la cláusula de “no maldad” (en broma) de Douglas Crockford , que afectó el proceso de lanzamiento de la distribución Debian en 2012 [59] y consiguió que el proyecto JSMin-PHP fuera expulsado de Google Code , [60] la adición de una condición pacifista basada en la Primera Ley de Robótica de Asimov a la GPL para el software de computación distribuida GPU en 2005, [61] así como varios proyectos de software que intentan excluir el uso por parte de los grandes proveedores de la nube. [62] [63]

Conflictos de definición

Como hay varias organizaciones y grupos que publican definiciones y pautas sobre las licencias FOSS, en particular la FSF, la OSI, el proyecto Debian y las BSD, a veces hay opiniones e interpretaciones conflictivas.

Opiniones permisivas versus opiniones copyleft

Muchos usuarios y desarrolladores de sistemas operativos basados ​​en BSD tienen una postura diferente sobre las licencias. La principal diferencia es la creencia de que las licencias copyleft , en particular la Licencia Pública General GNU (GPL), son indeseablemente complicadas y/o restrictivas. [64] La GPL exige que cualquier trabajo derivado también se publique de acuerdo con la GPL, mientras que la licencia BSD no lo exige. Esencialmente, el único requisito de la licencia BSD es reconocer a los autores originales y no impone restricciones sobre cómo se puede utilizar el código fuente .

Como resultado, el código BSD se puede utilizar en software propietario que solo reconoce a los autores. Por ejemplo, Microsoft Windows NT 3.1 y macOS tienen pilas de IP propietarias que se derivan de software con licencia BSD. [65] En casos extremos, las posibilidades de sublicencia o re-licencia con BSD u otras licencias permisivas podrían impedir un uso posterior en el ecosistema de código abierto. Por ejemplo, el repositorio FileExchange de MathWorks ofrece la licencia BSD para las contribuciones de los usuarios, pero impide con términos de uso adicionales cualquier uso además de su propio software propietario MATLAB , por ejemplo con el software FOSS GNU Octave . [66] [67] [68]

Los partidarios de la licencia BSD argumentan que es más libre que la GPL porque otorga el derecho a hacer lo que se quiera con el código fuente, siempre que se preserve la atribución. Este enfoque ha llevado a que el código BSD se utilice en software propietario ampliamente utilizado. Los defensores de la GPL señalan que una vez que el código se vuelve propietario, se niegan a los usuarios las libertades que definen al software libre. [69] Como resultado, consideran que la licencia BSD es menos libre que la GPL, y que esa libertad es más que una falta de restricción. Dado que la licencia BSD restringe el derecho de los desarrolladores a que los cambios se vuelvan a aportar a la comunidad, [ dudoso – discutir ] ni ella ni la GPL son "libres" en el sentido de "carecer de restricciones".

Debian

El proyecto Debian utiliza los criterios establecidos en sus Directrices de software libre de Debian (DFSG). Los únicos casos notables en los que Debian y la Free Software Foundation no están de acuerdo son en relación con la Licencia Artística y la Licencia de Documentación Libre de GNU (GFDL). Debian acepta la Licencia Artística original como licencia de software libre, pero la FSF no está de acuerdo. Sin embargo, esto tiene muy poco impacto, ya que la Licencia Artística casi siempre se utiliza en una configuración de licencia dual , junto con la Licencia Pública General de GNU .

Casos limítrofes controvertidos

La gran mayoría del software libre utiliza licencias de software libre indiscutibles; sin embargo, ha habido muchos debates sobre si ciertas otras licencias califican o no para la definición.

Ejemplos de licencias que provocaron debate fueron la serie 1.x de la Licencia de Código Público de Apple , que fue aceptada por la Iniciativa de Código Abierto pero no por la Free Software Foundation o Debian, y la Licencia de Código Público de RealNetworks , que fue aceptada por la Iniciativa de Código Abierto y la Free Software Foundation pero no por Debian .

Además, la FSF recomendó la Licencia de Documentación Libre GNU , [70] que es incompatible con la GPL, [71] fue considerada "no libre" por el proyecto Debian alrededor de 2006, [72] Nathanael Nerode, [73] y Bruce Perens . [74] La FSF argumenta que la documentación es cualitativamente diferente del software y está sujeta a diferentes requisitos. Debian aceptó, en una resolución posterior, que la FDL de GNU cumplía con las Directrices de Software Libre de Debian cuando se elimina la controvertida "sección invariante", pero considera que "aún no está libre de problemas". [75] No obstante, la mayoría de la documentación de GNU incluye "secciones invariantes". De manera similar, la fundación FLOSS Manuals , una organización dedicada a crear manuales para software libre, decidió en 2007 dejar de lado la GFDL en favor de la GPL para sus textos, citando la incompatibilidad entre ambas, las dificultades para implementar la GFDL y el hecho de que la GFDL "no permite una fácil duplicación y modificación", especialmente para la documentación digital. [76]

SLUC es una licencia de software publicada en España en diciembre de 2006 para permitir todo uso excepto el militar. Los autores de la licencia sostienen que es software libre, pero la Free Software Foundation dice que no es libre porque infringe la llamada "libertad cero" de la GPL, es decir, la libertad de usar el software para cualquier propósito. [77]

Cuota de mercado

Si bien históricamente la licencia FOSS más utilizada ha sido la GPLv2, en 2015, según Black Duck Software [37] la licencia permisiva MIT destronó a la GPLv2 y la colocó en segundo lugar, mientras que la licencia Apache también lo hizo en tercer lugar. Un estudio de 2012, que utilizó datos disponibles públicamente, criticó a Black Duck Software por no publicar la metodología que utilizaba para recopilar estadísticas. [78] Daniel German, profesor del Departamento de Ciencias de la Computación de la Universidad de Victoria en Canadá, presentó una charla en 2013 sobre los desafíos metodológicos para determinar cuáles son las licencias de software libre más utilizadas, y mostró cómo no podía replicar el resultado de Black Duck Software. [79]

Un estudio de GitHub realizado en 2015 sobre sus datos estadísticos descubrió que la licencia MIT era la licencia FOSS más destacada en esa plataforma. [38]

En junio de 2016, un análisis de los paquetes del Proyecto Fedora mostró que las licencias más utilizadas eran la familia GPL, seguida de MIT, BSD, la familia LGP, Artistic (para paquetes Perl), LPPL (para paquetes texlive ) y ASL. La GNU GPLv2+ fue la licencia más popular [39]

Véase también

Notas

  1. ^ Wheeler, David A. (2015). «La lucha por la libertad». Archivado desde el original el 4 de julio de 2017. Consultado el 17 de febrero de 2016 .
  2. ^ Hancock, Terry (29 de agosto de 2008). "¿Qué pasaría si el copyright no se aplicara a los ejecutables binarios?". Revista de Software Libre . Archivado desde el original el 25 de enero de 2016. Consultado el 25 de enero de 2016 .
  3. ^ Apple Computer, Inc. v. Franklin Computer Corporation devuelve el derecho de autor a los programas informáticos en Golden Gate University Law Review, volumen 14, número 2, artículo 3, por Jan L. Nussbaum (enero de 1984)
  4. ^ Lemley, Menell, Merges y Samuelson. Software and Internet Law , pág. 34.
  5. ^ "Aviso sobre permisos de copia de GNU Emacs (1985)". GitHub . Consultado el 8 de noviembre de 2015 .
  6. ^ "GPLv3 - Transcripción de Richard Stallman de la tercera conferencia internacional GPLv3, Barcelona; 2006-06-22 - FSFE" . Consultado el 15 de julio de 2021 .
  7. ^ Rubin, Paul (12 de diciembre de 1985). "Montgomery EMACS: ¿cuándo abandonó el dominio público?". Grupo de noticias : net.emacs. Este último está cubierto por la Licencia Pública General de GNU Emacs, que establece que las fuentes de cualquier cosa que lo utilice deben estar disponibles gratuitamente para todos.
  8. ^ "Software libre: aplicación de la GPL". Tech Insider . Consultado el 1 de mayo de 2015 .
  9. ^ "Comunicados del CCG" . Consultado el 19 de marzo de 2015 .
  10. ^ "GPLv3 - Transcripción de Richard Stallman de la segunda conferencia internacional GPLv3, Porto Alegre, Brasil; 2006-04-21". Fsfe - Free Software Foundation Europe . Archivado desde el original el 15 de junio de 2010. Consultado el 19 de marzo de 2015 .
  11. ^ Mark (8 de mayo de 2008). "La maldición de la proliferación de licencias de código abierto". socializedsoftware.com. Archivado desde el original el 8 de diciembre de 2015. Consultado el 30 de noviembre de 2015. Licencia pública general de GNU (GPL) 2.0 58,69 % Licencia pública general reducida de GNU (LGPL) 2.1 11,39 % Licencia artística (Perl) 7,46 % Licencia BSD 6,50 % Licencia Apache 2.0 2,92 % Licencia MIT 2,58 % Licencia pública general de GNU (GPL) 3.0 1,64 % Licencia pública de Mozilla (MPL) 1.1 1,37 % Licencia pública común 0,83 % Licencia zlib/lippng 0,64 %
  12. ^ David A. Wheeler. "Estimación del tamaño de Linux".
  13. ^ "SourceForge.net: Software Map". Dwheeler.com. Archivado desde el original el 13 de febrero de 2017. Consultado el 17 de noviembre de 2008. Licencia -> OSI: […] Licencia Pública General GNU (GPL) (32641 proyectos), Licencia Pública General Reducida o de Biblioteca GNU (LGPL) (4889 proyectos de 45727, 82,1%)
  14. ^ Kelty, Christpher M. (2008). "The Cultural Significance of free Software - Two Bits" (PDF) . Duke University Press - Durham y Londres. p. 99. Antes de 1998, el término "software libre" hacía referencia a la Free Software Foundation (y al ojo vigilante y microgestor de Stallman) o a uno de los miles de proyectos, procesos, licencias e ideologías comerciales, vocacionales o de investigación universitaria que tenían una variedad de nombres: sourceware, freeware, shareware, software abierto, software de dominio público, etc. El término "código abierto", por el contrario, buscaba abarcarlos a todos en un solo movimiento.
  15. ^ "Netscape anuncia planes para que el código fuente de Next-Generation Communicator esté disponible de forma gratuita en la red". Netscape Communications Corporation . 22 de enero de 1998. Archivado desde el original el 1 de abril de 2007 . Consultado el 8 de agosto de 2013 . Una decisión audaz para aprovechar el poder creativo de miles de desarrolladores de Internet; la empresa hace que Netscape Navigator y Communicator 4.0 sean inmediatamente gratuitos para todos los usuarios, lo que abre el mercado para empresas y centros de red
  16. ^ "MOUNTAIN VIEW, California, 1 de abril /PRNewswire/ -- Netscape Communications y los desarrolladores de código abierto celebran el primer aniversario, el 31 de marzo de 1999, de la publicación del código fuente del navegador de Netscape en mozilla.org". Netscape Communications . 31 de marzo de 1999. Archivado desde el original el 26 de marzo de 2014 . Consultado el 10 de enero de 2013 . ... la organización que gestiona a los desarrolladores de código abierto que trabajan en la próxima generación del navegador y el software de comunicación de Netscape. Este evento marcó un hito histórico para Internet, ya que Netscape se convirtió en la primera gran empresa de software comercial en abrir su código fuente, una tendencia que desde entonces ha sido seguida por varias otras corporaciones. Desde que el código se publicó por primera vez en Internet, miles de personas y organizaciones lo han descargado y han realizado cientos de contribuciones al software. Mozilla.org está celebrando ahora este primer aniversario con una fiesta el jueves por la noche en San Francisco.
  17. ^ Kelty, Christpher M. (2008). "The Cultural Significance of free Software - Two Bits" (PDF) . Duke University Press - Durham y Londres. p. 100. El término Open Source, por el contrario, pretendía abarcarlos a todos en un solo movimiento. El acontecimiento que precipitó este intento de golpe de estado semántico fue la publicación del código fuente del navegador web Communicator de Netscape. Es difícil sobreestimar la importancia de Netscape para la suerte del software libre. […] Pero Netscape es mucho más famoso entre los geeks por regalar algo más, en 1998: el código fuente de Netscape Communicator (antes Navigator).
  18. ^ "Informe del Comité de Proliferación de Licencias y borrador de preguntas frecuentes". Iniciativa de Código Abierto . 12 de diciembre de 2007.
  19. ^ "Groklaw - La orden GPL alemana - Traducida" . Consultado el 19 de marzo de 2015 .
  20. ^ Véase Progress Software Corporation v. MySQL AB , 195 F. Supp. 2d 328 (D. Mass. 2002), sobre la moción del acusado para una medida cautelar.
  21. ^ Lawrence Rosen (25 de mayo de 2004). "Por qué el dominio público no es una licencia". rosenlaw.com . Consultado el 22 de febrero de 2016 .
  22. ^ Bernstein, Daniel J. (2004). "Colocación de documentos en el dominio público". La mayoría de los derechos pueden ser abandonados voluntariamente ("renunciados") por el propietario de los mismos. Los legisladores pueden hacer un esfuerzo adicional para crear derechos que no puedan abandonarse, pero por lo general no lo hacen. En particular, usted puede abandonar voluntariamente sus derechos de autor en los Estados Unidos: "Está bien establecido que los derechos obtenidos en virtud de la Ley de Derechos de Autor pueden abandonarse. Pero el abandono de un derecho debe manifestarse mediante algún acto manifiesto que indique una intención de abandonar ese derecho. Véase Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960)".
  23. ^ Lawrence Rosen (8 de marzo de 2012). "(Licencia-revisión) (Licencia-discusión) CC0 no cumple con OSD sobre patentes, (era: MXM en comparación con CC0)". opensource.org. Archivado desde el original el 12 de marzo de 2016 . Consultado el 22 de febrero de 2016 . El caso al que hace referencia en su correo electrónico, Hampton v. Paramount Pictures, 279 F.2d 100 (9th Cir. Cal. 1960), defiende la proposición de que, al menos en el Noveno Circuito, una persona puede de hecho abandonar sus derechos de autor (en contra de lo que escribí en mi artículo), pero se necesita el equivalente a una licencia manifiesta para hacerlo. :-) ... Para que conste, ya he votado +1 para aprobar la dedicación al dominio público CC0 y la licencia de reserva como compatible con OSD. Reconozco que he argumentado durante años contra el "dominio público" como licencia de código abierto, pero en retrospectiva, considerando el riesgo mínimo para los desarrolladores y usuarios que dependen de ese software y la evidente popularidad de esa "licencia", cambié de opinión. Nadie puede interponerse en el camino de una manguera de software de dominio público gratuito, incluso si no viene con una mejor licencia de FOSS en la que confío más.
  24. ^ Mark (8 de mayo de 2008). "La maldición de la proliferación de licencias de código abierto". socializedsoftware.com. Archivado desde el original el 8 de diciembre de 2015. Consultado el 30 de noviembre de 2015. Actualmente, la decisión de pasar de la GPL v2 a la GPL v3 está siendo objeto de un intenso debate en muchos proyectos de código abierto . Según Palamida, un proveedor de software de cumplimiento de IP, ha habido aproximadamente 2489 proyectos de código abierto que han pasado de la GPLv2 a versiones posteriores.
  25. ^ ab "Preguntas frecuentes sobre las licencias GNU: ¿es compatible la GPLv3 con la GPLv2?". gnu.org . Consultado el 3 de junio de 2014 . No. Algunos de los requisitos de la GPLv3, como el requisito de proporcionar información de instalación, no existen en la GPLv2. Como resultado, las licencias no son compatibles: si intentara combinar código publicado bajo ambas licencias, violaría la sección 6 de la GPLv2. Sin embargo, si el código se publica bajo la GPL 'versión 2 o posterior', es compatible con la GPLv3 porque la GPLv3 es una de las opciones que permite. 
  26. ^ Kerner, Sean Michael (8 de enero de 2008). "Torvalds sigue interesado en la GPLv2". internetnews.com . Consultado el 12 de febrero de 2015 . En cierto modo, Linux fue el proyecto que realmente dejó clara la división entre lo que la FSF está impulsando, que es muy diferente de lo que siempre ha sido el código abierto, y Linux, que es más una superioridad técnica en lugar de una creencia religiosa en la libertad", dijo Torvalds a Zemlin. Por lo tanto, la versión 3 de la GPL refleja los objetivos de la FSF y la versión 2 de la GPL coincide bastante con lo que creo que debería hacer una licencia y, por lo tanto, en este momento, la versión 2 es donde está el núcleo.   
  27. ^ ab Byfield, Bruce (22 de noviembre de 2011). "7 Reasons Why Free Software Is Losing Influence: Page 2". Datamation .com . Consultado el 23 de agosto de 2013 . En su momento, la decisión parecía sensata ante un punto muerto. Pero ahora, la GPLv2 se utiliza para el 42,5% del software libre y la GPLv3 para menos del 6,5%, según Black Duck Software.
  28. ^ "MySQL cambia de licencia para evitar la GPLv3". Computer business review online . 4 de enero de 2007. Archivado desde el original el 6 de febrero de 2007. Consultado el 21 de noviembre de 2016 .
  29. ^ corbet (1 de octubre de 2006). "Busy busy busybox". lwn.net . Consultado el 21 de noviembre de 2015 . Dado que BusyBox se puede encontrar en tantos sistemas integrados, se encuentra en el centro del debate anti-DRM de la GPLv3. […] Los resultados reales, sin embargo, son estos: BusyBox será GPLv2 solamente a partir de la próxima versión. Se acepta generalmente que eliminar el "o cualquier versión posterior" es legalmente defendible, y que la fusión de otro código que sólo sea GPLv2 forzará esa cuestión en cualquier caso.
  30. ^ Landley, Rob (9 de septiembre de 2006). "Re: Move GPLv2 vs v3 fun..." lwn.net . Consultado el 21 de noviembre de 2015 . No inventes un argumento falaz, por favor. Considero que licenciar BusyBox bajo GPLv3 es inútil, innecesario, demasiado complicado y confuso, y además de eso tiene desventajas reales. 1) Inútil: nunca abandonaremos GPLv2.
  31. ^ Prokoudine, Alexandre (26 de enero de 2012). "¿Qué pasa con la adopción de DWG en el software libre?". libregraphicsworld.org. Archivado desde el original el 9 de noviembre de 2016. Consultado el 5 de diciembre de 2015. Blender también sigue siendo "GPLv2 o posterior". Por el momento nos atenemos a eso, pasar a GPL 3 no tiene beneficios evidentes que yo sepa.
  32. ^ Denis-Courmont, Rémi. "VLC media player to remain under GNU GPL version 2". videolan.org . Consultado el 21 de noviembre de 2015 . En 2001, VLC fue lanzado bajo la versión 2 de GNU General Public aprobada por OSI , con la opción comúnmente ofrecida de usar "cualquier versión posterior" de la misma (aunque no había ninguna versión posterior de ese tipo en ese momento). Luego del lanzamiento por parte de la Free Software Foundation (FSF) de la nueva versión 3 de su Licencia Pública General GNU (GPL) el 29 de junio de 2007, los contribuyentes al reproductor multimedia VLC y otros proyectos de software alojados en videolan.org debatieron la posibilidad de actualizar los términos de licencia para futuras versiones del reproductor multimedia VLC y otros proyectos alojados, a la versión 3 de la GPL. ... Existe una gran preocupación de que estos nuevos requisitos adicionales podrían no coincidir con la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Creemos que cambiar los términos de nuestra licencia a la versión 3 de la GPL no sería lo mejor para nuestra comunidad en su conjunto. Por lo tanto, tenemos previsto seguir distribuyendo futuras versiones del reproductor multimedia VLC bajo los términos de la versión 2 de la GPL.     
  33. ^ Asay, Matt (23 de julio de 2009). "GPLv3 alcanza el 50 por ciento de adopción | The Open Road - CNET News". News.cnet.com. Archivado desde el original el 29 de octubre de 2013. Consultado el 2 de septiembre de 2013 .
  34. ^ Proffitt, Brian (16 de diciembre de 2011). «El uso de GPL y copyleft está disminuyendo más rápido que nunca». ITworld . Archivado desde el original el 4 de septiembre de 2017. Consultado el 17 de febrero de 2016 .
  35. ^ Proffitt, Brian (16 de diciembre de 2011). "El uso de GPL y copyleft está disminuyendo más rápido que nunca: los datos sugieren un ritmo de declive más pronunciado, lo que plantea la pregunta: ¿por qué?". IT world. Archivado desde el original el 3 de diciembre de 2013. Consultado el 23 de agosto de 2013 .
  36. ^ Aslett, Matthew (15 de diciembre de 2011). «Sobre el continuo declive de la GPL». Archivado desde el original el 9 de diciembre de 2016. Consultado el 17 de febrero de 2016 .
  37. ^ ab "Top 20 licenses". Black Duck Software. 19 de noviembre de 2015. Archivado desde el original el 19 de julio de 2016. Consultado el 19 de noviembre de 2015. 1. Licencia MIT 24%, 2. Licencia pública general GNU (GPL) 2.0 23%, 3. Licencia Apache 16%, 4. Licencia pública general GNU (GPL) 3.0 9%, 5. Licencia BSD 2.0 (3 cláusulas, nueva o revisada) 6%, 6. Licencia pública general reducida GNU (LGPL) 2.1 5%, 7. Licencia artística (Perl) 4%, 8. Licencia pública general reducida GNU (LGPL) 3.0 2%, 9. Licencia pública Microsoft 2%, 10. Licencia pública Eclipse (EPL) 2%
  38. ^ ab Balter, Ben (9 de marzo de 2015). "Uso de licencias de código abierto en GitHub.com". github.com . Consultado el 21 de noviembre de 2015. 1 MIT 44,69 %, 2 Other 15,68 %, 3 GPLv2 12,96 %, 4 Apache 11,19 %, 5 GPLv3 8,88 %, 6 BSD 3-clause 4,53 %, 7 Unlicense 1,87 %, 8 BSD 2-clause 1,70 %, 9 LGPLv3 1,30 %, 10 AGPLv3 1,05 %
  39. ^ ab Anwesha Das (22 de junio de 2016). "Licencias de software en el ecosistema de Fedora". anweshadas.in . Consultado el 27 de junio de 2016 . Del cuadro anterior se desprende claramente que la familia GPL es la más utilizada (antes había calculado mal que era MIT). Las otras licencias principales son MIT, BSD, la familia LGPL, Artistic (para paquetes Perl), LPPL (para paquetes texlive), ASL.
  40. ^ "Varias licencias y comentarios sobre ellas - Proyecto GNU - Free Software Foundation" . Consultado el 19 de marzo de 2015 .
  41. ^ "Por qué deberías utilizar una licencia estilo BSD para tu proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  42. ^ "Por qué deberías utilizar una licencia estilo BSD para tu proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  43. ^ "GPLv3 - Transcripción de Richard Stallman de la quinta conferencia internacional GPLv3, Tokio, Japón; 2006-11-21" . Consultado el 19 de marzo de 2015 .
  44. ^ "Richard Stallman analiza los cambios en la GPLv3". Un nuevo método para intentar privar de libertad a los usuarios. En términos generales, lo llamamos tivoización.
  45. ^ Wheeler, David A. (27 de septiembre de 2007). "The Free-Libre / Open Source Software (FLOSS) License Slide". Archivado desde el original el 9 de marzo de 2011. Consultado el 28 de noviembre de 2015 .
  46. ^ "Cómo la GPLv3 aborda la proliferación de licencias". Archivado desde el original el 2 de mayo de 2013.
  47. ^ LAURENT, Philippe (24 de septiembre de 2008). «La GPLv3 y los problemas de compatibilidad» (PDF) . European Open Source Lawyers Event 2008. Universidad de Namur , Bélgica. pág. 7. Archivado desde el original (PDF) el 4 de marzo de 2016. Consultado el 30 de mayo de 2015. El copyleft es la principal fuente de problemas de compatibilidad.
  48. ^ Apache Foundation (30 de mayo de 2015). "Compatibilidad con GPL" . Consultado el 30 de mayo de 2015 . Por lo tanto, el software Apache 2 puede incluirse en proyectos GPLv3, porque la licencia GPLv3 acepta nuestro software en trabajos GPLv3. Sin embargo, el software GPLv3 no puede incluirse en proyectos Apache. Las licencias son incompatibles en una sola dirección, y es el resultado de la filosofía de licencias de ASF y la interpretación de la ley de derechos de autor por parte de los autores de GPLv3.
  49. ^ Hanwell, Marcus D. (28 de enero de 2014). "¿Debería utilizar una licencia permisiva? ¿Copyleft? ¿O algo intermedio?". opensource.com . Consultado el 30 de mayo de 2015. Las licencias permisivas simplifican las cosas Una de las razones por las que el mundo empresarial, y cada vez más desarrolladores [...], favorecen las licencias permisivas es la simplicidad de la reutilización. La licencia normalmente solo se refiere al código fuente que está licenciado y no intenta inferir ninguna condición sobre ningún otro componente, y debido a esto no hay necesidad de definir qué constituye un trabajo derivado. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que todas son compatibles.
  50. ^ "Compatibilidad e interoperabilidad de licencias". Software de código abierto: desarrollo, intercambio y reutilización de software de código abierto para administraciones públicas . joinup.ec.europa.eu. Archivado desde el original el 17 de junio de 2015. Consultado el 30 de mayo de 2015. Las licencias para distribuir software libre o de código abierto (FOSS) se dividen en dos familias: permisivas y copyleft. Las licencias permisivas (BSD, MIT, X11, Apache, Zope) son generalmente compatibles e interoperables con la mayoría de las demás licencias, tolerando la fusión, combinación o mejora del código cubierto y su redistribución bajo muchas licencias (incluidas las que no son libres o "propietarias").
  51. ^ Landley, Rob. "CELF 2013 Toybox talk". landley.net . Consultado el 21 de agosto de 2013 . La GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
  52. ^ "Los problemas de HESSLA - Proyecto GNU - Free Software Foundation" . Consultado el 19 de marzo de 2015 .
  53. ^ "GPLv3 - Transcripción de Richard Stallman de la tercera conferencia internacional GPLv3, Barcelona; 2006-06-22" . Consultado el 19 de marzo de 2015 .
  54. ^ "La envidia de la censura y las licencias — Free Software Foundation — Trabajando juntos por el software libre".
  55. ^ "Características distintivas de SQLite".
  56. ^ "Una licencia de código abierto pacífica | Wise Earth Technology".
  57. ^ "Sólo para uso no militar".
  58. ^ "❌(REVERTIDO): Agregar texto a la Licencia MIT que prohíbe a los colaboradores de ICE por jamiebuilds · Solicitud de incorporación de cambios n.° 1616 · lerna/Lerna". GitHub .
  59. ^ "El mal, o por qué Douglas Crockford es perjudicial para el software libre". 8 de noviembre de 2012.
  60. ^ "JSMin no es bienvenido en Google Code - wonko.com". wonko.com . Consultado el 1 de junio de 2024 .
  61. ^ "Proyecto de código abierto añade cláusula de "no uso militar" a la GPL". 14 de agosto de 2006.
  62. ^ "Inicio". commonsclause.com .
  63. ^ "La SSPL no es una licencia de código abierto | Iniciativa de código abierto". 19 de enero de 2021.
  64. ^ "Política de derechos de autor de OpenBSD". la restricción de que el código fuente debe distribuirse o ponerse a disposición para todos los trabajos que son derivados […] Como consecuencia, el software sujeto a los términos de la GPL no puede incluirse en el núcleo o "tiempo de ejecución" de OpenBSD
  65. ^ "FreeBSD der unbekannte Riese" (en alemán). 30 de agosto de 2023.
  66. ^ "Condiciones de uso". El contenido que envíe no debe competir directamente con los productos ofrecidos por MathWorks. El contenido enviado a File Exchange solo puede usarse con productos de MathWorks.
  67. ^ "Preguntas frecuentes sobre la transición de licencias de intercambio de archivos".
  68. ^ "¿Por qué no puedo usar el código de File Exchange en Octave? ¡Está publicado bajo una licencia BSD!".
  69. ^ "¿Libertad o poder? por Bradley Kuhn y Richard Stallman".
  70. ^ "Preguntas frecuentes sobre las licencias GNU: ¿Por qué no se utiliza la GPL para los manuales?" . Consultado el 20 de junio de 2009 .
  71. ^ Braakman, Richard. "Re: Propuesta de declaración con respecto a GNU FDL". Debian-legal (lista de correo).
  72. ^ Srivastava, Manoj (2006). "Borrador de la declaración de posición de Debian sobre la Licencia de Documentación Libre de GNU (nerGFDL)" . Consultado el 25 de septiembre de 2007. No es posible tomar prestado texto de un manual con licencia GFDL e incorporarlo en ningún programa de software libre. No se trata de una mera incompatibilidad de licencias. No se trata sólo de que la GFDL sea incompatible con esta o aquella licencia de software libre: es que es fundamentalmente incompatible con cualquier licencia de software libre. Por lo tanto, si escribe un programa nuevo y no tiene ningún compromiso sobre qué licencia quiere utilizar, salvo que sea una licencia libre, no puede incluir texto con licencia GFDL. La FDL de GNU, tal como está hoy, no cumple con las Directrices de Software Libre de Debian. Hay problemas significativos con la licencia, como se detalla más arriba; y, como tal, no podemos aceptar obras licenciadas bajo la FDL de GNU en nuestra distribución.
  73. ^ Nerode, Nathanael (24 de septiembre de 2003). "Why You Shouldn't Use the GNU FDL". Archivado desde el original el 9 de octubre de 2003. Consultado el 7 de noviembre de 2011 .
  74. ^ Bruce Perens (2 de septiembre de 2003). "interponiéndose entre Debian y la FSF". lists.debian.org/debian-legal . Consultado el 20 de marzo de 2016 . La FSF, una organización de software libre, no es totalmente fiel a la filosofía del software libre mientras promueve una licencia que permite que se apliquen secciones invariables a todo excepto al texto de la licencia y la atribución. La FSF no es Creative Commons: la documentación que maneja la FSF es un componente esencial del software libre de la FSF y debe tratarse como tal. En ese sentido, la GFDL no es coherente con la filosofía que la FSF ha promovido durante 19 años.
  75. ^ "Resolución: Por qué la Licencia de Documentación Libre de GNU no es adecuada para Debian". Proyecto Debian . Febrero-marzo de 2006 . Consultado el 20 de junio de 2009 .
  76. ^ FLOSS Manuals Foundation (6 de junio de 2007). «Cambio de licencia». Blog de FLOSS Manuals . FLOSS Manuals Foundation. Archivado desde el original el 28 de febrero de 2008 . Consultado el 20 de junio de 2009 .
  77. ^ "Transcripción de la intervención de Richard Stallman en la tercera conferencia internacional GPLv3". Free Software Foundation Europe. 22 de junio de 2006. Consultado el 23 de julio de 2017 .
  78. ^ Sam Varghese (7 de febrero de 2012). «El uso de la GPL en Debian va en aumento: estudio». Itwire.com . Consultado el 2 de septiembre de 2013 .
  79. ^ "Estudio de licencias de código abierto". Lwn.net . Consultado el 2 de septiembre de 2013 .

Referencias

Enlaces externos

Wikilibros tiene un libro sobre el tema: Licencias FOSS