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 destinatario 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 (generalmente el autor) de un software puede eliminar estas restricciones acompañando el software con una licencia de software que otorga estos derechos al destinatario. El software que utiliza dicha licencia es software libre (o software gratuito 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 proporcionan mitigación de riesgos contra diferentes amenazas o comportamientos legales que los desarrolladores consideran potencialmente dañinos:

Historia

Antes de la década de 1980

En los primeros tiempos del software, compartir software y código fuente era común en ciertas comunidades, por ejemplo en las instituciones académicas. Antes de que la Comisión estadounidense sobre nuevos usos tecnológicos de obras protegidas por 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 propia de derechos de autor", [3] [4] el software no era considerados protegidos por 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 CONTU, más decisiones judiciales como Apple v. Franklin en 1983 para el código objeto , aclararon que la Ley de Copyright otorgaba a los programas de computadora el estatus de copyright de obras literarias e iniciaba la concesión de licencias de software .

Las licencias de software libre antes de finales de los años 1980 eran generalmente avisos informales escritos por los propios desarrolladores. Estas primeras licencias eran del tipo " permisivas ".

década de 1980

A mediados de la década de 1980, el proyecto GNU produjo licencias de software libre copyleft para cada uno de sus paquetes de software. Una de las primeras licencias de este tipo (el "Aviso de permiso de copia de GNU Emacs") se utilizó para GNU Emacs en 1985, [5] que se revisó como "Licencia pública general de GNU Emacs" a finales de 1985 y se aclaró en marzo de 1987 y febrero de 1988. [6] [7] [8] Asimismo, la Licencia Pública General GCC similar se aplicó a la Colección de Compiladores GNU , que se publicó inicialmente en 1987. [9] [10] La licencia BSD original es también una de las primeras licencias libres. licencias de software, que datan de 1988. En 1989, se publicó la versión  1 de la Licencia Pública General 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]

Década de 1990 a 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 centró la idea del software libre en la percepción pública y empresarial más amplia. [14] En la época de la burbuja de las puntocom , el paso 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 , véase también esta lista ) escribieron sus propias licencias FOSS o adaptaron las licencias existentes. Posteriormente se reconoció que esta proliferación de licencias era un problema para el ecosistema gratuito 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 ralentizó posteriormente, 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 versión  2 de GNU GPL ha sido probada en los tribunales, primero en Alemania en 2004 y luego en Estados Unidos. En el caso alemán, el juez no discutió explícitamente la validez de las cláusulas de la GPL, pero aceptó que debía respetarse la GPL: "Si las partes no acordaran la GPL, el demandado carecería no obstante de los derechos necesarios para copiar, distribuir y hacer que el software 'netfilter/iptables' esté disponible públicamente". Como el demandado no cumplió 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" por la 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, el software no se puede realmente renunciar al dominio público y no se puede interpretar como una licencia de software libre 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 , aunque admitió que, contrariamente a sus afirmaciones anteriores, se puede renunciar a los derechos de autor, respaldado por decisiones del Noveno Circuito . [23]

En 2007, después de años de discusión sobre el borrador, se lanzó la GPLv3 como actualización importante de la GPLv2. El lanzamiento fue controvertido [24] debido al alcance significativamente ampliado de la licencia, que la hacía incompatible con la GPLv2. [25] Varios proyectos importantes de software libre ( kernel de 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 director 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 licencia de software que habían pasado a GPLv3 desde GPLv2 era del 50%, contando el proyectos alojados en Google Code . [33]

década de 2010

En 2011, cuatro años después del lanzamiento de GPLv3, el 6,5% de todos los proyectos con licencia de código abierto eran GPLv3, mientras que el 42,5% seguían siendo GPLv2, según 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 disminuyeron y las licencias permisivas aumentaron, según estadísticas de Black Duck Software. [35] [36]

En 2015, según Black Duck Software [37] y las estadísticas de GitHub , [38] la licencia permisiva MIT destronó a la GPLv2 como licencia de software libre más popular al segundo lugar, mientras que la licencia permisiva Apache ya ocupa el tercer lugar. En junio de 2016, un análisis de los paquetes del Proyecto Fedora reveló como licencias más utilizadas la GPL, MIT, BSD y 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 la Definición de Código Abierto en lugar de la Definición de Software Libre . Considera que el grupo de licencias Permisivas de Software Libre es una implementación de referencia de una licencia de Software Libre. [ cita necesaria ] [ 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 copyleft ( compartir por igual ) 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 copyleft GNU de la FSF .

Condiciones en las licencias de software libre

Existe un debate en curso dentro de la comunidad del software libre sobre la delgada línea entre las restricciones que se pueden aplicar y las que aún se pueden llamar "libres". [ cita necesaria ]

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

Copyleft

Las licencias compartidas de software libre escritas por Richard Stallman a mediados de la década de 1980 fueron pioneras en un concepto conocido como "copyleft". Las siguientes disposiciones sobre copyleft establecieron que cuando se distribuyen versiones modificadas de software libre, deben distribuirse bajo los mismos términos que el software original. De ahí que se les denomine "compartir y compartir por igual " o " quid pro quo ". Esto da como resultado 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 gratuitas.

Los desarrolladores que utilizan código GPL en su producto deben poner el código fuente a disposición de cualquiera cuando comparten o venden el código objeto . En este caso, el código fuente también debe contener los cambios que hayan realizado los desarrolladores. Si se utiliza el código GPL pero no se comparte ni se vende, no es necesario que el código esté disponible y cualquier cambio puede permanecer privado. Esto permite a los desarrolladores y organizaciones utilizar y modificar el 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 tener que poner los cambios a disposición del público.

Los partidarios de la GPL afirman que al exigir que los trabajos derivados permanezcan bajo la GPL, se fomenta el crecimiento del software libre y se requiere la participación igualitaria de todos los usuarios. Quienes se oponen a la GPL afirman [41] que "ninguna licencia puede garantizar la disponibilidad futura del software" y que las desventajas de la GPL superan [42] sus ventajas. Algunos también argumentan que restringir la distribución hace que la licencia sea menos gratuita. 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 trabajo si se publica públicamente, mientras que una licencia 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 en materia de patentes , para proteger contra casos de litigios por patentes de software , un problema que no había existido anteriormente. Esta nueva amenaza fue una de las razones para escribir la versión  3 de GNU GPL en 2006. [43] En los últimos años, el término acuñado tivoización describe un proceso en el que se utilizan restricciones de hardware para impedir que los usuarios ejecuten versiones modificadas del software en ese dispositivo. hardware, en el que el dispositivo TiVo es un ejemplo. La FSF lo ve como una manera de convertir el software libre en no libre, y es por eso que han decidido prohibirlo en la GPLv3 . [44] La mayoría de las nuevas licencias de software libre emitidas desde finales de los años 1990 incluyen algún tipo de cláusulas de represalia por patentes. Estas medidas estipulan que los derechos de una persona bajo la licencia (como los de redistribución) pueden rescindirse si se intenta hacer cumplir las patentes relacionadas con el software licenciado, bajo ciertas circunstancias. Por ejemplo, la Licencia de fuente pública de Apple puede rescindir los derechos de un usuario si dicho usuario se embarca en un litigio contra él debido a un litigio de patentes. Las represalias contra las patentes surgieron en 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 diga que no está modificado. Algunas licencias también requieren que se acredite a los titulares de los derechos de autor. Un ejemplo de ello es  la versión 2 de GNU GPL, que exige que los programas interactivos que imprimen información de garantía o licencia no puedan eliminar estos avisos de las versiones modificadas destinadas a su distribución.

Problemas prácticos con las licencias.

Compatibilidad de licencia

Compatibilidad de licencias entre licencias de software FOSS comunes según David A. Wheeler (2007): las flechas vectoriales indican 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 licencia entre una licencia copyleft y otra licencia es a menudo una compatibilidad unidireccional. [47] Esta característica de "compatibilidad unidireccional" es, por ejemplo, criticada por la Fundación Apache , que proporciona la licencia Apache más permisiva que no tiene esta característica. [48] ​​Las licencias sin copyleft, como las licencias permisivas de FOSS , tienen una interacción de licencia menos complicada y normalmente exhiben una mejor compatibilidad de licencia. [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 combinó un paquete de software que utiliza una licencia con un paquete de software que utiliza la otra, sería imposible distribuir la combinación porque estos requisitos contradictorios no pueden cumplirse simultáneamente. Por lo tanto, estos dos paquetes serían incompatibles en cuanto a licencia. Cuando se trata de licencias de software copyleft , no son inherentemente compatibles con otras licencias copyleft, incluso la GPLv2 es, por sí sola, no compatible con la GPLv3. [25] [51]

Propósito de uso

Las restricciones en el uso de un software ("restricciones de uso") son generalmente inaceptables según las distribuciones basadas en FSF, OSI , Debian o BSD. Los ejemplos incluyen la prohibición de que el software se utilice para aplicaciones no privadas, con fines militares, para comparación o evaluación comparativa, para un buen uso, [ se necesita aclaración ] para medios éticamente cuestionables, [52] o en organizaciones comerciales. [53] Si bien algunas restricciones a la libertad del usuario, por ejemplo las relativas a la guerra nuclear, parecen gozar de apoyo moral entre la mayoría de los desarrolladores de software libre, [54] en general se cree que tales agendas no deberían cumplirse a través de licencias de software; entre otras cosas, debido a aspectos prácticos como las consiguientes incertidumbres jurídicas y 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 declaraciones legalmente no vinculantes para el usuario, en particular SQLite . [55] Entre los repetidos intentos [56] [57] [58] por parte de los desarrolladores de regular el comportamiento del usuario a través de la licencia que provocaron un debate más amplio se encuentran la cláusula (en broma) de Douglas Crockford de “no maldad”, que afectó el proceso de lanzamiento de la licencia. distribución Debian en 2012 [59] y la expulsión del proyecto JSMin-PHP de Google Code , [60] la adición de una condición pacifista basada en la Primera Ley de la 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 existen varias organizaciones y grupos que publican definiciones y directrices sobre las licencias de FOSS, en particular la FSF, la OSI, el proyecto Debian y los BSD, a veces existen opiniones e interpretaciones contradictorias.

Opiniones permisivas versus copyleft

Muchos usuarios y desarrolladores de sistemas operativos basados ​​en BSD tienen una postura diferente respecto a las licencias. La principal diferencia es la creencia de que las licencias copyleft , particularmente 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 hace. Básicamente, 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 sólo 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 relicencia con BSD u otras licencias permisivas podrían impedir un mayor uso 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 condiciones 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 gratuita que la GPL porque otorga el derecho de hacer cualquier cosa con el código fuente, siempre que se conserve la atribución. Este enfoque ha llevado al uso del código BSD en software propietario ampliamente utilizado. Los defensores de la GPL señalan que una vez que el código se vuelve propietario, a los usuarios se les niegan las libertades que definen el software libre. [69] Como resultado, consideran que la licencia BSD es menos libre que la GPL, y 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 contribuir 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 la Licencia Artística y la Licencia de Documentación Libre GNU (GFDL). Debian acepta la Licencia Artística original como una 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 usa en una configuración de licencia dual , junto con la Licencia Pública General GNU .

Casos límite controvertidos

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

Ejemplos de licencias que provocaron debate fueron la serie 1.x de la Licencia de Fuente Pública de Apple , que fueron aceptadas por la Open Source Initiative pero no por la Free Software Foundation o Debian y la Licencia de Fuente Pública RealNetworks , que fue aceptada por la Open Source Initiative. 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 sostiene que la documentación es cualitativamente diferente del software y está sujeta a requisitos diferentes. Debian aceptó, en una resolución posterior, que GNU FDL cumplió con las Directrices de software libre de Debian cuando se eliminó la controvertida "sección invariante", pero considera que "todavía no está libre de problemas". [75] No obstante, la mayor parte de la documentación GNU incluye "secciones invariantes". De manera similar, la fundación FLOSS Manuals , una organización dedicada a la creación de manuales para software libre, decidió en 2007 prescindir de 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 en el caso de la documentación digital. [76]

SLUC es una licencia de software publicada en España en diciembre de 2006 para permitir todo uso excepto militar. Los redactores 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 utilizar 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 al segundo lugar mientras que la licencia permisiva Apache le sigue en tercer lugar. Un estudio de 2012, que utilizó datos disponibles públicamente, criticó a Black Duck Software por no publicar la metodología utilizada en la recopilación de 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 encontró 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ó como licencias más utilizadas la familia GPL, seguida por 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]

Ver 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 los derechos de autor no se aplicaran 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. contra Franklin Computer Corporation devuelve el byte a la protección de derechos de autor para 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. Derecho del software y de Internet , pág. 34.
  5. ^ "Aviso de permiso 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; 22 de junio de 2006 - FSFE" . Consultado el 15 de julio de 2021 .
  7. ^ Rubin, Paul (12 de diciembre de 1985). "Montgomery EMACS: ¿cuándo dejó el dominio público?". Grupo de noticias : net.emacs. Este último está cubierto por la Licencia Pública General GNU Emacs, que dice que las fuentes de cualquier cosa que lo utilice deben estar disponibles de forma gratuita para todos.
  8. ^ "Software libre: cumplimiento de la GPL". Información privilegiada sobre tecnología . Consultado el 1 de mayo de 2015 .
  9. ^ "Publicaciones 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; 21 de abril de 2006". Fsfe - Fundación para el Software Libre Europa . 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 GNU (GPL) 2,0 58,69 % Licencia pública general reducida (LGPL) GNU 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 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: mapa de software". 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), Biblioteca GNU o Licencia Pública General Reducida (LGPL) (4889 proyectos de 45727, 82,1%)
  14. ^ Kelty, Christpher M. (2008). "La importancia cultural del software libre: dos bits" (PDF) . Prensa de la Universidad de Duke - Durham y Londres. pag. 99. Antes de 1998, el Software Libre se refería ya sea a la Free Software Foundation (y al ojo vigilante y microadministrador de Stallman) o a uno de los miles de diferentes proyectos, procesos, licencias e ideologías comerciales, vocacionales o de investigación universitaria que habían una variedad de nombres: sourceware, freeware, shareware, software abierto, software de dominio público, etc. El término Open Source, por el contrario, buscaba abarcarlos a todos en un solo movimiento.
  15. ^ "Netscape anuncia planes para hacer que el código fuente del comunicador de próxima generación esté disponible de forma gratuita en la red". Corporación de Comunicaciones Netscape . 22 de enero de 1998. Archivado desde el original el 1 de abril de 2007 . Consultado el 8 de agosto de 2013 . Una medida audaz para aprovechar el poder creativo de miles de desarrolladores de Internet; La compañía hace que Netscape Navigator y Communicator 4.0 sean inmediatamente gratuitos para todos los usuarios, generando mercado para empresas y negocios netcenter.
  16. ^ "MOUNTAIN VIEW, California, 1 de abril /PRNewswire/ -- Netscape Communications y los desarrolladores de código abierto están celebrando el primer aniversario, el 31 de marzo de 1999, del lanzamiento del código fuente del navegador Netscape en mozilla.org". Comunicaciones Netscape . 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 los desarrolladores de código abierto que trabajan en la próxima generación del software de comunicación y navegador 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 han seguido varias otras corporaciones. Desde que el código se publicó por primera vez en Internet, miles de personas y organizaciones lo descargaron y realizaron cientos de contribuciones al software. Mozilla.org celebra ahora este primer aniversario con una fiesta el jueves por la noche en San Francisco.
  17. ^ Kelty, Christpher M. (2008). "La importancia cultural del software libre: dos bits" (PDF) . Prensa de la Universidad de Duke - Durham y Londres. pag. 100. El término Código Abierto, por el contrario, pretendía abarcarlos a todos en un solo movimiento. El evento 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 (de soltera 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 - Traducido" . Consultado el 19 de marzo de 2015 .
  20. ^ Véase Progress Software Corporation contra MySQL AB , 195 F. Supp. 2d 328 (D. Mass. 2002), sobre la moción del demandado de orden judicial preliminar.
  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 ("renunciados") voluntariamente por el propietario de los mismos. Los legisladores pueden hacer un esfuerzo adicional para crear derechos que no puedan abandonarse, pero normalmente no lo hacen. En particular, puede abandonar voluntariamente sus derechos de autor en los Estados Unidos: "Está bien establecido que los derechos adquiridos 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 la intención de abandonar ese derecho. Véase Hampton contra Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960)".
  23. ^ Lawrence Rosen (8 de marzo de 2012). "(Revisión de licencia) (Discusión de licencia) CC0 no cumple con OSD en 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 hizo 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 efectivamente abandonar sus derechos de autor (contra a lo que escribí en mi artículo), pero se necesita el equivalente a una licencia manifiesta para hacerlo. :-) ... Para que conste, ya voté +1 para aprobar la dedicación de dominio público CC0 y la licencia alternativa como compatible con OSD. Admito que he argumentado durante años en contra del "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 dicho software y la evidente popularidad de esa "licencia", cambié de opinión. . Uno no puede interponerse en el camino de una manguera contra incendios de software gratuito de dominio público, incluso si no viene con una mejor licencia 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, muchos proyectos de código abierto están debatiendo acaloradamente la decisión de pasar de GPL v2 a GPL v3. Según Palamida, un proveedor de software de cumplimiento de IP, ha habido aproximadamente 2489 proyectos de código abierto que han pasado de GPLv2 a versiones posteriores.
  25. ^ ab "Preguntas frecuentes sobre las licencias GNU: ¿GPLv3 es compatible con GPLv2?". gnu.org . Consultado el 3 de junio de 2014 . No. Algunos de los requisitos de GPLv3, como el requisito de proporcionar información de instalación, no existen en GPLv2. Como resultado, las licencias no son compatibles: si intentara combinar el código publicado bajo ambas licencias, violaría la sección 6 de GPLv2. Sin embargo, si el código se publica bajo la 'versión 2 o posterior' de GPL, eso es compatible con GPLv3 porque GPLv3 es una de las opciones que permite. 
  26. ^ Kerner, Sean Michael (8 de enero de 2008). "Torvalds todavía está 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 impulsa la FSF, que es muy diferente de lo que siempre ha sido el código abierto y Linux, que es más una superioridad técnica que una creencia religiosa. en libertad", dijo Torvalds a Zemlin. Entonces, la GPL Versión 3 refleja los objetivos de la FSF y la GPL Versión 2 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). "Siete razones por las que el software libre está perdiendo influencia: página 2". Datamación.com . _ Consultado el 23 de agosto de 2013 . En aquel momento, la decisión parecía sensata ante un punto muerto. Pero ahora, GPLv2 se utiliza para el 42,5% del software libre y GPLv3 para menos del 6,5%, según Black Duck Software.
  28. ^ "MySQL cambia de licencia para evitar GPLv3". Revisión de negocios informáticos en línea . 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). "Ocupado, ocupado, ocupado". 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 GPLv3. […] Los resultados reales, sin embargo, son los siguientes: BusyBox será GPLv2 sólo a partir de la próxima versión. En general, se acepta que eliminar "o cualquier versión posterior" es legalmente defendible, y que la combinación de otro código exclusivo de GPLv2 forzará esa cuestión en cualquier caso.
  30. ^ Landley, Rob (9 de septiembre de 2006). "Re: Mover la diversión GPLv2 vs v3..." lwn.net . Consultado el 21 de noviembre de 2015 . No inventes un argumento de hombre de paja, por favor. Considero que licenciar BusyBox bajo GPLv3 es inútil, innecesario, demasiado complicado y confuso, y además tiene desventajas reales. 1) Inútil: nunca abandonaremos la 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. "El reproductor multimedia VLC permanecerá bajo GNU GPL versión 2". videolan.org . Consultado el 21 de noviembre de 2015 . En 2001, VLC se lanzó 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" del mismo (aunque no existía ninguna versión posterior en ese momento). Tras el 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 no se correspondan con la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Creemos que cambiar nuestros términos de licencia a la versión 3 de GPL actualmente no sería lo mejor para nuestra comunidad en su conjunto. En consecuencia, planeamos seguir distribuyendo versiones futuras del reproductor multimedia VLC bajo los términos de la versión 2 de GPL.     
  33. ^ Asay, Matt (23 de julio de 2009). "GPLv3 alcanza una adopción del 50 por ciento | The Open Road - CNET News". Noticias.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". Mundo de TI .
  35. ^ Proffitt, Brian (16 de diciembre de 2011). "El uso de GPL y copyleft disminuye más rápido que nunca: los datos sugieren una tasa de disminución más pronunciada, lo que plantea la pregunta: ¿por qué?". Mundo TI . 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 "Las 20 licencias principales". Software del pato negro. 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) Licencia 6%, 6. Licencia pública general reducida (LGPL) de GNU 2,1 5%, 7. Licencia pública general reducida (Perl) 4%, 8. Licencia pública general reducida de GNU (LGPL) 3,0 2%, 9. Pública de Microsoft Licencia 2%, 10. Licencia Pública Eclipse (EPL) 2%
  38. ^ ab Balter, Ben (9 de marzo de 2015). "Uso de licencia de código abierto en GitHub.com". github.com . Consultado el 21 de noviembre de 2015 . 1 MIT 44,69%, 2 Otros 15,68%, 3 GPLv2 12,96%, 4 Apache 11,19%, 5 GPLv3 8,88%, 6 BSD 3 cláusulas 4,53%, 7 Sin licencia 1,87%, 8 BSD 2 cláusulas 1,70%, 9 LGPLv3 1,30% , 10AGPLv3 1,05%
  39. ^ ab Anwesha Das (22 de junio de 2016). "Licencias de software en el ecosistema Fedora". anweshadas.in . Consultado el 27 de junio de 2016 . En el cuadro anterior queda claro que la familia GPL es la más utilizada (antes la había calculado mal como MIT). Las otras licencias principales son MIT, BSD, la familia LGPL, Artistic (para paquetes Perl), LPPL (enemigo de los 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ía utilizar una licencia estilo BSD para su proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  42. ^ "Por qué debería utilizar una licencia estilo BSD para su 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; 21 de noviembre de 2006" . Consultado el 19 de marzo de 2015 .
  44. ^ "Richard Stallman analiza los cambios en GPLv3". un nuevo método para intentar privar de libertad a los usuarios. En términos generales nos referimos a esto como tivoización.
  45. ^ Wheeler, David A. (27 de septiembre de 2007). "La diapositiva de licencia de software libre/de código abierto (FLOSS)". Archivado desde el original el 9 de marzo de 2011 . Consultado el 28 de noviembre de 2015 .
  46. ^ "Cómo aborda GPLv3 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) . Evento Europeo de Abogados de Código Abierto 2008 . Universidad de Namur – Bélgica. pag. 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. ^ Fundación Apache (30 de mayo de 2015). "Compatibilidad GPL" . Consultado el 30 de mayo de 2015 . Por lo tanto, el software Apache 2 se puede incluir en proyectos GPLv3, porque la licencia GPLv3 acepta nuestro software en trabajos GPLv3. Sin embargo, el software GPLv3 no se puede incluir en proyectos Apache. Las licencias son incompatibles en una sola dirección, y es el resultado de la filosofía de concesión de licencias de ASF y la interpretación de la ley de derechos de autor de los autores de la 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. Por lo general, la licencia solo se refiere al código fuente bajo licencia y no intenta inferir ninguna condición sobre ningún otro componente, por lo que no es necesario definir qué constituye un trabajo derivado. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que son todos compatibles.
  50. ^ "Compatibilidad e interoperabilidad de licencias". Software de código abierto: desarrolle, comparta y reutilice software de código abierto para las 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 fusionar, combinar o mejorar el código cubierto y redistribuirlo bajo muchas licencias (incluidas las no libres o las propietarias). ').
  51. ^ Landley, Rob. "Charla Toybox CELF 2013". landley.net . Consultado el 21 de agosto de 2013 . GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
  52. ^ "Los problemas de HESSLA - Proyecto GNU - Fundación de Software Libre" . Consultado el 19 de marzo de 2015 .
  53. ^ "GPLv3 - Transcripción de Richard Stallman de la tercera conferencia internacional GPLv3, Barcelona; 22 de junio de 2006" . Consultado el 19 de marzo de 2015 .
  54. ^ "Censura, envidia y licencias - Free Software Foundation - Trabajando juntos por el software libre".
  55. ^ "Características distintivas de SQLite".
  56. ^ "Una licencia pacífica de código abierto | Wise Earth Technology".
  57. ^ "Únicamente para uso no militar".
  58. ^ "❌(REVERTIDO): Agregar texto a la licencia MIT que prohíbe a los colaboradores de ICE por jamiebuilds · Solicitud de extracción 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. ^ https://wonko.com/post/jsmin-isnt-welcome-on-google-code [ URL básica ]
  61. ^ "El proyecto de código abierto agrega una cláusula de" no uso militar "a la GPL". 14 de agosto de 2006.
  62. ^ "Inicio". commonsclause.com .
  63. ^ "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 de todos los trabajos que sean 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. ^ "términos de uso". El contenido que envíe no debe competir directamente con los productos ofrecidos por MathWorks. El contenido enviado a File Exchange solo se puede utilizar con productos 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? ¡Se publica bajo una licencia BSD!".
  69. ^ "¿Libertad o poder? Por Bradley Kuhn y Richard Stallman".
  70. ^ "Preguntas frecuentes sobre las licencias GNU: ¿Por qué no utiliza la GPL para los manuales?" . Consultado el 20 de junio de 2009 .
  71. ^ Braakman, Richard. "Re: Declaración propuesta sobre GNU FDL". Debian-legal (lista de correo).
  72. ^ Srivastava, Manoj (2006). "Borrador de declaración de posición de Debian sobre la licencia de documentación libre GNU (nerGFDL)" . Consultado el 25 de septiembre de 2007 . No es posible tomar prestado texto de un manual GFDL e incorporarlo en ningún programa de software gratuito. No se trata de una mera incompatibilidad de licencia. No se trata sólo de que la GFDL sea incompatible con tal o cual licencia de software libre: es que es fundamentalmente incompatible con cualquier licencia de software libre. Entonces, si escribe un programa nuevo y no tiene ningún compromiso sobre qué licencia desea usar, salvo que sea una licencia gratuita, no puede incluir texto GFDL. GNU FDL, tal como está hoy, no cumple con las Directrices de software libre de Debian. Existen problemas importantes con la licencia, como se detalla anteriormente; y, como tal, no podemos aceptar obras bajo licencia GNU FDL en nuestra distribución.
  73. ^ Nerode, Nathanael (24 de septiembre de 2003). "Por qué no debería utilizar 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). "interviniendo entre Debian y FSF". listas.debian.org/debian-legal . Consultado el 20 de marzo de 2016 . La FSF, una organización de Software Libre, no está siendo del todo fiel al espíritu del Software Libre mientras promueve una licencia que permite aplicar secciones invariantes a cualquier cosa menos al texto de la licencia y la atribución. FSF no es Creative Commons: la documentación que maneja FSF es un componente esencial del Software Libre de FSF, y debe ser tratada como tal. En ese sentido, la GFDL no es consistente con el espíritu que la FSF ha promovido durante 19 años.
  75. ^ "Resolución: Por qué la licencia de documentación libre GNU no es adecuada para Debian". Proyecto Debian . Febrero-marzo de 2006 . Consultado el 20 de junio de 2009 .
  76. ^ Fundación FLOSS Manuals (6 de junio de 2007). "Cambio de licencia". Blog de manuales de FLOSS . Fundación de manuales FLOSS. Archivado desde el original el 28 de febrero de 2008 . Consultado el 20 de junio de 2009 .
  77. ^ "Transcripción de Richard Stallman en la tercera conferencia internacional GPLv3". Fundación de Software Libre Europa. 22 de junio de 2006 . Consultado el 23 de julio de 2017 .
  78. ^ Sam Varghese (7 de febrero de 2012). "El uso de 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