Hispanopedia Wiki
Articulo de referencia

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 ...

Hispanopedia WikiContenido en espanolLectura gratuita

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 programa informático amplios derechos para modificarlo y redistribuirlo . Estas acciones suelen estar prohibidas por la ley de derechos de autor , pero el titular de los derechos (generalmente el autor) de un programa informático puede eliminar estas restricciones al acompañar el programa con una licencia que otorgue dichos derechos al destinatario. El software que utiliza dicha licencia es software libre (o software libre y de código abierto ) según lo conferido por el titular de los derechos de autor. Las licencias de software libre se aplican al software tanto en código fuente como en código objeto binario , ya que la ley de derechos de autor reconoce ambas formas. [ 2 ]

Comparación

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

Historia

Antes de la década de 1980

En los inicios del software, el intercambio de software y código fuente era común en ciertas comunidades, por ejemplo, en instituciones académicas. Antes de que la Comisión de Estados Unidos 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 susceptible de protección por derechos de autor", [ 4 ] [ 5 ] el software no se consideraba protegible 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, junto con decisiones judiciales como Apple v. Franklin en 1983 para el código objeto , aclaró que la Ley de Derechos de Autor otorgaba a los programas informáticos el estatus de obras literarias protegidas por derechos de autor y dio inicio a la concesión de licencias de software .

Las licencias de software libre anteriores a finales de la década de 1980 eran generalmente avisos informales escritos por los propios desarrolladores. Estas primeras licencias eran de carácter " permisivo ".

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, [ 6 ] que se revisó a la "Licencia Pública General de GNU Emacs" a finales de 1985, y se aclaró en marzo de 1987 y febrero de 1988. [ 7 ] [ 8 ] [ 9 ] De igual modo, la similar Licencia Pública General GCC se aplicó a la Colección de Compiladores GNU , que se publicó inicialmente en 1987. [ 10 ] [ 11 ] La licencia BSD original también es 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, publicada en 1991, se convirtió en la licencia de software libre más utilizada. [ 12 ] [ 13 ] [ 14 ]

Década de 1990 a década de 2000

Starting in the mid-1990s and until the mid-2000s, the open-source movement pushed and focused the free-software idea forward in the wider public and business perception.[15] In the Dot-com bubble time, Netscape Communications' step to release its webbrowser under a FOSS license in 1998,[16][17] inspired many other companies to adapt to the FOSS ecosystem.[18] In this trend companies and new projects (Mozilla, Apache foundation, and Sun, see also this list) wrote their own FOSS licenses, or adapted existing licenses. This License proliferation was later recognized as problem for the Free and open-source ecosystem due to the increased complexity of license compatibility considerations.[19] While the creation of new licenses slowed down later, license proliferation and its impact are considered an ongoing serious challenge for the free and open-source ecosystem.

From the free-software licenses, the GNU GPL version 2 has been tested in to court, first in Germany in 2004 and later in the US. In the German case the judge did not explicitly discuss the validity of the GPL's clauses but accepted that the GPL had to be adhered to: "If the GPL were not agreed upon by the parties, defendant would notwithstanding lack the necessary rights to copy, distribute, and make the software 'netfilter/iptables' publicly available." Because the defendant did not comply with the GPL, it had to cease use of the software.[20] The US case (MySQL vs Progress) was settled before a verdict was arrived at, but at an initial hearing, Judge Saris "saw no reason" that the GPL would not be enforceable.[21]

Around 2004, lawyer Lawrence Rosen argued in the essay Why the public domain isn't a license that software could not truly be waived into public domain and can't be interpreted as very permissive FOSS license,[22] a position which faced opposition by Daniel J. Bernstein and others.[23] In 2012, Rosen accepted the CC0 as open source license and conceded that copyright can be waived away, backed by Ninth circuit decisions.[24]

En 2007, tras años de debate sobre el borrador, se publicó la GPLv3 como una actualización importante de la GPLv2. El lanzamiento fue controvertido [ 25 ] debido al alcance significativamente ampliado de la licencia, que la hacía incompatible con la GPLv2. [ 26 ] Varios proyectos importantes de software libre ( núcleo de Linux , [ 27 ] [ 28 ] MySQL , [ 29 ] BusyBox , [ 30 ] [ 31 ] Blender , [ 32 ] reproductor multimedia VLC [ 33 ] ) 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 software de código abierto que habían migrado a la GPLv3 desde la GPLv2 era del 50%, contando los proyectos alojados en Google Code . [ 34 ]

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 % seguían siendo GPLv2, según datos de Black Duck Software. [ 28 ] [ 35 ] Posteriormente, en 2011, el analista de 451 Group, Matthew Aslett, argumentó en una publicación de blog que las licencias copyleft habían disminuido y las licencias permisivas habían aumentado, basándose en estadísticas de Black Duck Software. [ 36 ] [ 37 ]

En 2015, según Black Duck Software [ 38 ] y las estadísticas de GitHub [ 39 ] , la permisiva licencia MIT destronó a la GPLv2 como la licencia de software libre más popular, relegándola al segundo lugar, mientras que la permisiva licencia Apache la seguía en 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, la MIT, la BSD y la LGPL [ 40 ] .

Definiciones

Licencias de código abierto aprobadas por la OSI

El grupo Open Source Initiative (OSI) define y mantiene una lista de licencias de código abierto aprobadas . OSI coincide con la FSF en todas las licencias de software libre de uso generalizado, pero difiere de la lista de la FSF, ya que aprueba las licencias 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. 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. [ 41 ]

La Free Software Foundation prefiere las licencias de software libre copyleft ( compartir por igual ) en lugar de las licencias permisivas para la mayoría de los casos. Su lista distingue entre licencias de software libre compatibles e incompatibles con la Licencia Pública General GNU copyleft de la FSF .

Condiciones en las licencias de software libre

Existe un debate constante dentro de la comunidad del software libre sobre la delgada línea que separa las restricciones que se pueden aplicar sin dejar de considerarse "libre".

Solo el software de dominio público y el software bajo una licencia similar al dominio público están libres de restricciones. Ejemplos de licencias similares al dominio público son, por ejemplo, la WTFPL y la licencia CC0 . Las licencias permisivas pueden conllevar obligaciones menores, como la atribución del autor, pero permiten prácticamente cualquier uso del código. Ciertas licencias, en particular las licencias copyleft , incluyen restricciones intencionadamente más estrictas (especialmente para la distribución/distribuidor) con el fin de obligar a los proyectos derivados a garantizar derechos específicos que no se pueden revocar.

Copyleft

Las licencias de software libre "compartir por igual" escritas por Richard Stallman a mediados de la década de 1980 fueron pioneras en el concepto conocido como "copyleft". Las disposiciones 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 lo tanto, se las denomina "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 otorguen la libertad de modificar el código, se trata de "software libre". Las licencias que no son 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 del público cuando comparten o venden el código objeto . En este caso, el código fuente también debe incluir cualquier modificación que hayan realizado. Si se utiliza código GPL pero no se comparte ni se vende, no es necesario ponerlo a disposición del público y las modificaciones pueden permanecer privadas. Esto permite a los desarrolladores y organizaciones usar y modificar código GPL para fines privados (es decir, cuando el código o el proyecto no se venden ni se comparten de ninguna otra forma) sin la obligación de hacer públicas sus modificaciones.

Los defensores de la GPL afirman que, al exigir que las obras derivadas permanezcan bajo la GPL, fomenta el crecimiento del software libre y requiere la participación equitativa de todos los usuarios. Los opositores de la GPL afirman [ 42 ] que "ninguna licencia puede garantizar la disponibilidad futura del software" y que las desventajas de la GPL superan [ 43 ] sus ventajas. Algunos también argumentan 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 que no sea copyleft no otorga al autor la libertad de ver versiones modificadas de su obra 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 represalia por patentes , para protegerse contra los 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 GNU GPL en 2006. [ 44 ] En los últimos años, se acuñó el término tivoización para describir un proceso en el que se utilizan restricciones de hardware para impedir que los usuarios ejecuten versiones modificadas del software en ese hardware, siendo el dispositivo TiVo un ejemplo. La FSF lo considera una forma de convertir el software libre en software efectivamente no libre, y es por eso que han optado por prohibirlo en la GPLv3 . [ 45 ] La mayoría de las licencias de software libre escritas recientemente desde finales de la década de 1990 incluyen algún tipo de cláusula de represalia por patentes. Estas medidas estipulan que los derechos de una persona bajo la licencia (como la redistribución) pueden terminarse si se intenta hacer valer las patentes relacionadas con el software licenciado, bajo ciertas circunstancias. Por ejemplo, la Licencia de Código Público de Apple puede rescindir los derechos de un usuario si este inicia un proceso judicial en su contra debido a litigios 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 se presente como original. Algunas licencias también requieren que se reconozca la autoría de los derechos de autor. Un ejemplo de ello es la versión  2 de la GNU GPL, que exige que los programas interactivos que imprimen información sobre la garantía o la licencia no eliminen estos avisos de las versiones modificadas destinadas a la distribución.

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 indican una compatibilidad unidireccional, por lo tanto, mejor compatibilidad en el lado izquierdo ("licencias permisivas") que en el lado derecho ("licencias copyleft"). [ 46 ]

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. [ 47 ] La compatibilidad de licencias entre una licencia copyleft y otra licencia suele ser solo una compatibilidad unidireccional. [ 48 ] Esta característica de "compatibilidad unidireccional" es criticada, por ejemplo, por la Fundación Apache , que proporciona la licencia Apache más permisiva que no tiene esta característica. [ 49 ] Las licencias que no son copyleft, como las licencias permisivas FOSS , tienen una interacción de licencias menos complicada y normalmente exhiben una mejor compatibilidad de licencias. [ 50 ] [ 51 ] 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. [ 26 ] [ 52 ]

Finalidad de uso

Las restricciones en el uso de un software ("restricciones de uso") son generalmente inaceptables según la FSF, OSI , Debian o las distribuciones basadas en BSD. Ejemplos incluyen la prohibición de que el software se utilice para aplicaciones no privadas, para fines militares, para comparación o evaluación comparativa, para un buen uso, para medios éticamente cuestionables, [ 53 ] o en organizaciones comerciales. [ 54 ] Si bien algunas restricciones a la libertad del usuario, por ejemplo, en relación con la guerra nuclear, parecen gozar de apoyo moral entre la mayoría de los desarrolladores de software libre, [ 55 ] generalmente se cree que tales agendas no deberían servir 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 creadores de herramientas generalmente no son responsables del uso que otras personas hagan de sus herramientas. Sin embargo, algunos proyectos incluyen peticiones legalmente no vinculantes para el usuario, prominentemente SQLite . [ 56 ] Entre los repetidos intentos [ 57 ] [ 58 ] [ 59 ] 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 (en tono de broma) de Douglas Crockford de "no hacer el mal", que afectó el proceso de lanzamiento de la distribución Debian en 2012 [ 60 ] y provocó la expulsión del proyecto JSMin-PHP de Google Code , [ 61 ] 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, [ 62 ] así como varios proyectos de software que intentaban excluir el uso por parte de grandes proveedores de la nube. [ 63 ] [ 64 ]

Conflictos de definición

Dado que existen varias organizaciones y grupos que publican definiciones y directrices sobre las licencias FOSS, en particular la FSF, la OSI, el proyecto Debian y las BSD, a veces surgen opiniones e interpretaciones contradictorias.

Opiniones sobre el copyleft y el permiso

Muchos usuarios y desarrolladores de sistemas operativos basados ​​en BSD tienen una postura diferente respecto a las licencias. La principal diferencia radica en la creencia de que las licencias copyleft , en particular la Licencia Pública General de GNU (GPL), son excesivamente complicadas y/o restrictivas. [ 65 ] La GPL exige que cualquier obra derivada se publique también bajo la GPL, mientras que la licencia BSD no. En esencia, 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 puede usarse en software propietario que solo reconoce a los autores. Por ejemplo, Microsoft Windows NT 3.1 y macOS tienen pilas de propiedad intelectual propietarias que se derivan de software con licencia BSD. [ 66 ] En casos extremos, las posibilidades de sublicencias o relicencias con BSD u otras licencias permisivas podrían impedir su 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 fuera de su propio software propietario MATLAB , por ejemplo, con el software FOSS GNU Octave . [ 67 ] [ 68 ] [ 69 ]

Los defensores de la licencia BSD argumentan que es más libre que la GPL porque otorga el derecho a hacer cualquier cosa con el código fuente, siempre que se conserve la atribución. Este enfoque ha llevado a que el código BSD se utilice en software propietario de amplia difusión. Los defensores de la GPL señalan que, una vez que el código se vuelve propietario, se les niegan a los usuarios las libertades que definen el software libre. [ 70 ] En consecuencia, consideran que la licencia BSD es menos libre que la GPL, y que la libertad es más que la simple ausencia de restricciones. Dado que la licencia BSD restringe el derecho de los desarrolladores a que sus cambios se reincorporen a la comunidad, ni esta ni la GPL son «libres» en el sentido de «no tener 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 discrepan son la Licencia Artística y la Licencia de Documentación Libre de 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 poca repercusión, ya que la Licencia Artística casi siempre se utiliza en un sistema de doble licencia , junto con la Licencia Pública General de 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 ciertas otras licencias cumplen o no con la definición.

Ejemplos de licencias que suscitaron debate fueron la serie 1.x de la Licencia Pública de Código Fuente de Apple , que fue aceptada por la Open Source Initiative pero no por la Free Software Foundation ni por Debian, y la Licencia Pública de Código Fuente de 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 de GNU , [ 71 ] que es incompatible con la GPL, [ 72 ] fue considerada "no libre" por el proyecto Debian alrededor de 2006, [ 73 ] Nathanael Nerode, [ 74 ] y Bruce Perens . [ 75 ] La FSF argumenta que la documentación es cualitativamente diferente del software y está sujeta a requisitos diferentes. 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 la considera "todavía no exenta de problemas". [ 76 ] 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 la creación de manuales para software libre, decidió en 2007 prescindir de la GFDL y adoptar la GPL para sus textos, alegando la incompatibilidad entre ambas, las dificultades para implementar la GFDL y el hecho de que esta "no permite una fácil duplicación y modificación", especialmente en el caso de la documentación digital. [ 77 ]

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

Cuota de mercado

Si bien históricamente la licencia FOSS más utilizada ha sido la GPLv2, en 2015, según Black Duck Software [ 38 ], la permisiva licencia MIT destronó a la GPLv2 al segundo lugar, mientras que la permisiva licencia Apache ocupa el tercer lugar. Un estudio de 2012, que utilizó datos disponibles públicamente, criticó a Black Duck Software por no publicar la metodología utilizada para recopilar estadísticas. [ 79 ] 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 pudo replicar el resultado de Black Duck Software. [ 80 ]

Un estudio de GitHub de 2015 sobre sus datos estadísticos encontró que la licencia MIT era la licencia FOSS más prominente en esa plataforma. [ 39 ]

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 TeX Live ) y ASL. La licencia GNU GPLv2+ fue la más popular. [ 40 ]

Véase también

Notas

  1. ↑ Wheeler, David A. (2015). "La lucha por la libertad" . Archivado del original el 4 de julio de 2017. Recuperado 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?" . Free Software Magazine . Archivado del original el 25 de enero de 2016 . Recuperado el 25 de enero de 2016 .
  3. 1 2 Esta licencia es una licencia copyleft débil, lo que significa que solo proporciona protección parcial contra la propiedad y la licencia puede permitir que los proyectos se utilicen en proyectos propietarios más grandes.
  4. ↑ Apple Computer, Inc. v. Franklin Computer Corporation Devuelve el valor al concepto 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)
  5. ↑ Lemley, Menell, Merges y Samuelson. Software and Internet Law , pág. 34.
  6. ↑ "Aviso de permiso de copia de GNU Emacs (1985)" . GitHub . Consultado el 8 de noviembre de 2015 .
  7. ↑ "GPLv3 - Transcripción de Richard Stallman de la tercera conferencia internacional GPLv3, Barcelona; 22-06-2006 - FSFE" . Consultado el 15 de julio de 2021 .
  8. ↑ Rubin, Paul (12 de diciembre de 1985). "Montgomery EMACS : ¿cuándo dejó de ser de dominio público ?" . Grupo de noticias : net.emacs . Este último está cubierto por la Licencia Pública General de GNU Emacs, que establece que el código fuente de cualquier cosa que lo utilice debe estar disponible gratuitamente para todos.   
  9. ↑ "Software libre - Aplicación de la GPL" . Tech Insider . Consultado el 1 de mayo de 2015 .
  10. ↑ "Versiones de GCC" . Consultado el 19 de marzo de 2015 .
  11. ↑ "GPLv3 - Transcripción de Richard Stallman de la segunda conferencia internacional GPLv3, Porto Alegre, Brasil; 21-04-2006" . Fsfe - Free Software Foundation Europe . Archivado del original el 15 de junio de 2010. Recuperado el 19 de marzo de 2015 .
  12. ↑ Mark (8 de mayo de 2008). "La maldición de la proliferación de licencias de código abierto" . socializedsoftware.com. Archivado del original el 8 de diciembre de 2015. Recuperado 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%
  13. ↑ David A. Wheeler. "Estimando el tamaño de Linux" .
  14. ↑ "SourceForge.net: Mapa de software" . Dwheeler.com. Archivado del original el 13 de febrero de 2017. Recuperado el 17 de noviembre de 2008. Licencia -> OSI: […] Licencia Pública General de GNU (GPL) (32641 proyectos), Licencia Pública General Reducida o de Biblioteca de GNU (LGPL) (4889 proyectos de 45727, 82,1 %).
  15. ↑ Kelty, Christopher M. (2008). "The Cultural Significance of free Software - Two Bits" (PDF) . Duke University Press - Durham y Londres. pág. 99. Antes de 1998, el software libre se refería a la Free Software Foundation (y a la atenta y microgestionada mirada de Stallman) o a uno de los miles de proyectos, procesos, licencias e ideologías comerciales, de aficionados o de investigación universitaria que tenían diversos nombres: sourceware, freeware, shareware, software abierto, software de dominio público, etc. El término código abierto, por el contrario, buscaba englobarlos a todos en un solo movimiento. 
  16. ↑ "Netscape anuncia planes para poner a disposición gratuitamente en la red el código fuente de Communicator de próxima generación" . Netscape Communications Corporation . 22 de enero de 1998. Archivado del original el 1 de abril de 2007. Consultado el 8 de agosto de 2013. Una audaz iniciativa para aprovechar el poder creativo de miles de desarrolladores de internet; la compañía pone Netscape Navigator y Communicator 4.0 a disposición de todos los usuarios de forma inmediata y gratuita, impulsando así el mercado para empresas y centros de datos.
  17. ↑ "MOUNTAIN VIEW, California, 1 de abril /PRNewswire/ -- Netscape Communications y los desarrolladores de código abierto celebran el primer aniversario, 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 del original el 26 de marzo de 2014. Recuperado 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 han seguido 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 celebra ahora este primer aniversario con una fiesta el jueves por la noche en San Francisco.
  18. ↑ Kelty, Christopher M. (2008). "The Cultural Significance of free Software - Two Bits" (PDF) . Duke University Press - Durham y Londres. pág. 100. El término Código Abierto, por el contrario, buscaba englobarlos 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 el futuro del Software Libre. […] Pero Netscape es mucho más famoso entre los geeks por regalar otra cosa, en 1998: el código fuente de Netscape Communicator (antes Navigator). 
  19. ↑ "Informe del Comité de Proliferación de Licencias y borrador de preguntas frecuentes" . Iniciativa de Código Abierto . 12 de diciembre de 2007.
  20. ↑ "Groklaw - La Ordenanza GPL alemana - Traducida" . Archivado del original el 5 de mayo de 2010. Consultado el 19 de marzo de 2015 .
  21. ↑ Véase Progress Software Corporation v. MySQL AB , 195 F. Supp. 2d 328 (D. Mass. 2002), sobre la moción del demandado para una medida cautelar preliminar.
  22. ↑ 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 .
  23. ↑ Bernstein, Daniel J. (2004). "Posición de documentos en el dominio público" . La mayoría de los derechos pueden ser abandonados voluntariamente ("renunciados") por el titular de los derechos. Los legisladores pueden esforzarse por crear derechos que no puedan abandonarse, pero generalmente no lo hacen. En particular, se pueden abandonar voluntariamente los derechos de autor en Estados Unidos: "Está bien establecido que los derechos adquiridos bajo 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 abandonarlo. Véase Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960)".
  24. ↑ Lawrence Rosen (8 de marzo de 2012). "(Revisión de licencia) (Discusión de licencia) CC0 incompatible con OSD en patentes, (antes: MXM comparado con CC0)" . opensource.org. Archivado del original el 12 de marzo de 2016. Recuperado el 22 de febrero de 2016. El caso al que te referiste en tu correo electrónico, Hampton v. Paramount Pictures, 279 F.2d 100 (9th Cir. Cal. 1960), representa la proposición de que, al menos en el Noveno Circuito, una persona puede renunciar a sus derechos de autor (contrario 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 al dominio público CC0 y la licencia de reserva como compatibles con OSD. Admito que durante años me he opuesto al "dominio público" como licencia de código abierto, pero en retrospectiva, considerando el mínimo riesgo para los desarrolladores y usuarios que dependen de dicho software y la evidente popularidad de esa "licencia", cambié de opinión. No se puede impedir la avalancha de software libre de dominio público, aunque no venga con una licencia FOSS mejor en la que confíe más. 
  25. ↑ Mark (8 de mayo de 2008). "La maldición de la proliferación de licencias de código abierto" . socializedsoftware.com. Archivado del original el 8 de diciembre de 2015. Recuperado 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 entre muchos proyectos de código abierto. Según Palamida, proveedor de software de cumplimiento de propiedad intelectual, aproximadamente 2489 proyectos de código abierto han pasado de la GPLv2 a versiones posteriores.
  26. 1 2 "Preguntas frecuentes sobre las licencias GNU: ¿Es compatible GPLv3 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 código publicado bajo ambas licencias, violaría la sección 6 de GPLv2. Sin embargo, si el código se publica bajo GPL 'versión 2 o posterior', es compatible con GPLv3 porque GPLv3 es una de las opciones que permite. 
  27. ↑ Kerner, Sean Michael (8 de enero de 2008). "Torvalds sigue interesado en la GPLv2" . internetnews.com . Recuperado 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 el código abierto y Linux siempre han representado, que es más una superioridad técnica en lugar de una... esta creencia religiosa en la libertad", dijo Torvalds a Zemlin. Entonces, la GPL versión 3 refleja los objetivos de la FSF y la GPL versión 2 se ajusta bastante bien a lo que creo que debería hacer una licencia y, por lo tanto, en este momento, la versión 2 es donde está el kernel.   
  28. 1 2 Byfield, Bruce (22 de noviembre de 2011). "7 razones por las que el software libre está perdiendo influencia: página 2" . Datamation.com . Recuperado el 23 de agosto de 2013. En ese 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.
  29. ↑ "MySQL cambia de licencia para evitar la GPLv3" . Computer business review online . 4 de enero de 2007. Archivado del original el 6 de febrero de 2007. Consultado el 21 de noviembre de 2016 .
  30. ↑ corbet (1 de octubre de 2006). "Busy busy busybox" . lwn.net . Recuperado el 21 de noviembre de 2015. Dado que BusyBox se encuentra en tantos sistemas embebidos, se sitúa en el centro del debate anti-DRM de la GPLv3. […] Sin embargo, los resultados reales son estos: BusyBox será solo GPLv2 a partir de la próxima versión. Generalmente se acepta que eliminar la frase "o cualquier versión posterior" es legalmente defendible, y que la fusión de otro código exclusivo de GPLv2 forzará ese problema en cualquier caso.
  31. ↑ Landley, Rob (9 de septiembre de 2006). "Re: Move GPLv2 vs v3 fun..." lwn.net . Recuperado el 21 de noviembre de 2015 . Por favor, no inventes un argumento falaz. 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.
  32. ↑ Prokoudine, Alexandre (26 de enero de 2012). "¿Qué pasa con la adopción de DWG en el software libre?" . libregraphicsworld.org. Archivado del original el 9 de noviembre de 2016. Recuperado el 5 de diciembre de 2015. Blender también sigue siendo 'GPLv2 o posterior'. Por el momento nos mantenemos así, el cambio a GPL 3 no tiene beneficios evidentes que yo conozca.
  33. ↑ Denis-Courmont, Rémi. "El reproductor multimedia VLC seguirá bajo la versión 2 de la GNU GPL" . videolan.org . Consultado el 21 de noviembre de 2015. En 2001, VLC se lanzó bajo la versión 2 de la GNU General Public, aprobada por la OSI, con la opción comúnmente ofrecida de usar "cualquier versión posterior" de la misma (aunque no existía tal 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 GNU General Public License (GPL) el 29 de junio de 2007, los colaboradores del reproductor multimedia VLC y otros proyectos de software alojados en videolan.org debatieron la posibilidad de actualizar los términos de la 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 ajusten a la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Consideramos que cambiar nuestros términos de licencia a la versión 3 de la GPL no sería lo más conveniente para nuestra comunidad en general. Por lo tanto, planeamos seguir distribuyendo las futuras versiones del reproductor multimedia VLC bajo los términos de la versión 2 de la GPL.      
  34. ↑ 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 del original el 29 de octubre de 2013. Recuperado el 2 de septiembre de 2013 .
  35. ↑ Proffitt, Brian (16 de diciembre de 2011). "El uso de GPL y copyleft disminuye más rápido que nunca" . ITworld . Archivado del original el 4 de septiembre de 2017. Recuperado el 17 de febrero de 2016 .
  36. ↑ 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é?" . IT world. Archivado del original el 3 de diciembre de 2013. Recuperado el 23 de agosto de 2013 .
  37. ↑ Aslett, Matthew (15 de diciembre de 2011). "Sobre el continuo declive de la GPL" . Archivado del original el 9 de diciembre de 2016. Recuperado el 17 de febrero de 2016 .
  38. 1 2 "Las 20 licencias más populares" . Black Duck Software. 19 de noviembre de 2015. Archivado del 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 de Microsoft 2%, 10. Licencia Pública Eclipse (EPL) 2%
  39. 1 2 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 Otras 15,68%, 3 GPLv2 12,96%, 4 Apache 11,19%, 5 GPLv3 8,88%, 6 BSD de 3 cláusulas 4,53%, 7 Sin licencia 1,87%, 8 BSD de 2 cláusulas 1,70%, 9 LGPLv3 1,30%, 10 AGPLv3 1,05%
  40. 1 2 Anwesha Das (22 de junio de 2016). "Licencias de software en el ecosistema Fedora" . anweshadas.in . Recuperado el 27 de junio de 2016. Del gráfico anterior se desprende claramente que la familia GPL es la más utilizada (antes la había calculado erróneamente como MIT). Las otras licencias principales son MIT, BSD, la familia LGPL, Artistic (para paquetes Perl), LPPL (para paquetes texlive), ASL.
  41. ↑ "Varias licencias y comentarios sobre ellas - Proyecto GNU - Fundación del Software Libre" . Consultado el 19 de marzo de 2015 .
  42. ↑ "Por qué deberías usar una licencia de estilo BSD para tu proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  43. ↑ "Por qué deberías usar una licencia de estilo BSD para tu proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  44. ↑ "GPLv3 - Transcripción de Richard Stallman de la quinta conferencia internacional GPLv3, Tokio, Japón; 21-11-2006" . Consultado el 19 de marzo de 2015 .
  45. ↑ "Richard Stallman analiza los cambios en la GPLv3" . Un nuevo método para intentar privar a los usuarios de libertad. En términos generales, nos referimos a esto como tivoización.
  46. ↑ Wheeler, David A. (27 de septiembre de 2007). "La diapositiva de la licencia de software libre/de código abierto (FLOSS)" . Archivado del original el 9 de marzo de 2011. Recuperado el 28 de noviembre de 2015 .
  47. ↑ "Cómo GPLv3 aborda la proliferación de licencias" .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  48. ↑ LAURENT, Philippe (24 de septiembre de 2008). "La GPLv3 y los problemas de compatibilidad" (PDF) . Evento de Abogados Europeos de Código Abierto 2008. Universidad de Namur – Bélgica. pág. 7. Archivado del original (PDF) el 4 de marzo de 2016. Recuperado el 30 de mayo de 2015. El copyleft es la principal fuente de problemas de compatibilidad. 
  49. ↑ Fundación Apache (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, ya que la licencia GPLv3 acepta nuestro software como obras GPLv3. Sin embargo, el software GPLv3 no puede incluirse en proyectos Apache. Las licencias son incompatibles en una sola dirección, y esto se debe a la filosofía de licenciamiento de la Fundación Apache y a la interpretación de la ley de derechos de autor por parte de los autores de GPLv3.
  50. ↑ Hanwell, Marcus D. (28 de enero de 2014). "¿Debería usar una licencia permisiva? ¿Copyleft? ¿O algo intermedio?" . opensource.com . Recuperado el 30 de mayo de 2015 . Las licencias permisivas simplifican las cosas Una razón por la que el mundo empresarial, y cada vez más desarrolladores […], prefieren las licencias permisivas es la simplicidad de la reutilización. La licencia generalmente 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 una obra derivada. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que todas son compatibles.
  51. ↑ "Compatibilidad e interoperabilidad de licencias" . Software de código abierto: desarrollar, compartir y reutilizar software de código abierto para administraciones públicas . joinup.ec.europa.eu. Archivado del original el 17 de junio de 2015. Recuperado 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 no libres o "propietarias").
  52. ↑ Landley, Rob. "Charla de CELF 2013 Toybox" . landley.net . Consultado el 21 de agosto de 2013. La GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
  53. ↑ "Los problemas de HESSLA - Proyecto GNU - Fundación del Software Libre" . Consultado el 19 de marzo de 2015 .
  54. ↑ "GPLv3 - Transcripción de Richard Stallman de la tercera conferencia internacional GPLv3, Barcelona; 22-06-2006" . Consultado el 19 de marzo de 2015 .
  55. ↑ "Envidia de la censura y licencias — Free Software Foundation — Trabajando juntos por el software libre" .
  56. ↑ "Características distintivas de SQLite" .
  57. ↑ "Una licencia de código abierto pacífica | Wise Earth Technology" .
  58. ↑ "Solo para uso no militar" .
  59. ↑ "❌(REVERTED): Agregar texto a la licencia MIT que prohíbe a los colaboradores de ICE por jamiebuilds · Pull Request #1616 · lerna/Lerna" . GitHub .
  60. ↑ "El mal, o por qué Douglas Crockford es perjudicial para el software libre" . 8 de noviembre de 2012.
  61. ↑ "JSMin no es bienvenido en Google Code - wonko.com" . wonko.com . Consultado el 1 de junio de 2024 .
  62. ↑ "Proyecto de código abierto añade cláusula de 'no uso militar' a la GPL" . 14 de agosto de 2006.
  63. ↑ "Inicio" . commonsclause.com .
  64. ↑ "La SSPL no es una licencia de código abierto | Iniciativa de código abierto" . 19 de enero de 2021.
  65. ↑ "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 todas las obras que sean derivadas [...]. En consecuencia, el software sujeto a los términos de la GPL no puede incluirse en el núcleo o el "tiempo de ejecución" de OpenBSD.
  66. ^ "FreeBSD der unbekannte Riese" (en alemán). 30 de agosto de 2023.
  67. ↑ "Condiciones de uso" . El contenido que envíe no debe competir directamente con los productos de MathWorks. El contenido enviado a File Exchange solo puede utilizarse con productos de MathWorks.
  68. ↑ "Preguntas frecuentes sobre la transición a las licencias de intercambio de archivos" .
  69. ↑ "¿Por qué no puedo usar código de File Exchange en Octave? ¡Está publicado bajo una licencia BSD!" .
  70. ↑ "¿Libertad o poder?, de Bradley Kuhn y Richard Stallman" .
  71. ↑ "Preguntas frecuentes sobre las licencias GNU: ¿Por qué no utilizan la GPL para los manuales?" . Consultado el 20 de junio de 2009 .
  72. ↑ Braakman, Richard. "Re: Declaración propuesta sobre GNU FDL" . Debian-legal (Lista de correo).
  73. ↑ Srivastava, Manoj (2006). "Borrador de la Declaración de Posición de Debian sobre la Licencia de Documentación Libre de GNU (GFDL)" . Recuperado 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. Esto no es una simple incompatibilidad de licencias. No se trata solo de que la GFDL sea incompatible con tal o cual licencia de software libre: se trata de que es fundamentalmente incompatible con cualquier licencia de software libre. Por lo tanto, si escribes un programa nuevo y no tienes ningún compromiso sobre qué licencia quieres usar, salvo que sea una licencia libre, no puedes incluir texto con licencia GFDL. La GNU FDL, tal como está hoy, no cumple con las Directrices de Software Libre de Debian. Hay problemas significativos con la licencia, como se detalla anteriormente; y, por lo tanto, no podemos aceptar obras con licencia GNU FDL en nuestra distribución.
  74. ↑ Nerode, Nathanael (24 de septiembre de 2003). "Por qué no deberías usar la GNU FDL" . Archivado del original el 9 de octubre de 2003. Recuperado el 7 de noviembre de 2011 .
  75. ↑ Bruce Perens (2 de septiembre de 2003). "Interponiéndose entre Debian y FSF" . lists.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 a la ética del software libre al promover una licencia que permite que las secciones invariantes se apliquen a cualquier cosa que no sea el 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 ética que la FSF ha promovido durante 19 años.
  76. ↑ "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 .
  77. ↑ Fundación de Manuales FLOSS (6 de junio de 2007). "Cambio de licencia" . Blog de Manuales FLOSS . Fundación de Manuales FLOSS . Consultado el 20 de junio de 2009 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  78. ↑ "Transcripción de Richard Stallman en la 3.ª conferencia internacional GPLv3" . Free Software Foundation Europe. 22 de junio de 2006. Consultado el 23 de julio de 2017 .
  79. ↑ 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 .
  80. ↑ "Análisis de licencias de código abierto" . Lwn.net . Consultado el 2 de septiembre de 2013 .

Referencias

  • Rosen, Lawrence (22 de julio de 2004). Licencias de código abierto: Libertad de software y derecho de propiedad intelectual . Prentice Hall. ISBN 978-0-13-148787-1.
  • La definición de software libre , según la Fundación del Software Libre.
  • Lista de licencias libres y no libres de la Free Software Foundation
  • Página de información sobre la licencia de Debian
  • Lista de licencias de la Open Source Initiative
  • Comprender el software libre y de código abierto , por Andrew M. St. Laurent
  • Un manual de 45 páginas sobre licencias del Software Freedom Law Center.
Lecturas relacionadas
6 articulos
Distribución de softwareDistribución de softwareLa distribución de software es el proceso de entregar software al usuario final. [1]Derechos de autorDerechos de autorUn derecho de autor es un tipo de propiedad intelectual que otorga a su propietario el derecho legal exclusivo de copiar, distribuir, adaptar, exhi...Software licenseSoftware licenseDiagram of software under various licenses according to the FSF and their The Free Software Definition : on the left side " free software ", on the...Creación de un juego de carreras de coches en 3D utilizando el motor de juego Blender.Software libreGNU Guix . Un ejemplo de un sistema operativo de software libre que cumple con la FSDG de GNU y que ejecuta algunas aplicaciones representativas. S...Software libre y de código abiertoSoftware libre y de código abiertoEl software libre y de código abierto ( FOSS , por sus siglas en inglés) es un software que está disponible bajo una licencia que otorga el derecho...SoftwareSoftwareEl software consiste en programas informáticos que dan instrucciones sobre la ejecución de una computadora . [1] El software puede definirse de man...