De Wikipedia, la enciclopedia libre
  (Redirigido desde la licencia de software libre )
Saltar a navegación Saltar a búsqueda

Tipos de licencia de software y licencias similares. Las columnas resaltadas son software gratuito .
Dominio público y equivalentesLicencia permisivaCopyleft (licencia de protección)Licencia no comercialLicencia propietariaSecreto comercial
DescripciónOtorga todos los derechosOtorga derechos de uso, incluido el derecho a volver a licenciar (permite la propiedad , compatibilidad de licencia )Otorga derechos de uso, prohíbe la propiedadOtorga derechos para uso no comercial únicamente. Puede combinarse con copyleft.Uso tradicional de derechos de autor ; no es necesario otorgar derechosNinguna información hecha pública
SoftwarePD, CC0MIT , Apache , MPLGPL , AGPLJRL , AFPLsoftware propietario , sin licencia públicasoftware interno privado
Otras obras creativasPD, CC0CC-BYCC-BY-SACC-BY-NCCopyright , sin licencia públicainédito
El espectro de licencias de software libre y algunos ejemplos de programas bajo esas licencias según David A. Wheeler (2007) [1]
Copyleft
artículos sobre licencias Copyleft
Temas

Categoría superior: Software , Libertad

Una licencia de software libre es un aviso que otorga al destinatario de una pieza de software amplios derechos para modificar y redistribuir ese software. Estas acciones generalmente están 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 al destinatario estos derechos. El software que utiliza una licencia de este tipo es software libre (o software libre y de código abierto ) otorgado por el titular de los derechos de autor. Las licencias de software libre se aplican al software en código fuente y también en código objeto binario.forma, ya que la ley de derechos de autor reconoce ambas formas. [2]

Comparación [ editar ]

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

Licencias protectoras y permisivas de uso frecuente
AGPLv3GPLv3GPLv2.1LGPLv3LGPLv2.1MPL-2BSD
SaaS / nubesíNoNoNoNoNoNo
TivoizaciónsísíNosíNoNoNo
Trolling de patentessísíNosíNoNoNo
PrivatizaciónsísísíParcialParcialParcialNo
Granularidad / alcanceProyectoProyectoProyectoBibliotecaBibliotecaArchivoN / A
Concesión de marca comercialsísí?sí?NoNo

Historia [ editar ]

Ver también: Historia del software gratuito y de código abierto

Antes de la década de 1980 [ editar ]

En los primeros tiempos del software, compartir software y código fuente era común en ciertas comunidades, por ejemplo, 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 de computadora, en la medida en que incorporen la creación original de un autor, son materia apropiada de derechos de autor", [3] [4] el software no era considerado sujeto a derechos de autor. Por lo tanto, el software no tenía licencias adjuntas y se compartió como software de dominio público . La decisión CONTU más decisiones judiciales como Apple v. Franklin en 1983 por código objeto , aclaró que la Ley de Derechos de Autor otorgó a los programas de computadora el estatus de derechos de autor de obras literarias y comenzó lalicenciamiento de software .

Las licencias de software libre antes de finales de la década de 1980 eran generalmente avisos informales escritos por los propios desarrolladores. Estas primeras licencias eran del tipo " permisivo ".

Década de 1980 [ editar ]

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 usó para GNU Emacs en 1985, [5] con revisiones posteriores en 1986, 1987 y 1988 que tomaron el nombre de "Licencia pública general GNU Emacs". [6] Asimismo, se aplicó una licencia pública general similar de GCC a la colección de compiladores GNU , que se publicó inicialmente en 1987. [7] [8] La licencia BSD original es también una de las primeras licencias de software libre, que data de 1988. . En 1989, la versión  1 de la Licencia Pública General GNU(GPL) se publicó. La versión  2 de la GPL, lanzada en 1991, pasó a convertirse en la licencia de software libre más utilizada. [9] [10] [11]

De 1990 a 2000 [ editar ]

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

A partir de las licencias de software libre, la versión  2 de GNU GPL se ha probado en los tribunales, primero en Alemania en 2004 y luego en los EE. UU. En el caso alemán, el juez no discutió explícitamente la validez de las cláusulas de la GPL, pero aceptó que la GPL debía cumplirse: "Si las partes no acordaran la GPL, el acusado carecería de los derechos necesarios para copiar, distribuir y hacer que el software 'netfilter / iptables' esté disponible públicamente ". Debido a que el demandado no cumplió con la GPL, tuvo que dejar de usar el software. [17] El caso de EE. UU. ( MySQL contra Progress) se resolvió antes de que se llegara a un veredicto, pero en una audiencia inicial, el juez Saris "no vio ninguna razón" para que la GPL no fuera ejecutable. [18]

Alrededor de 2004, el abogado Lawrence Rosen argumentó en el ensayo ¿Por qué el dominio público no es una licencia? El software no puede realmente pasar al dominio público y no puede interpretarse como una licencia FOSS muy permisiva, [19] una posición que enfrentó la oposición de Daniel J. Bernstein y otros. [20] En 2012, la disputa se resolvió finalmente cuando Rosen aceptó el CC0 como licencia de código abierto , al tiempo que admitió que, contrariamente a sus afirmaciones anteriores, se puede renunciar a los derechos de autor, respaldado por decisiones del Noveno circuito . [21]

En 2007, después de años de discusión preliminar, se lanzó la GPLv3 como actualización importante de la GPLv2. El lanzamiento fue controvertido [22] debido al alcance extendido significativo de la licencia, que la hizo incompatible con la GPLv2. [23] Varios proyectos importantes de software libre ( kernel de Linux , [24] [25] MySQL , [26] BusyBox , [27] [28] Blender , [29] VLC media player [30] ) decidieron no adoptar la GPLv3. Por otro lado, en 2009, dos años después del lanzamiento de la GPLv3, GoogleEl director de la oficina de programas de código abierto, Chris DiBona, informó que el número de proyectos de código abierto con licencia de software que se habían trasladado a GPLv3 desde GPLv2 era del 50%, contando los proyectos alojados en Google Code . [31]

Década de 2010 [ editar ]

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 los datos de Black Duck Software. [25] [32] A continuación, en 2011 , el analista de 451 Group , Matthew Aslett, argumentó en una publicación de blog que las licencias de copyleft entraron en declive y las licencias permisivas aumentaron, según las estadísticas de Black Duck Software. [33] [34]

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

Definiciones [ editar ]

Licencias de código abierto aprobadas por OSI [ editar ]

Artículo principal: licencia de código abierto

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 requerida ] [ aclaración necesaria ] Por lo tanto, sus requisitos para aprobar licencias son diferentes.

Licencias de software libre aprobadas por la FSF [ editar ]

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

La Free Software Foundation prefiere las licencias de software libre con copyleft ( compartidas por igual ) en lugar de las licencias permisivas de software libre para la mayoría de los propósitos. Su lista distingue entre licencias de software libre que son compatibles o incompatibles con la licencia pública general GNU copyleft de la FSF .

Condiciones de las licencias de software libre [ editar ]

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

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

Copyleft [ editar ]

Artículo principal: 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 disposiciones de copyleft subsiguientes establecieron que cuando se distribuyen versiones modificadas de software libre, deben distribuirse bajo los mismos términos que el software original. Por lo tanto, se denominan "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 otorguen 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 cualquier persona cuando compartan o vendan el código objeto . En este caso, el código fuente también debe contener los cambios que hayan realizado los desarrolladores. Si se usa 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 que los desarrolladores y las organizaciones utilicen y modifiquen el código GPL para fines privados (es decir, cuando el código o el proyecto no se venda o no se comparta) sin necesidad de que sus cambios estén disponibles para el público.

Los partidarios de GPL afirman que al exigir que los trabajos derivados permanezcan bajo la GPL, fomenta el crecimiento del software libre y requiere la participación equitativa de todos los usuarios. Los que se oponen a la GPL afirman [39] que "ninguna licencia puede garantizar la disponibilidad futura del software" y que las desventajas de la GPL superan [40] sus ventajas. Algunos también argumentan que restringir la distribución hace que la licencia sea menos gratuita. Mientras que los proponentes 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 de patentes [ editar ]

Más información: Represalias por patentes

Durante la década de 1990, las licencias de software libre comenzaron a incluir cláusulas, como represalias por patentes , para protegerse contra casos de litigios sobre patentes de software , un problema que no había existido anteriormente. Esta nueva amenaza fue una de las razones para la escritura de la versión  3 de la GPL de GNU en 2006. [41] En los últimos años, un término acuñado tivoización describe un proceso en el que se utilizan las restricciones de hardware para evitar que los usuarios ejecuten versiones modificadas del software en ese hardware, en el que el dispositivo TiVo es un ejemplo. La FSF lo ve como una forma de convertir el software libre en no libre de manera efectiva, y es por eso que han optado por prohibirlo en la GPLv3 . [42]La mayoría de las nuevas licencias de software libre escritas desde finales de la década de 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 la redistribución), pueden terminarse si se intenta hacer cumplir las patentes relacionadas con el software con licencia, 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 procedimiento de litigio en su contra debido a un litigio de patentes. Las represalias por patentes surgieron en respuesta a la proliferación y el abuso de las patentes de software .

Restricciones de hardware [ editar ]

Artículo principal: restricciones de hardware

La versión  3 de GNU GPL incluye un lenguaje específico que prohíbe restricciones adicionales impuestas por restricciones de hardware y administración de derechos digitales (DRM) , una práctica que la FSF llama tivoización después de que Tivo usó software GPL en dispositivos que no permitían la modificación de ese software por parte del usuario.

Atribución, exenciones de responsabilidad y avisos [ editar ]

La mayoría de las licencias de software libre requieren que el software modificado no pretenda no haber sido 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 requiere 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 [ editar ]

Compatibilidad de licencia [ editar ]

Compatibilidad de licencia 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") [43]
Artículo principal: compatibilidad de licencias

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. [44] La compatibilidad de licencia entre una licencia copyleft y otra licencia es a menudo solo una compatibilidad unidireccional. [45] 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. [46] Las licencias sin copyleft, como las licencias permisivas de software libre , tienen una interacción de licencia menos complicada y normalmente exhiben una mejor compatibilidad de licencias. [47][48] 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 usa una licencia con un paquete de software que utiliza el otro, 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 con la licencia. Cuando se trata de licencias de software copyleft , no son intrínsecamente compatibles con otras licencias copyleft, incluso la GPLv2, por sí misma, no es compatible con la GPLv3. [23] [49]

Finalidad de uso [ editar ]

Las restricciones sobre el uso de un software ("restricciones de uso") son generalmente inaceptables de acuerdo con 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, [ aclaración necesaria ] por medios éticamente cuestionables, [50] o en organizaciones comerciales. [51] Si bien algunas restricciones a la libertad de los usuarios, por ejemplo, las relativas a la guerra nuclear, parecen gozar de apoyo moral entre la mayoría de los desarrolladores de software libre, [52]En general, se cree que tales agendas no deben cumplirse mediante licencias de software; entre otras cosas, debido a aspectos prácticos como las incertidumbres legales resultantes y los problemas con la aplicabilidad de criterios vagos, amplios y / o subjetivos, o porque los fabricantes de herramientas generalmente no son responsables del uso de sus herramientas por parte de otras personas. Sin embargo, algunos proyectos incluyen peticiones legalmente no vinculantes para el usuario, principalmente SQLite . [53] Entre los repetidos intentos [54] [55] [56] de los desarrolladores para regular el comportamiento del usuario a través de la licencia que provocó un debate más amplio se encuentran la cláusula "sin maldad" (en broma) de Douglas Crockford , que afectó el proceso de publicación de la Distribución de Debian en 2012 [57]y consiguió que el proyecto JSMin-PHP fuera expulsado de Google Code , [58] 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, [59] así como varios proyectos de software que intentaban para excluir el uso por parte de grandes proveedores de servicios en la nube. [60] [61]

Conflictos de definición [ editar ]

Como hay varias organizaciones y grupos definitorios que publican definiciones y pautas sobre las licencias de software libre, en particular la FSF, el OSI, el proyecto Debian y los BSD, a veces hay opiniones e interpretaciones contradictorias.

Opiniones permisivas versus copyleft [ editar ]

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

Como resultado, el código BSD se puede utilizar en software propietario que solo reconoce a los autores. Por ejemplo, Microsoft Windows NT 3.1 y macOS tienen pilas de IP patentadas que se derivan del software con licencia BSD. [63] En casos extremos, las posibilidades de sublicenciar o volver a otorgar licencias 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 evita, con términos de uso adicionales , cualquier uso además de su propio software MATLAB patentado , por ejemplo, con FOSS GNU Octave.software. [64] [65] [66]

En el lado positivo, dado que las licencias permisivas similares a BSD tienen restricciones muy limitadas (generalmente solo atribución ), también tienen una excelente compatibilidad de licencias , incluso con licencias copyleft. [47] [48]

Los partidarios de la licencia BSD argumentan que es más gratuita que la GPL porque otorga el derecho a hacer cualquier cosa con el código fuente, siempre que se conserve la atribución. Por ejemplo, los usuarios pueden incorporar el código con licencia BSD en productos patentados. El enfoque ha llevado a que el código BSD se utilice en software propietario común y ampliamente utilizado. En respuesta, los defensores de la GPL señalan que una vez que el código se convierte en propietario, los usuarios carecen de las libertades que definen el software libre. [67] Como resultado, consideran la licencia BSD 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 recontribuyan a la comunidad, [ dudoso - discutir ] ni ella ni la GPL son "gratuitas" en el sentido de que "carecen de restricciones".

El código con una licencia de software libre permisiva , como la licencia BSD, puede incorporarse en proyectos con copyleft (por ejemplo, GPL). Por tanto, dicho código es "compatible con GPL". No es necesario obtener el consentimiento de los autores originales. Por el contrario, el código de la GPL no se puede volver a otorgar bajo la licencia BSD sin obtener el consentimiento de todos los titulares de los derechos de autor. Por lo tanto, las dos licencias son compatibles, pero (a menos que se haya obtenido dicho consentimiento) la combinación en su conjunto debe distribuirse bajo los términos de la GPL y no la licencia permisiva.

Los proyectos existentes de software libre con licencia BSD tienden a evitar incluir software con licencia GPL en el sistema operativo central o en el sistema base , excepto como último recurso cuando las alternativas no existen o son mucho menos capaces, como con GCC . Por ejemplo, a partir de FreeBSD  10.0, GCC fue reemplazado por el compilador Clang / LLVM , quizás principalmente por esta razón. [ cita requerida ] El proyecto OpenBSD ha actuado para eliminar las herramientas con licencia GPL a favor de alternativas con licencia BSD, algunas recién escritas y otras adaptadas de código anterior. [68]

Debian [ editar ]

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 sobre 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 [ editar ]

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

Ejemplos de licencias que provocaron debate fueron la serie 1.x de Apple Public Source License , que fueron aceptadas por la Open Source Initiative pero no por la Free Software Foundation o Debian y la RealNetworks Public Source License , que fue aceptada por Open Source Initiative. y Free Software Foundation, pero no de Debian .

Además, la FSF recomendó GNU Free Documentation License , [69] que es incompatible con la GPL, [70] fue considerada "no libre" por el proyecto Debian alrededor de 2006, [71] Nathanael Nerode, [72] y Bruce Perens . [73] La FSF aduce que la documentación es cualitativamente diferente del software y está sujeta a diferentes requisitos. Debian aceptó, en una resolución posterior, que GNU FDL cumplía con las Directrices de software libre de Debian cuando se elimina la controvertida "sección invariante", pero considera que "todavía no está libre de problemas". [74]No obstante, la mayoría de la documentación de GNU incluye "secciones invariables". Del mismo modo, la fundación FLOSS Manuals , organización dedicada a la creación de manuales de software libre, decidió prescindir de la GFDL en favor de la GPL para sus textos en 2007, citando la incompatibilidad entre las dos, las dificultades para implementar la GFDL y el hecho de que el GFDL "no permite una fácil duplicación y modificación", especialmente para la documentación digital. [75]

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

Cuota de mercado [ editar ]

Si bien históricamente la licencia FOSS más utilizada ha sido la GPLv2, en 2015, según Black Duck Software [35], 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 su metodología utilizada en la recopilación de estadísticas. [77] Daniel German, profesor del Departamento de Ciencias de la Computación de la Universidad de Victoriaen 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. [78]

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

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

Ver también [ editar ]

  • Comparación de licencias de software gratuitas y de código abierto
  • Acuerdo de licencia de usuario final
  • Software sin licencia
  • Lista de licencias de contenido libre
  • Dominio publico
  • Licencia de software

Notas [ editar ]

  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). "¿Y 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. v.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 e Internet , pág. 34.
  5. ^ "Aviso de permiso de copia de GNU Emacs (1985)" . Consultado el 8 de noviembre de 2015 .
  6. ^ "Software libre - Aplicación de la GPL" . Tech Insider . Consultado el 1 de mayo de 2015 .
  7. ^ "Lanzamientos de GCC" . Consultado el 19 de marzo de 2015 .
  8. ^ "GPLv3 - Transcripción de Richard Stallman de la segunda conferencia internacional GPLv3, Porto Alegre, Brasil; 2006-04-21" . Consultado el 19 de marzo de 2015 .
  9. ^ 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 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 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%
  10. ^ David A. Wheeler. "Estimación del tamaño de Linux" .
  11. ^ "SourceForge.net: Mapa de software" . Dwheeler.com . 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%)
  12. ^ 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 a la Free Software Foundation (y al ojo vigilante y microgestivo de Stallman) oa uno de los miles de diferentes proyectos, procesos, licencias e ideologías comerciales, profesionales o de investigación universitaria que tenían una variedad de nombres: sourceware, freeware, shareware, software abierto, software de dominio público, etc. El término Open Source, por el contrario, buscaba englobarlos a todos en un solo movimiento.
  13. ^ "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 de Netscape . 22 de enero de 1998. Archivado desde el original el 1 de abril de 2007 . Consultado el 8 de agosto de 2013 . Movimiento audaz para aprovechar el poder creativo de miles de desarrolladores de Internet; La empresa hace que Netscape Navigator y Communicator 4.0 sean inmediatamente gratuitos para todos los usuarios, sembrando mercado para empresas y negocios de netcenter
  14. ^ "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 de Netscape en mozilla.org" . Comunicaciones de 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 a 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 compañía de software comercial en abrir su código fuente, una tendencia que desde entonces ha sido seguida por varias otras corporaciones. Desde que el código se publicó por primera vez en Internet, miles de personas y organizaciones lo descargaron y realizaron cientos de contribuciones al software. Mozilla.org ahora está celebrando este primer aniversario con una fiesta el jueves por la noche en San Francisco.
  15. ^ 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 Open Source, por el contrario, buscaba englobarlos a todos en un solo movimiento. El evento que precipitó este intento de golpe de estado semántico fue el lanzamiento 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).
  16. ^ "Informe del Comité de proliferación de licencias y proyecto de preguntas frecuentes" . Iniciativa de código abierto . 12 de diciembre de 2007.
  17. ^ "Groklaw - La orden GPL alemana - Traducido" . Consultado el 19 de marzo de 2015 .
  18. ^ Ver Progress Software Corporation v. MySQL AB , 195 F. Supp. 2d 328 (D. Mass. 2002), sobre la moción del demandado de orden judicial preliminar.
  19. ^ 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 .
  20. ^ Bernstein, Daniel J. (2004). "Colocación de documentos en el dominio público" . La mayoría de los derechos pueden ser abandonados voluntariamente ("renunciados") por el propietario de los derechos. Los legisladores pueden hacer un esfuerzo adicional para crear derechos que no se pueden abandonar, pero por lo general no lo hacen. En particular, puede abandonar voluntariamente sus derechos de autor de 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. Consulte Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (Noveno Cir. 1960) ".
  21. ^ Lawrence Rosen (8 de marzo de 2012). "(Revisión de licencia) (Discusión de licencia) CC0 no cumple con OSD sobre patentes, (era: MXM en comparación con CC0)" . opensource.org. Archivado desde el original el 12 de marzo de 2016 . Consultado el 22 de febrero de 2016 .El caso al que hizo referencia en su 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, de hecho, abandonar sus derechos de autor (contador a lo que escribí en mi artículo), pero se necesita el equivalente a una licencia de manifiesto para hacerlo. :-) ... Para que conste, ya he votado +1 para aprobar la licencia de reserva y dedicación de dominio público CC0 como compatible con OSD. Admito que he argumentado durante años en contra del "dominio público" como una 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 de dominio público gratuito, incluso si no lo hace 'Viene con una mejor licencia FOSS en la que confío más.
  22. ^ Mark (8 de mayo de 2008). "La maldición de la proliferación de licencias de código abierto" . socializedsoftware.com. Archivado desde el original el 8 de diciembre de 2015 . Consultado el 30 de noviembre de 2015 . Actualmente, la decisión de pasar de GPL v2 a GPL v3 está siendo objeto de acalorados debates en muchos proyectos de código abierto. Según Palamida, un proveedor de software de cumplimiento de IP, ha habido aproximadamente 2489 proyectos de código abierto que se han trasladado de GPLv2 a versiones posteriores.
  23. ^ a b "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 intenta 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', eso es compatible con GPLv3 porque GPLv3 es una de las opciones que permite. 
  24. ^ Kerner, Sean Michael (8 de enero de 2008). "Torvalds sigue interesado en GPLv2" . internetnews.com . Consultado el 12 de febrero de 2015 . De alguna manera, Linux fue el proyecto que realmente dejó en claro la división entre lo que la FSF está impulsando, que es muy diferente de lo que siempre ha sido el código abierto y Linux, que es más una superioridad técnica en lugar de una - esta creencia religiosa. en libertad ", dijo Torvalds a Zemlin. Por lo tanto, 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, ahora mismo, la Versión 2 es donde está el kernel.   
  25. ↑ a b Byfield, Bruce (22 de noviembre de 2011). "7 razones por las que el software libre está perdiendo influencia: página 2" . Datamation .com . Consultado el 23 de agosto de 2013 . En ese momento, la decisión parecía sensata frente a 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.
  26. ^ "MySQL cambia la licencia para evitar la 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 .
  27. ^ corbet (1 de octubre de 2006). "Busy busy busybox" . lwn.net . Consultado el 21 de noviembre de 2015 . Dado que BusyBox se puede encontrar en tantos sistemas embebidos, se encuentra en el centro del debate anti-DRM de GPLv3. […] Los resultados reales, sin embargo, son los siguientes: BusyBox será GPLv2 solo 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 fusión de otro código exclusivo de GPLv2 forzará ese problema en cualquier caso.
  28. ^ Landley, Rob (9 de septiembre de 2006). "Re: Move GPLv2 vs v3 fun ..." lwn.net . Consultado el 21 de noviembre de 2015 . No inventes un argumento de hombre de paja, por favor. Considero que la licencia de BusyBox bajo GPLv3 es inútil, innecesaria, complicada y confusa, y además tiene desventajas reales. 1) Inútil: nunca vamos a eliminar la GPLv2.
  29. ^ Prokoudine, Alexandre (26 de enero de 2012). "¿Qué pasa con la adopción de DWG en 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, cambiar a GPL 3 no tiene beneficios evidentes que yo sepa.
  30. ↑ Denis-Courmont, Rémi. "VLC media player permanecerá bajo GNU GPL versión 2" . videolan.org . Consultado el 21 de noviembre de 2015 . En 2001, VLC fue lanzado bajo la versión GNU General Public 2 aprobada por OSI , con la opción comúnmente ofrecida para usar 'cualquier versión posterior' del mismo (aunque no habí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 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 licencia para la versión futura 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 puedan no coincidir con la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Creemos que cambiar nuestros términos de licencia a la versión  3 de la GPL no redundaría actualmente en el mejor interés de nuestra comunidad en su conjunto. En consecuencia, planeamos seguir distribuyendo versiones futuras del reproductor multimedia VLC según los términos de la versión  2 de la GPL .
  31. ^ Asay, Matt (23 de julio de 2009). "GPLv3 alcanza la adopción del 50 por ciento | The Open Road - CNET News" . News.cnet.com . Consultado el 2 de septiembre de 2013 .
  32. ^ Proffitt, Brian (16 de diciembre de 2011). "GPL, el uso del copyleft está disminuyendo más rápido que nunca" . ITworld .
  33. ^ Proffitt, Brian (16 de diciembre de 2011). "GPL, el uso de copyleft está disminuyendo 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 de TI . Consultado el 23 de agosto de 2013 .
  34. ^ 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 .
  35. ^ a b "Top 20 licencias" . Software Black Duck. 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, Licencia nueva o revisada 6%, 6. Licencia pública general reducida de GNU (LGPL) 2,1 5%, 7. Licencia artística (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 de Eclipse (EPL) 2%
  36. ↑ a b 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 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% , 10 AGPLv3 1.05%
  37. ↑ a b Anwesha Das (22 de junio de 2016). "Licencias de software en el ecosistema Fedora" . anweshadas.in . Consultado el 27 de junio de 2016 . A partir de la tabla anterior, está 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 (paquetes foe texlive ), ASL.
  38. ^ "Varias licencias y comentarios sobre ellos - Proyecto GNU - Free Software Foundation" . Consultado el 19 de marzo de 2015 .
  39. ^ "Por qué debería utilizar una licencia de estilo BSD para su proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  40. ^ "Por qué debería utilizar una licencia de estilo BSD para su proyecto de código abierto" . Consultado el 19 de marzo de 2015 .
  41. ^ "GPLv3 - Transcripción de Richard Stallman de la quinta conferencia internacional GPLv3, Tokio, Japón; 2006-11-21" . Consultado el 19 de marzo de 2015 .
  42. ^ "Richard Stallman analiza los cambios en GPLv3" . un nuevo método para intentar privar a los usuarios de la libertad. En términos generales, nos referimos a esto como tivoización.
  43. ^ Wheeler, David A. (27 de septiembre de 2007). "Diapositiva de licencia de software libre / de código abierto (FLOSS)" .
  44. ^ "Cómo GPLv3 aborda la proliferación de licencias" . Archivado desde el original el 2 de mayo de 2013.
  45. ^ 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.
  46. ^ 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 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 los proyectos de 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 los autores de la GPLv3 de la ley de derechos de autor.
  47. ↑ a b Hanwell, Marcus D. (28 de enero de 2014). "¿Debo usar una licencia permisiva? ¿Copyleft? ¿O algo en el medio?" . 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 pertenece al código fuente que se 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 todos son compatibles.
  48. ^ a b "Compatibilidad de licencia e interoperabilidad" . 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 otras licencias, y toleran fusionar, combinar o mejorar el código cubierto y redistribuirlo bajo muchas licencias (incluidas las no libres o 'propietarias ').
  49. ^ 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.
  50. ^ "Los problemas de HESSLA - Proyecto GNU - Free Software Foundation" . Consultado el 19 de marzo de 2015 .
  51. ^ "GPLv3 - Transcripción de Richard Stallman de la tercera conferencia internacional GPLv3, Barcelona; 2006-06-22" . Consultado el 19 de marzo de 2015 .
  52. ^ https://www.fsf.org/blogs/licensing/20050211.html
  53. ^ https://sqlite.org/different.html#license
  54. ^ http://wiseearthtechnology.com/blog/peaceful-open-source-license
  55. ^ https://mindprod.com/contact/nonmil.html
  56. ^ https://github.com/lerna/lerna/pull/1616
  57. ^ https://apebox.org/wordpress/rants/456
  58. ^ https://wonko.com/post/jsmin-isnt-welcome-on-google-code
  59. ^ https://www.linux.com/news/open-source-project-adds-no-military-use-clause-gpl/
  60. ^ https://commonsclause.com/
  61. ^ https://opensource.org/node/1099
  62. ^ "Política de derechos de autor de OpenBSD" . la restricción de que el código fuente debe distribuirse o estar disponible para todos los trabajos que sean derivados […] Como consecuencia, el software sujeto a los términos de la GPL no se puede incluir en el kernel o "runtime" de OpenBSD
  63. ^ "FreeBSD der unbekannte Riese" (en alemán).
  64. ^ "condiciones de uso" . El contenido que envíe no debe competir directamente con los productos ofrecidos por MathWorks. El contenido enviado a File Exchange solo se puede utilizar con productos MathWorks.
  65. ^ "Preguntas frecuentes sobre la transición de licencias de intercambio de archivos" .
  66. ^ "¿Por qué no puedo usar código de File Exchange en Octave? ¡Se publica bajo una licencia BSD!" .
  67. ^ "¿Libertad o poder? Por Bradley Kuhn y Richard Stallman" .
  68. ^ "Objetivos" .
  69. ^ "Preguntas frecuentes sobre las licencias GNU: ¿Por qué no usa la GPL para los manuales?" . Consultado el 20 de junio de 2009 .
  70. ^ Braakman, Richard. "Re: declaración propuesta wrt GNU FDL" . Debian-legal (lista de correo).
  71. ^ Srivastava, Manoj (2006). "Borrador de la 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 libre. Esta no es una mera incompatibilidad de licencia. No es solo que la GFDL sea incompatible con esta o aquella licencia de software libre: es que es fundamentalmente incompatible con cualquier licencia de software libre. Por lo tanto, si escribe un programa nuevo y no tiene ningún compromiso sobre la licencia que 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 trabajos con licencia bajo GNU FDL en nuestra distribución.
  72. ^ 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 .
  73. ^ Bruce Perens (2 de septiembre de 2003). "interviniendo entre Debian y FSF" . listas.debian.org/debian-legal . Consultado el 20 de marzo de 2016 . FSF, una organización de software libre, no está siendo completamente fiel al espíritu del software libre mientras promueve una licencia que permite que las secciones invariables se apliquen a cualquier cosa que no sea el texto y la atribución de la licencia. FSF no es Creative Commons: la documentación que maneja FSF es un componente esencial del Software Libre de FSF y debe tratarse como tal. En ese sentido, la GFDL no es coherente con el espíritu que la FSF ha promovido durante 19 años.
  74. ^ "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 .
  75. ^ Fundación de manuales FLOSS (6 de junio de 2007). "Cambio de licencia" . Blog de manuales de FLOSS . Fundación Manuales FLOSS. Archivado desde el original el 28 de febrero de 2008 . Consultado el 20 de junio de 2009 .
  76. ^ "Transcripción de Richard Stallman en la 3ª conferencia internacional GPLv3" . Fundación de Software Libre de Europa. 22 de junio de 2006 . Consultado el 23 de julio de 2017 .
  77. ^ Sam Varghese (7 de febrero de 2012). "Aumento del uso de GPL en Debian: estudio" . Itwire.com . Consultado el 2 de septiembre de 2013 .
  78. ^ "Encuesta de licencias de código abierto" . Lwn.net . Consultado el 2 de septiembre de 2013 .

Referencias [ editar ]

  • Rosen, Lawrence (22 de julio de 2004). Licencias de código abierto: Ley de libertad de software y propiedad intelectual . Prentice Hall. ISBN 978-0-13-148787-1.

Enlaces externos [ editar ]

  • La Definición de Software Libre , de la Free Software Foundation.
  • Lista de licencias gratuitas y no libres de la Free Software Foundation
  • Página de información de licencia de Debian
  • Lista de licencias de Open Source Initiative
  • La página de "objetivos" de OpenBSD describe su visión del software libre
  • Transcripciones de las discusiones sobre la estrategia de licencias. Archivado el 21 de febrero de 2009 en Wayback Machine , principalmente de Stallman y Moglen, durante la redacción de la GPLv3.
  • Comprensión de las licencias de software libre y de código abierto , por Andrew M. St. Laurent
  • Informe sobre licencias y modelos comerciales de software libre (58 páginas)
  • Una cartilla de licencias de 45 páginas por Software Freedom Law Center
  • Mejores prácticas de código abierto