Las Licencias Públicas Generales de GNU ( GNU GPL o simplemente GPL ) son una serie de licencias de software libre ampliamente utilizadas , o licencias copyleft , que garantizan a los usuarios finales las libertades de ejecutar, estudiar, compartir y modificar el software. [7] La licencia fue la primera copyleft para uso general y fue escrita originalmente por Richard Stallman , el fundador de la Free Software Foundation (FSF), para el Proyecto GNU . La licencia otorga a los destinatarios de un programa de computadora los derechos de la Definición de Software Libre . [8] Las licencias de la serie GPL son todas licencias copyleft, lo que significa que cualquier trabajo derivado debe distribuirse bajo los mismos términos de licencia o equivalentes. Es más restrictiva que la Licencia Pública General Menor e incluso más distinta de las licencias de software permisivas más utilizadas, como BSD , MIT y Apache .
Históricamente, la familia de licencias GPL ha sido una de las licencias de software más populares en el dominio del software libre y de código abierto (FOSS). [7] [9] [10] [11] [12] Entre los programas de software libre más destacados licenciados bajo la GPL se encuentran el núcleo Linux y la Colección de compiladores GNU (GCC). David A. Wheeler sostiene que el copyleft proporcionado por la GPL fue crucial para el éxito de los sistemas basados en Linux , ya que dio a los programadores que contribuyeron al núcleo la seguridad de que su trabajo beneficiaría a todo el mundo y seguiría siendo libre, en lugar de ser explotado por empresas de software que no tendrían que dar nada a cambio a la comunidad. [13]
En 2007, se lanzó la tercera versión de la licencia (GPLv3) para abordar algunos problemas percibidos con la segunda versión (GPLv2) que se descubrieron durante el uso prolongado de esta última.
Para mantener la licencia vigente, la licencia GPL incluye una cláusula opcional de "cualquier versión posterior", que permite a los usuarios elegir entre los términos originales o los términos de las nuevas versiones actualizadas por la FSF. Entre los proyectos de software licenciados con la cláusula opcional "o posterior" se encuentra el Proyecto GNU, mientras que el núcleo Linux, por ejemplo, está licenciado únicamente bajo la GPLv2.
La cláusula "o cualquier versión posterior" a veces se conoce como "cláusula de salvavidas", ya que permite combinaciones entre diferentes versiones de software con licencia GPL para mantener la compatibilidad.
La GPL original fue escrita por Richard Stallman en 1989, para su uso con programas publicados como parte del proyecto GNU. Se basó en una unificación de licencias similares utilizadas para las primeras versiones de GNU Emacs (1985), [14] el depurador GNU y el compilador C GNU . [15] Estas licencias contenían disposiciones similares a la GPL moderna, pero eran específicas para cada programa, lo que las hacía incompatibles, a pesar de ser la misma licencia. [16] El objetivo de Stallman era producir una licencia que pudiera usarse para cualquier proyecto, haciendo posible así que muchos proyectos compartieran código.
La segunda versión de la licencia, la versión 2, fue lanzada en 1991. Durante los siguientes 15 años, los miembros de la comunidad de software libre comenzaron a preocuparse por los problemas en la licencia GPLv2 que podrían permitir que alguien explotara software con licencia GPL de maneras contrarias a la intención de la licencia. [17] Estos problemas incluían la tivoización (la inclusión de software con licencia GPL en hardware que se niega a ejecutar versiones modificadas de su software), problemas de compatibilidad similares a los de la AGPL (v1) y acuerdos de patentes entre Microsoft y distribuidores de software libre y de código abierto, que algunos vieron como un intento de usar las patentes como un arma contra la comunidad de software libre.
La versión 3 se desarrolló como un intento de abordar estas preocupaciones y se lanzó oficialmente el 29 de junio de 2007. [18]
La versión 1 de la GPL de GNU, [19] publicada el 25 de febrero de 1989, [20] fue escrita para protegerse contra los dos métodos principales por los cuales los distribuidores de software restringían las libertades que definen al software libre. El primer problema era que los distribuidores podían publicar sólo archivos binarios que fueran ejecutables, pero no legibles ni modificables por humanos. Para evitar esto, la GPLv1 establecía que la copia y distribución de copias de cualquier parte del programa también debía hacer que el código fuente legible por humanos estuviera disponible bajo los mismos términos de licencia. [a]
El segundo problema era que los distribuidores podían añadir restricciones, ya fuera a la licencia o combinando el software con otro software que tuviera otras restricciones de distribución. La unión de dos conjuntos de restricciones se aplicaría a la obra combinada, añadiendo así restricciones inaceptables. Para evitarlo, la GPLv1 establecía que las versiones modificadas, en su conjunto, debían distribuirse bajo los términos de la GPLv1. [b] Por tanto, el software distribuido bajo los términos de la GPLv1 podía combinarse con software bajo términos más permisivos, ya que esto no cambiaría los términos bajo los que se podía distribuir el conjunto. Sin embargo, el software distribuido bajo la GPLv1 no podía combinarse con software distribuido bajo una licencia más restrictiva, ya que esto entraría en conflicto con el requisito de que el conjunto fuera distribuible bajo los términos de la GPLv1.
Según Richard Stallman, el cambio más importante en la GPLv2 fue la cláusula de "libertad o muerte", como él la llama [16] – Sección 7. La sección dice que los licenciatarios pueden distribuir una obra amparada por la GPL sólo si pueden satisfacer todas las obligaciones de la licencia, a pesar de cualquier otra obligación legal que puedan tener. En otras palabras, las obligaciones de la licencia no pueden ser separadas debido a obligaciones conflictivas. Esta disposición tiene por objeto disuadir a cualquier parte de utilizar una demanda por infracción de patente u otro litigio para perjudicar la libertad de los usuarios bajo la licencia. [16]
En 1990, se hizo evidente que una licencia menos restrictiva sería estratégicamente útil para la biblioteca C y para las bibliotecas de software que básicamente hacían el trabajo de las propietarias existentes; [21] cuando se publicó la versión 2 de la GPL (GPLv2) en junio de 1991, se introdujo al mismo tiempo una segunda licencia – la Licencia Pública General de Bibliotecas GNU – y se la numeró con la versión 2 para mostrar que ambas eran complementarias. [22] Los números de versión divergieron en 1999 cuando se publicó la versión 2.1 de la LGPL, que la renombró Licencia Pública General Reducida de GNU para reflejar su lugar en la filosofía. La GPLv2 también se modificó para hacer referencia al nuevo nombre de la LGPL, pero su número de versión siguió siendo el mismo, lo que provocó que la GPLv2 original no fuera reconocida por el Intercambio de Datos de Paquetes de Software (SPDX). [23] [ verificación fallida ]
La licencia incluye instrucciones para especificar "versión 2 de la Licencia o (a su elección) cualquier versión posterior" para permitir el uso opcional flexible de la versión 2 o 3, pero algunos desarrolladores cambian esto para especificar solo "versión 2".
A finales de 2005, la Free Software Foundation (FSF) anunció que estaba trabajando en la versión 3 de la GPL (GPLv3). El 16 de enero de 2006 se publicó el primer "borrador de discusión" de la GPLv3 y comenzó la consulta pública. La consulta pública se había planeado originalmente para que durara entre nueve y quince meses, pero finalmente duró dieciocho meses y se publicaron cuatro borradores. La GPLv3 oficial fue publicada por la FSF el 29 de junio de 2007. La GPLv3 fue escrita por Richard Stallman, con el asesoramiento legal de Eben Moglen y Richard Fontana del Software Freedom Law Center . [24] [25]
Según Stallman, los cambios más importantes se relacionaron con las patentes de software , la compatibilidad de licencias de software libre , la definición de "código fuente" y las restricciones de hardware sobre modificaciones de software, como la tivoización . [24] [26] Otros cambios se relacionaron con la internacionalización, cómo se manejan las violaciones de licencias y cómo el titular de los derechos de autor podría otorgar permisos adicionales. El concepto de "propagación de software", como término para la copia y duplicación de software, se definió explícitamente.
El proceso de consulta pública fue coordinado por la Free Software Foundation con la ayuda del Software Freedom Law Center, la Free Software Foundation Europe [27] y otros grupos de software libre. Los comentarios del público se recogieron a través del portal web gplv3.fsf.org [28] , utilizando un software creado específicamente para este fin llamado stet .
Durante el proceso de consulta pública se recibieron 962 comentarios sobre el primer borrador. [29] Al final del período de comentarios, se habían presentado un total de 2.636 comentarios. [30]
El tercer borrador se publicó el 28 de marzo de 2007. [31] Este borrador incluía un lenguaje destinado a evitar acuerdos relacionados con patentes, como el controvertido acuerdo de patentes Microsoft-Novell , y restringía las cláusulas anti-tivoización a una definición legal de "usuario" y "producto de consumo". También eliminaba explícitamente la sección sobre "Limitaciones geográficas", ya que la probable eliminación de esta sección se había anunciado al inicio de la consulta pública.
El cuarto borrador de discusión, [32] que fue el último, se publicó el 31 de mayo de 2007. Introdujo la compatibilidad con la versión 2.0 de la Licencia Apache (las versiones anteriores son incompatibles), aclaró el papel de los contratistas externos e hizo una excepción para evitar los problemas percibidos de un acuerdo al estilo Microsoft-Novell, diciendo en la Sección 11, párrafo 6, que:
No puede transmitir una obra cubierta si es parte de un acuerdo con un tercero que se dedica a distribuir software, en virtud del cual usted realiza un pago al tercero en función del alcance de su actividad de transmisión de la obra, y en virtud del cual el tercero otorga, a cualquiera de las partes que recibirían la obra cubierta de usted, una licencia de patente discriminatoria ...
El objetivo de esta licencia era hacer que esos acuerdos futuros no tuvieran efecto. También pretendía que Microsoft extendiera las licencias de patentes que concedía a los clientes de Novell para el uso del software GPLv3 a todos los usuarios de ese software GPLv3; esto sólo era posible si Microsoft era legalmente un "transmisor" del software GPLv3. [33]
Los primeros borradores de la GPLv3 también permitían a los licenciantes añadir un requisito similar a la AGPL que habría tapado la laguna de la ASP en la GPL . [34] [35] Como se expresaron preocupaciones sobre los costos administrativos de verificar el código para este requisito adicional, se decidió mantener separadas la GPL y la licencia AGPL. [36]
Otros, en particular algunos desarrolladores de núcleo Linux de alto perfil como Linus Torvalds , Greg Kroah-Hartman y Andrew Morton , comentaron a los medios de comunicación e hicieron declaraciones públicas sobre sus objeciones a partes de los borradores de discusión 1 y 2. [37] Los desarrolladores del núcleo se refirieron a las cláusulas del borrador de la GPLv3 sobre DRM / Tivoización , patentes y "restricciones adicionales", y advirtieron sobre una balcanización del "Universo de Código Abierto". [37] [38] Linus Torvalds, que decidió no adoptar la GPLv3 para el núcleo Linux, [39] reiteró sus críticas varios años después. [40] [41]
La GPLv3 mejoró la compatibilidad con varias licencias de software libre, como la Licencia Apache, versión 2.0, y la Licencia Pública General Affero de GNU, con las que no se podía combinar la GPLv2. [42] Sin embargo, el software GPLv3 solo se podía combinar y compartir código con el software GPLv2 si la licencia GPLv2 utilizada tenía la cláusula opcional "o posterior" y el software se actualizaba a GPLv3. Si bien la cláusula "GPLv2 o cualquier versión posterior" es considerada por la FSF como la forma más común de licenciar software GPLv2, [43] el desarrollador de Toybox, Rob Landley, la describió como una cláusula salvavidas . [c] Los proyectos de software licenciados con la cláusula opcional "o posterior" incluyen el Proyecto GNU , [ cita requerida ] mientras que un ejemplo destacado sin la cláusula es el núcleo Linux. [39] [46]
La versión final del texto de la licencia se publicó el 29 de junio de 2007. [47]
Los términos y condiciones de la GPL deben ponerse a disposición de todo aquel que reciba una copia de una obra a la que se le aplica una GPL ("el licenciatario"). Cualquier licenciatario que se adhiera a los términos y condiciones tiene permiso para modificar la obra, así como para copiar y redistribuir la obra o cualquier versión derivada. El licenciatario puede cobrar una tarifa por este servicio o hacerlo de forma gratuita. Este último punto distingue a la GPL de las licencias de software que prohíben la redistribución comercial. La FSF sostiene que el software libre no debería imponer restricciones al uso comercial, [48] y la GPL establece explícitamente que las obras GPL pueden venderse a cualquier precio.
La GPL también establece que un distribuidor no puede imponer "restricciones adicionales a los derechos otorgados por la GPL". Esto prohíbe actividades como la distribución del software bajo un acuerdo o contrato de confidencialidad.
La cuarta sección de la versión 2 de la licencia y la séptima sección de la versión 3 exigen que los programas distribuidos como binarios precompilados vayan acompañados de una copia del código fuente, una oferta escrita para distribuir el código fuente a través del mismo mecanismo que el binario precompilado, o la oferta escrita para obtener el código fuente que el usuario obtuvo cuando recibió el binario precompilado bajo la GPL. La segunda sección de la versión 2 y la quinta sección de la versión 3 también exigen que se dé "a todos los destinatarios una copia de esta Licencia junto con el Programa". La versión 3 de la licencia permite hacer disponible el código fuente de otras maneras en cumplimiento de la séptima sección. Estas incluyen la descarga del código fuente desde un servidor de red adyacente o mediante transmisión de igual a igual, siempre que así sea como el código compilado estaba disponible y haya "instrucciones claras" sobre dónde encontrarlo.
La FSF no posee los derechos de autor de una obra publicada bajo la GPL a menos que un autor le asigne explícitamente los derechos de autor (lo que rara vez ocurre, excepto en el caso de los programas que forman parte del proyecto GNU). Sólo los titulares individuales de los derechos de autor tienen la autoridad para demandar cuando se sospecha una violación de la licencia.
El software bajo la GPL puede ejecutarse para todos los fines, incluidos los comerciales e incluso como herramienta para crear software propietario , como cuando se utilizan compiladores con licencia GPL . [49] Los usuarios o empresas que distribuyen obras con licencia GPL (por ejemplo, software), pueden cobrar una tarifa por las copias o entregarlas de forma gratuita. Esto distingue a la GPL de las licencias de software shareware que permiten la copia para uso personal pero prohíben la distribución comercial o las licencias propietarias donde la copia está prohibida por la ley de derechos de autor . La FSF sostiene que el software libre respetuoso con la libertad tampoco debería restringir el uso y la distribución comerciales (incluida la redistribución): [48]
En el caso de un uso puramente privado (o interno), sin ventas ni distribución, el código del software puede modificarse y reutilizarse en partes sin necesidad de que se publique el código fuente. Para la venta o distribución, es necesario poner a disposición de los usuarios finales todo el código fuente, incluidos los cambios y añadidos al código; en ese caso, se aplica el copyleft para garantizar que los usuarios finales conserven las libertades definidas anteriormente. [50]
Sin embargo, el software que se ejecuta como un programa de aplicación bajo un sistema operativo con licencia GPL como Linux no necesita tener licencia GPL o distribuirse con disponibilidad de código fuente; la licencia depende solo de las bibliotecas y componentes de software utilizados y no de la plataforma subyacente. [51] Por ejemplo, si un programa consiste solo en código fuente original , o se combina con código fuente de otros componentes de software , [d] entonces los componentes de software personalizados no necesitan tener licencia GPL y no necesitan hacer disponible su código fuente; incluso si el sistema operativo subyacente utilizado tiene licencia GPL, las aplicaciones que se ejecutan en él no se consideran trabajos derivados. [51] Solo si se usan partes con licencia GPL en un programa (y el programa se distribuye), entonces todo el resto del código fuente del programa debe estar disponible bajo los mismos términos de licencia. La Licencia Pública General Reducida de GNU (LGPL) fue creada para tener un copyleft más débil que la GPL, en el sentido de que no requiere que el código fuente desarrollado a medida (distinto de las partes con licencia LGPL) esté disponible bajo los mismos términos de licencia.
La quinta sección de la versión 3 establece que ningún código con licencia GPL se considerará una "medida de protección técnica" eficaz según la definición del Artículo 11 del Tratado de la OMPI sobre Derecho de Autor , y que quienes transmitan la obra renuncian a todo poder legal para prohibir la elusión de la medida de protección técnica "en la medida en que dicha elusión se efectúe ejerciendo derechos bajo esta Licencia con respecto a la obra amparada". Esto significa que los usuarios no pueden ser considerados responsables de eludir la DRM implementada utilizando código con licencia GPLv3 según leyes como la Ley de Derechos de Autor del Milenio Digital (DMCA) de los Estados Unidos. [52]
Los derechos de distribución que concede la GPL para las versiones modificadas de una obra no son incondicionales. Cuando alguien distribuye una obra con licencia GPL más sus propias modificaciones, los requisitos para distribuir la obra completa no pueden ser mayores que los requisitos que se establecen en la GPL.
Este requisito se conoce como copyleft. Su poder legal se deriva del uso de los derechos de autor en programas de software. Como una obra GPL está protegida por derechos de autor, el licenciatario no tiene derecho a redistribuirla, ni siquiera en forma modificada (salvo en el caso de uso legítimo ), excepto en virtud de los términos de la licencia. Solo se exige que uno cumpla los términos de la GPL si desea ejercer derechos normalmente restringidos por la ley de derechos de autor, como la redistribución. Por el contrario, si uno distribuye copias de la obra sin cumplir los términos de la GPL (por ejemplo, manteniendo en secreto el código fuente), puede ser demandado por el autor original en virtud de la ley de derechos de autor.
Históricamente, la legislación sobre derechos de autor se ha utilizado para impedir la distribución de obras por terceros no autorizados por el creador. El copyleft utiliza las mismas leyes de derechos de autor para lograr un objetivo muy diferente: concede derechos de distribución a todas las partes siempre que otorguen los mismos derechos a las partes posteriores, y éstas a la siguiente, etc. De esta manera, la GPL y otras licencias copyleft intentan imponer el libre acceso a la obra y a todos sus derivados. [53]
Muchos distribuidores de programas con licencia GPL incluyen el código fuente junto con los ejecutables . Un método alternativo para satisfacer la exigencia de copyleft es proporcionar una oferta por escrito para proporcionar el código fuente en un medio físico (como un CD) si se solicita. En la práctica, muchos programas con licencia GPL se distribuyen a través de Internet y el código fuente se pone a disposición a través de FTP o HTTP . Para la distribución a través de Internet, esto cumple con la licencia.
El copyleft se aplica únicamente cuando una persona busca redistribuir el programa. Los desarrolladores pueden hacer versiones modificadas privadas sin obligación de divulgar las modificaciones, siempre y cuando no distribuyan el software modificado a nadie más. El copyleft se aplica únicamente al software, y no a su resultado (a menos que el resultado sea en sí mismo un trabajo derivado del programa). [e] Por ejemplo, un portal web público que ejecuta un derivado modificado de un sistema de gestión de contenido con licencia GPL no está obligado a distribuir sus cambios al software subyacente, porque el portal web modificado no se está redistribuyendo sino que se está alojando, y también porque el resultado del portal web tampoco es un trabajo derivado del sistema de gestión de contenido con licencia GPL.
Se ha debatido si es una violación de la GPLv1 publicar el código fuente en forma ofuscada , como en los casos en que el autor no está dispuesto a ponerlo a disposición. El consenso fue que, si bien no es ético, no se considera una violación. La cuestión se aclaró cuando se modificó la licencia con la v2 para exigir que se pusiera a disposición la versión "preferida" del código fuente. [55]
La GPL fue diseñada como una licencia , más que como un contrato. [56] En algunas jurisdicciones de derecho consuetudinario , la distinción legal entre una licencia y un contrato es importante: los contratos se pueden hacer cumplir por la ley contractual , mientras que las licencias se hacen cumplir por la ley de derechos de autor . Sin embargo, esta distinción no es útil en las muchas jurisdicciones donde no hay diferencias entre contratos y licencias, como los sistemas de derecho civil . [57]
Quienes no acepten los términos y condiciones de la GPL no tienen permiso, según la ley de derechos de autor, para copiar o distribuir software con licencia GPL o trabajos derivados. Sin embargo, si no redistribuyen el programa con licencia GPL, pueden utilizar el software dentro de su organización como quieran, y los trabajos (incluidos los programas) creados mediante el uso del programa no están necesariamente cubiertos por esta licencia.
La desarrolladora de software Allison Randal argumentó que la GPLv3 como licencia es innecesariamente confusa para los lectores comunes y podría simplificarse manteniendo las mismas condiciones y fuerza legal. [58]
En abril de 2017, un tribunal federal de Estados Unidos dictaminó que una licencia de código abierto es un contrato exigible. [59]
En octubre de 2021, la SFC demandó a Vizio por incumplimiento de contrato como usuario final al solicitar el código fuente de los televisores Vizio; un juez federal dictaminó de forma provisional que la GPL es un contrato exigible por los usuarios finales, así como una licencia para los titulares de derechos de autor. [60]
El texto de la GPL está protegido por derechos de autor , y dichos derechos pertenecen a la Free Software Foundation.
La FSF permite que las personas creen nuevas licencias basadas en la GPL, siempre y cuando las licencias derivadas no utilicen el preámbulo de la GPL sin permiso. Sin embargo, esto no se recomienda, ya que una licencia de este tipo podría ser incompatible con la GPL [61] y provocar una proliferación percibida de licencias .
Otras licencias creadas por el proyecto GNU incluyen la Licencia Pública General Reducida GNU , la Licencia de Documentación Libre GNU y la Licencia Pública General Affero GNU .
El texto de la GPL no está incluido en la licencia. Los derechos de autor de la licencia no permiten modificarla. Se permite copiar y distribuir la licencia ya que la GPL exige que los destinatarios obtengan "una copia de esta Licencia junto con el Programa". [62] Según las FAQ de la GPL, cualquiera puede crear una nueva licencia utilizando una versión modificada de la GPL siempre que utilice un nombre diferente para la licencia, no mencione "GNU" y elimine el preámbulo, aunque el preámbulo puede utilizarse en una licencia modificada si se obtiene permiso para usarlo de la Free Software Foundation (FSF). [63]
Según la FSF, "la GPL no exige que se publique la versión modificada o cualquier parte de ella. Se es libre de realizar modificaciones y utilizarlas de forma privada, sin necesidad de publicarlas nunca". [64] Sin embargo, si se publica una entidad con licencia GPL, existe un problema con respecto a los enlaces: es decir, si un programa propietario que utiliza una biblioteca GPL infringe la GPL.
La disputa clave es si el software que no está bajo la GPL puede legalmente vincularse estáticamente o dinámicamente a bibliotecas GPL. Existen diferentes opiniones sobre esta cuestión. La GPL es clara al exigir que todos los trabajos derivados de código bajo la GPL deben estar a su vez bajo la GPL. Surge una ambigüedad con respecto al uso de bibliotecas GPL y la inclusión de software GPL en un paquete más grande (quizás mezclado en un binario mediante enlaces estáticos). En última instancia, no se trata de una cuestión de la GPL en sí , sino de cómo la ley de derechos de autor define los trabajos derivados. Existen los siguientes puntos de vista:
La Free Software Foundation (que posee los derechos de autor de varios productos de software con licencia GPL y del propio texto de la licencia) afirma que un ejecutable que utiliza una biblioteca vinculada dinámicamente es, en efecto, un trabajo derivado. Sin embargo, esto no se aplica a programas separados que se comunican entre sí. [65]
La Free Software Foundation también creó la LGPL , que es casi idéntica a la GPL, pero con permisos adicionales para permitir enlaces con el propósito de "usar la biblioteca".
Richard Stallman y la FSF alientan específicamente a los autores de bibliotecas a utilizar licencias bajo la GPL para que los programas propietarios no puedan usar las bibliotecas, en un esfuerzo por proteger el mundo del software libre dándole más herramientas que al mundo propietario. [66]
Algunas personas creen que, si bien los enlaces estáticos producen obras derivadas, no está claro si un ejecutable que se vincula dinámicamente a un código GPL debería considerarse una obra derivada (véase copyleft débil ). El autor de Linux Linus Torvalds está de acuerdo en que los enlaces dinámicos pueden crear obras derivadas, pero no está de acuerdo con las circunstancias. [67]
Un abogado de Novell ha escrito que el hecho de que los enlaces dinámicos no sean derivados "tiene sentido" pero no es "claro", y que la evidencia de que los enlaces dinámicos son bien intencionados se puede ver en la existencia de controladores de kernel Linux propietarios. [68]
En Galoob v. Nintendo , el Tribunal de Apelaciones del Noveno Circuito de los Estados Unidos definió una obra derivada como aquella que tiene " 'forma' o permanencia" y señaló que "la obra infractora debe incorporar una parte de la obra protegida por derechos de autor en alguna forma", [69] pero no ha habido decisiones judiciales claras para resolver este conflicto en particular.
Según un artículo publicado en Linux Journal , Lawrence Rosen (antiguo asesor general de la Iniciativa de Código Abierto ) sostiene que el método de vinculación es en su mayor parte irrelevante para la cuestión de si un software es un trabajo derivado ; más importante es la cuestión de si el software estaba destinado a interactuar con el software cliente y/o las bibliotecas. [70] Afirma: "La principal indicación de si un nuevo programa es un trabajo derivado es si el código fuente del programa original se utilizó [en un sentido de copiar y pegar], se modificó, se tradujo o se cambió de alguna otra manera para crear el nuevo programa. Si no es así, entonces yo diría que no es un trabajo derivado", [70] y enumera numerosos otros puntos relacionados con la intención, la agrupación y el mecanismo de vinculación. Además, argumenta en el sitio web de su empresa [71] que dichos factores "basados en el mercado" son más importantes que la técnica de vinculación.
También está la cuestión específica de si un complemento o módulo (como los módulos del núcleo de las tarjetas gráficas NVidia o ATI ) también debe ser GPL si se puede considerar razonablemente que es un trabajo propio. Este punto de vista sugiere que los complementos razonablemente separados, o los complementos para software diseñado para utilizar complementos, podrían licenciarse bajo una licencia arbitraria si el trabajo es GPLv2. De particular interés es el párrafo GPLv2:
Puede modificar su copia o copias del Programa o cualquier parte del mismo, formando así un trabajo basado en el Programa, y copiar y distribuir dichas modificaciones o trabajo bajo los términos de la Sección 1 anterior, siempre que también cumpla con todas estas condiciones: ...
b) Usted debe hacer que cualquier trabajo que distribuya o publique, que en su totalidad o en parte contenga o se derive del Programa o cualquier parte del mismo, sea licenciado como un todo sin cargo para todos los terceros bajo los términos de esta Licencia. ... Estos requisitos se aplican al trabajo modificado como un todo. Si secciones identificables de ese trabajo no se derivan del Programa y pueden considerarse razonablemente trabajos independientes y separados en sí mismos, entonces esta Licencia y sus términos no se aplican a esas secciones cuando las distribuya como trabajos separados. Pero cuando distribuya las mismas secciones como parte de un todo que es un trabajo basado en el Programa, la distribución del todo debe realizarse bajo los términos de esta Licencia, cuyos permisos para otros licenciatarios se extienden al todo, y por lo tanto a todas y cada una de las partes, independientemente de quién la haya escrito.
La GPLv3 tiene una cláusula diferente:
Usted puede transmitir una obra basada en el Programa o las modificaciones para producirla a partir del Programa, en forma de código fuente bajo los términos de la Sección 4, siempre que también cumpla con todas estas condiciones: ...
c) Usted debe licenciar la obra completa, como un todo, bajo esta Licencia a cualquier persona que entre en posesión de una copia. Por lo tanto, esta Licencia se aplicará, junto con cualquier término adicional aplicable de la Sección 7, a la totalidad de la obra y todas sus partes, independientemente de cómo estén empaquetadas. Esta Licencia no otorga permiso para licenciar la obra de ninguna otra manera, pero no invalida dicho permiso si usted la ha recibido por separado. ... Una compilación de una obra amparada con otras obras separadas e independientes, que no son por su naturaleza extensiones de la obra amparada, y que no están combinadas con ella de modo que formen un programa más grande, en o sobre un volumen de un medio de almacenamiento o distribución, se denomina "agregado" si la compilación y su copyright resultante no se utilizan para limitar el acceso o los derechos legales de los usuarios de la compilación más allá de lo que permiten las obras individuales. La inclusión de una obra amparada en un agregado no hace que esta Licencia se aplique a las otras partes del agregado.
Como caso de estudio, algunos complementos y temas / skins supuestamente propietarios para software CMS GPLv2 como Drupal y WordPress han sido objeto de críticas, con ambos lados del argumento tomados. [72]
La FSF diferencia la forma en que se invoca el complemento. Si el complemento se invoca a través de un enlace dinámico y realiza llamadas de función al programa GPL, lo más probable es que se trate de un trabajo derivado. [73]
El mero acto de comunicarse con otros programas no exige, por sí mismo, que todo el software sea GPL; tampoco lo exige la distribución de software GPL junto con software que no lo sea. Sin embargo, se deben cumplir unas condiciones menores que aseguren que los derechos del software GPL no se vean restringidos. A continuación se incluye una cita de las preguntas frecuentes sobre la GPL de gnu.org , que describen hasta qué punto se permite que el software se comunique con los programas GPL y se incluya con ellos: [74]
¿Cuál es la diferencia entre un “agregado” y otros tipos de “versiones modificadas”?
Un "conjunto" consiste en una serie de programas separados, distribuidos juntos en el mismo CD-ROM u otro medio. La GPL permite crear y distribuir un conjunto, incluso cuando las licencias del otro software no sean libres o incompatibles con la GPL. La única condición es que no se puede publicar el conjunto bajo una licencia que prohíba a los usuarios ejercer los derechos que les otorgaría la licencia individual de cada programa.
¿Dónde está la línea divisoria entre dos programas separados y un programa con dos partes? Esta es una cuestión legal, que en última instancia decidirán los jueces. Creemos que un criterio adecuado depende tanto del mecanismo de comunicación (exec, pipes, rpc, llamadas a funciones dentro de un espacio de direcciones compartido, etc.) como de la semántica de la comunicación (qué tipos de información se intercambian).
Si los módulos están incluidos en el mismo archivo ejecutable, seguramente se combinan en un solo programa. Si los módulos están diseñados para ejecutarse vinculados entre sí en un espacio de direcciones compartido, eso casi seguramente significa combinarlos en un solo programa.
Por el contrario, las tuberías, los sockets y los argumentos de la línea de comandos son mecanismos de comunicación que normalmente se utilizan entre dos programas separados. Por lo tanto, cuando se utilizan para la comunicación, los módulos normalmente son programas separados. Pero si la semántica de la comunicación es lo suficientemente íntima, intercambiando estructuras de datos internas complejas, eso también podría ser una base para considerar las dos partes como combinadas en un programa más grande.
La FSF traza así la línea entre "biblioteca" y "otro programa" a través de 1) la "complejidad" e "intimidad" del intercambio de información y 2) el mecanismo (más que la semántica), pero resigna que la cuestión no está clara y que en situaciones complejas la jurisprudencia decidirá.
La primera violación conocida de la GPL fue en 1989, cuando NeXT amplió el compilador GCC para que fuera compatible con Objective-C , pero no publicó los cambios. [75] Después de una investigación, crearon un parche público . No se presentó ninguna demanda por esta violación. [76]
En 2002, MySQL AB demandó a Progress NuSphere por violación de derechos de autor y marca registrada en un tribunal de distrito de los Estados Unidos . NuSphere supuestamente había violado los derechos de autor de MySQL al vincular el código con licencia GPL de MySQL con la tabla Gemini de NuSphere sin cumplir con la licencia. Después de una audiencia preliminar ante la jueza Patti Saris el 27 de febrero de 2002, las partes iniciaron conversaciones para llegar a un acuerdo y finalmente llegaron a un acuerdo. [f] Después de la audiencia, la FSF comentó que "la jueza Saris dejó en claro que considera que la GPL de GNU es una licencia ejecutable y vinculante". [77]
En agosto de 2003, el Grupo SCO declaró que creía que la GPL no tenía validez legal y que tenía la intención de presentar demandas por secciones de código supuestamente copiadas de SCO Unix en el núcleo Linux . Esta fue una postura problemática para ellos, ya que habían distribuido Linux y otro código con licencia GPL en su distribución Caldera OpenLinux , y hay poca evidencia de que tuvieran algún derecho legal para hacerlo excepto bajo los términos de la GPL. [ cita requerida ] En febrero de 2018, después de la sentencia del tribunal de circuito federal, la apelación y la devolución (parcial) del caso al tribunal de circuito, las partes reafirmaron sus reclamaciones restantes y proporcionaron un plan para avanzar hacia la sentencia final. [78] Las reclamaciones restantes giraban en torno al Proyecto Monterey y finalmente se resolvieron en noviembre de 2021 cuando IBM pagó 14,25 millones de dólares al síndico de quiebras de TSG (anteriormente SCO). [79]
En abril de 2004, el proyecto netfilter / iptables recibió una orden judicial preliminar contra Sitecom Alemania por parte del Tribunal de Distrito de Múnich después de que Sitecom se negara a desistir de distribuir el software con licencia GPL de Netfilter en violación de los términos de la GPL. Harald Welte , de Netfilter, estuvo representado por el cofundador de ifrOSS, Till Jaeger. En julio de 2004, el tribunal alemán confirmó esta orden judicial como sentencia definitiva contra Sitecom. [80] La justificación del tribunal fue que:
Esto reflejaba exactamente las predicciones dadas previamente por Eben Moglen de la FSF. Esta decisión fue importante porque fue la primera vez que un tribunal había confirmado que violar los términos de la GPL podía ser una violación de los derechos de autor y había establecido jurisprudencia en cuanto a la aplicabilidad de la GPLv2 bajo la ley alemana. [81]
En mayo de 2005, Daniel Wallace presentó una demanda contra la Free Software Foundation en el Distrito Sur de Indiana , alegando que la GPL es un intento ilegal de fijar precios (a cero). La demanda fue desestimada en marzo de 2006, con el argumento de que Wallace no había presentado una demanda antimonopolio válida; el tribunal señaló que "la GPL fomenta, en lugar de desalentar, la libre competencia y la distribución de sistemas operativos informáticos, cuyos beneficios pasan directamente a los consumidores". [82] A Wallace se le negó la posibilidad de enmendar aún más su demanda y se le ordenó pagar los gastos legales de la FSF.
El 8 de septiembre de 2005, el Tribunal del Distrito Central de Seúl dictaminó que la GPL no era pertinente en un caso que trataba de secretos comerciales derivados de obras con licencia GPL. [83] Los demandados argumentaron que, dado que es imposible mantener secretos comerciales mientras se cumple con la GPL y se distribuye la obra, no están infringiendo la ley de secretos comerciales. Este argumento se consideró infundado.
El 6 de septiembre de 2006, el proyecto gpl-violations.org ganó un litigio judicial contra D-Link Germany GmbH en relación con el uso infractor de derechos de autor por parte de D-Link de partes del núcleo Linux en los dispositivos de almacenamiento que distribuían. [84] La sentencia declaró que la GPL es válida, legalmente vinculante y se mantiene en un tribunal alemán. [85]
A finales de 2007, los desarrolladores de BusyBox y el Software Freedom Law Center se embarcaron en un programa para lograr que los distribuidores de BusyBox en sistemas integrados cumplieran con la GPL , demandando a quienes no la cumplieran. Se afirmó que estos eran los primeros usos de los tribunales en Estados Unidos para hacer cumplir las obligaciones de la GPL. (Véase Demandas por la GPL de BusyBox .)
El 11 de diciembre de 2008, la Free Software Foundation demandó a Cisco Systems, Inc. por violaciones de derechos de autor por parte de su división Linksys, de los paquetes de software con licencia GPL coreutils , readline , Parted , Wget , GNU Compiler Collection , binutils y GNU Debugger de la FSF , que Linksys distribuye en el firmware Linux [86] de sus enrutadores inalámbricos WRT54G , así como de otros numerosos dispositivos, incluidos módems DSL y de cable, dispositivos de almacenamiento conectado a red, puertas de enlace de voz sobre IP, dispositivos de red privada virtual y un dispositivo de cine en casa/reproductor multimedia. [87]
Después de seis años de reiteradas quejas de la FSF a Cisco , de afirmaciones de Cisco de que corregirían, o estaban corrigiendo, sus problemas de cumplimiento (no proporcionar copias completas de todo el código fuente y sus modificaciones), de repetidas nuevas violaciones descubiertas y reportadas con más productos, y de la falta de acción por parte de Linksys (un proceso descrito en el blog de la FSF como un "juego de Whack-a-Mole que dura cinco años" [87] ), la FSF los llevó a los tribunales.
Cisco resolvió el caso seis meses después al aceptar "designar un Director de Software Libre para Linksys" para garantizar el cumplimiento, "notificar a los destinatarios anteriores de productos Linksys que contenían programas de la FSF sobre sus derechos bajo la GPL", hacer que el código fuente de los programas de la FSF esté disponible gratuitamente en su sitio web y hacer una contribución monetaria a la FSF. [88]
En 2011, se advirtió que GNU Emacs había estado publicando accidentalmente algunos binarios sin el código fuente correspondiente durante dos años, en oposición al espíritu previsto de la GPL , lo que resultó en una violación de los derechos de autor . [89] Richard Stallman describió este incidente como un "error muy grave", [90] que se solucionó rápidamente. La FSF no demandó a ningún redistribuidor que también violara sin saberlo la GPL al distribuir estos binarios.
En 2017, Artifex, el creador de Ghostscript , demandó a Hancom , el creador de una suite ofimática que incluía Ghostscript. Artifex ofrece dos licencias para Ghostscript; una es la licencia AGPL y la otra es una licencia comercial. Hancom no adquirió una licencia comercial de Artifex ni lanzó su suite ofimática como software libre. Artifex demandó a Hancom en el Tribunal de Distrito de los Estados Unidos e hizo dos afirmaciones. En primer lugar, el uso de Ghostscript por parte de Hancom fue una violación de los derechos de autor; y en segundo lugar, el uso de Ghostscript por parte de Hancom fue una violación de la licencia. La jueza Jacqueline Scott Corley determinó que la licencia GPL era un contrato ejecutable y que Hancom había incumplido el contrato. [91] [92]
El 20 de julio de 2021, los desarrolladores del motor de ajedrez de código abierto Stockfish demandaron a ChessBase , el creador del software de ajedrez, por violar la licencia GPLv3. [93] Se afirmó que Chessbase solo había realizado ligeras modificaciones al código de Stockfish y vendió los nuevos motores (Fat Fritz 2 y Houdini 6) a sus clientes. [94] Además, Fat Fritz 2 se comercializó como si fuera un motor innovador. ChessBase había infringido la licencia al no distribuir estos productos como software libre de acuerdo con la GPL.
Un año después, el 7 de noviembre de 2022, ambas partes llegaron a un acuerdo y pusieron fin a la disputa. En un futuro próximo, ChessBase ya no vendería productos que contuvieran el código de Stockfish, aunque informaría de ello a sus clientes mediante un aviso adecuado en sus páginas web. Sin embargo, un año después, se restablecería la licencia de Chessbase. Stockfish no solicitó daños ni compensación económica. [95] [96] [97]
El código licenciado bajo varias otras licencias se puede combinar con un programa bajo la GPL sin conflicto, siempre que la combinación de restricciones sobre el trabajo en su conjunto no imponga restricciones adicionales más allá de lo que permite la GPL. [98] Además de los términos regulares de la GPL, existen restricciones y permisos adicionales que se pueden aplicar:
La FSF mantiene una lista [103] de licencias de software libre compatibles con la GPL [104] que contiene muchas de las licencias de software libre más comunes, como la licencia MIT/X original , la licencia BSD (en su forma actual de 3 cláusulas) y la Licencia Artística 2.0. [105]
A partir de la GPLv3, es unilateralmente compatible que los materiales (como texto y otros medios) bajo la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional se mezclen con los materiales con licencia GPL (principalmente software), no al revés, para casos de uso específicos como motor de juego (GPL) con scripts de juego (CC BY-SA). [106] [107]
David A. Wheeler ha defendido que los desarrolladores de software libre/de código abierto utilicen únicamente licencias compatibles con la GPL, porque de lo contrario se dificulta la participación y contribución de código por parte de otros. [108] Como ejemplo específico de incompatibilidad de licencias, ZFS de Sun Microsystems no puede incluirse en el núcleo Linux con licencia GPL, porque está licenciado bajo la Licencia de Desarrollo y Distribución Común incompatible con la GPL . Además, ZFS está protegido por patentes, por lo que distribuir una implementación GPL desarrollada independientemente todavía requeriría el permiso de Oracle. [109]
Varias empresas utilizan licencias múltiples para distribuir una versión GPL y vender una licencia propietaria a empresas que desean combinar el paquete con código propietario, utilizando o no enlaces dinámicos. Algunos ejemplos de estas empresas son MySQL AB , Digia PLC ( Qt framework , antes de 2011 de Nokia ), Red Hat ( Cygwin ) y Riverbank Computing ( PyQt ). Otras empresas, como la Fundación Mozilla (entre sus productos se incluyen Mozilla Application Suite , Mozilla Thunderbird y Mozilla Firefox ), utilizaron licencias múltiples para distribuir versiones bajo la GPL y algunas otras licencias de código abierto.
Es posible utilizar la GPL para documentos de texto en lugar de programas de ordenador, o más generalmente para todo tipo de medios, si está claro qué constituye el código fuente (definido como "la forma preferida de la obra para hacer cambios en ella"). [110] Para manuales y libros de texto, sin embargo, la FSF recomienda la Licencia de Documentación Libre GNU (GFDL), que creó para este propósito. [111] Sin embargo, los desarrolladores de Debian recomendaron (en una resolución adoptada en 2006) licenciar la documentación para su proyecto bajo la GPL, debido a la incompatibilidad de la GFDL con la GPL (el texto licenciado bajo la GFDL no puede incorporarse al software GPL). [112] [113] Además, la fundación FLOSS Manuals , una organización dedicada a crear manuales para software libre, decidió evitar la GFDL a favor de la GPL para sus textos en 2007. [114]
Si la GPL se utiliza para fuentes de ordenador , cualquier documento o imagen realizada con dichas fuentes también podría tener que distribuirse bajo los términos de la GPL. Este no es el caso en los países que reconocen las tipografías (la apariencia de las fuentes) como un artículo útil y, por lo tanto, no elegible para derechos de autor , pero los archivos de fuentes como software de ordenador con derechos de autor (lo que puede complicar la incrustación de fuentes, ya que el documento podría considerarse "vinculado" a la fuente; en otras palabras, incrustar una fuente vectorial en un documento podría obligarlo a ser publicado bajo la GPL, pero una representación rasterizada de la fuente no estaría sujeta a la GPL). La FSF proporciona una excepción para los casos en que esto no se desea. [115]
Históricamente, la familia de licencias GPL ha sido una de las licencias de software más populares en el dominio FOSS . [7] [116] [9] [10] [11] [117]
Una encuesta de 1997 de MetaLab , entonces el mayor archivo de software libre, mostró que la GPL representaba aproximadamente la mitad del software licenciado allí. [116] De manera similar, una encuesta de 2000 de Red Hat Linux 7.1 encontró que el 53% del código fuente estaba licenciado bajo la GPL. [9] A partir de 2003 [update], aproximadamente el 68% de todos los proyectos y el 82,1% de los proyectos con licencia certificada por la industria de código abierto listados en SourceForge.net eran de la familia de licencias GPL. [118] A partir de agosto de 2008 [update], la familia GPL representaba el 70,9% de los 44.927 proyectos de software libre listados en Freecode . [10]
Tras el lanzamiento de la GPLv3 en junio de 2007, la adopción de esta nueva versión de la GPL fue muy discutida [119] y algunos proyectos decidieron no actualizarse. Por ejemplo, el núcleo de Linux, [39] [41] MySQL , [120] BusyBox , [121] AdvFS , [122] Blender , [123] [124] VLC media player , [125] y MediaWiki [126] decidieron no adoptar la GPLv3. Por otro lado, en 2009, dos años después del lanzamiento de la GPLv3, el director de la oficina de programas de código abierto de Google, Chris DiBona, informó que el número de proyectos de software con licencia de código abierto que habían pasado de la GPLv2 a la GPLv3 era del 50%, contando los proyectos alojados en Google Code . [11]
En 2011, cuatro años después del lanzamiento de la GPLv3, el 6,5% de todos los proyectos de licencia de código abierto son GPLv3, mientras que el 42,5% son GPLv2, según los datos de Black Duck Software. [127] [128] Después, en 2011, el analista de 451 Group, Matthew Aslett, argumentó en una publicación de blog que las licencias copyleft entraron en declive y las licencias permisivas aumentaron, según las estadísticas de Black Duck Software. [129] De manera similar, en febrero de 2012, Jon Buys informó que entre los 50 proyectos principales en GitHub, cinco proyectos estaban bajo una licencia GPL, incluidos proyectos con licencia dual y AGPL. [130]
Las estadísticas de uso de GPL de 2009 a 2013 fueron extraídas de los datos de Freecode por Walter van Holst mientras analizaba la proliferación de licencias . [12]
En agosto de 2013, según Black Duck Software, los datos del sitio web muestran que la familia de licencias GPL es utilizada por el 54% de los proyectos de código abierto, con un desglose de las licencias individuales que se muestra en la siguiente tabla. [117] Sin embargo, un estudio posterior en 2013 mostró que el software con licencia bajo la familia de licencias GPL ha aumentado, y que incluso los datos de Black Duck Software han mostrado un aumento total de proyectos de software con licencia GPL. El estudio utilizó información pública recopilada de los repositorios del Proyecto Debian , y el estudio criticó a Black Duck Software por no publicar su metodología utilizada en la recopilación de estadísticas. [133] Daniel German, profesor del Departamento de Ciencias de la Computación de la Universidad de Victoria en Canadá, presentó una charla en 2013 sobre los desafíos metodológicos para determinar cuáles son las licencias de software libre más utilizadas, y mostró cómo no podía replicar el resultado de Black Duck Software. [134]
En 2015, según Black Duck, la GPLv2 perdió su primera posición ante la licencia MIT y ahora está en segundo lugar, la GPLv3 cayó al cuarto lugar mientras que la licencia Apache mantuvo su tercera posición. [7]
Un análisis de marzo de 2015 de los repositorios de GitHub reveló, para la familia de licencias GPL, un porcentaje de uso de aproximadamente el 25% entre los proyectos con licencia. [140] En junio de 2016, un análisis de los paquetes del Proyecto Fedora reveló que la GNU GPLv2 o posterior era la licencia más popular, y la familia GNU GPL como la familia de licencias más popular (seguida por las familias MIT, BSD y GNU LGPL). [141]
Un análisis de whitesourcesoftware.com en abril de 2018 del ecosistema FOSS mostró que la GPLv3 estaba en tercer lugar (18%) y la GPLv2 en cuarto lugar (11%), después de la licencia MIT (26%) y la licencia Apache 2.0 (21%). [142]
La GPL es incompatible con muchos sistemas de distribución digital de aplicaciones, como la Mac App Store y otras plataformas de distribución de software (tanto en teléfonos inteligentes como en PC). El problema radica en el derecho a "hacer una copia para el vecino", ya que este derecho se ve violado por los sistemas de gestión de derechos digitales integrados en la plataforma para evitar la copia de software de pago. Incluso si la aplicación es gratuita en la tienda de aplicaciones en cuestión, podría resultar en una violación de los términos de esa tienda de aplicaciones. [143]
Existe una distinción entre una tienda de aplicaciones , que vende software restringido por DRM bajo licencias propietarias, y el concepto más general de distribución digital a través de alguna forma de repositorio de software en línea. Prácticamente todos los sistemas Unix y distribuciones Linux modernos tienen repositorios de aplicaciones, incluidos NetBSD , FreeBSD , Ubuntu , Fedora y Debian . Todos estos repositorios de aplicaciones específicos contienen aplicaciones de software con licencia GPL, en algunos casos incluso cuando el proyecto principal no permite código con licencia GPL en el sistema base (por ejemplo, OpenBSD [144] ). En otros casos, como la App Store de Ubuntu , las aplicaciones de software comercial propietarias y las aplicaciones con licencia GPL están disponibles a través del mismo sistema; la razón por la que la Mac App Store (y proyectos similares) es incompatible con las aplicaciones con licencia GPL no es inherente al concepto de una tienda de aplicaciones, sino que se debe más bien específicamente al requisito de los términos de uso de Apple [143] de que todas las aplicaciones en la tienda utilicen restricciones DRM de Apple. La tienda de aplicaciones de Ubuntu no exige ningún requisito de este tipo: “Estos términos no limitan ni restringen sus derechos bajo ninguna licencia de software de código abierto aplicable”. [145]
En 2001, el director ejecutivo de Microsoft, Steve Ballmer, se refirió a Linux como "un cáncer que se adhiere en un sentido de propiedad intelectual a todo lo que toca". [146] [147] En respuesta a los ataques de Microsoft a la GPL, varios destacados desarrolladores y defensores del software libre publicaron una declaración conjunta apoyando la licencia. [148] Microsoft ha publicado Microsoft Windows Services para UNIX , que contiene código con licencia GPL. En julio de 2009, Microsoft publicó un conjunto de alrededor de 20.000 líneas de código de controlador Linux bajo la GPL. [149] El código Hyper-V que forma parte del código presentado utilizaba componentes de código abierto con licencia GPL y originalmente estaba vinculado estáticamente a partes binarias propietarias, siendo estas últimas inadmisibles en software con licencia GPL. [150]
La descripción de la GPL como "viral" , cuando se la llama 'Virus Público General' o 'Virus Público GNU' (GPV), se remonta a un año después de que se lanzara la GPLv1. [151]
En 2001, el término recibió una mayor atención pública cuando Craig Mundie , vicepresidente senior de Microsoft, describió la GPL como "viral". [152] Mundie sostiene que la GPL tiene un efecto "viral" ya que solo permite la transmisión de programas completos, lo que significa que los programas que se vinculan a bibliotecas GPL deben estar bajo una licencia compatible con la GPL, de lo contrario no se pueden combinar y distribuir.
En 2006, Richard Stallman respondió en una entrevista que la metáfora de Mundie de un "virus" es errónea, ya que el software bajo la GPL no "ataca" ni "infecta" a otro software. En consecuencia, Stallman cree que comparar la GPL con un virus es inadecuado y que una mejor metáfora para el software bajo la GPL sería una planta araña : si uno toma un trozo de ella y lo coloca en otro lugar, crece allí también. [153]
Por otra parte, el concepto de naturaleza viral de la GPL fue retomado por otros más tarde también. [154] [155] Por ejemplo, un artículo de 2008 afirmaba: "La licencia GPL es 'viral', lo que significa que cualquier trabajo derivado que usted cree que contenga incluso la porción más pequeña del software previamente licenciado bajo la GPL también debe estar licenciado bajo la licencia GPL". [156]
El proyecto FreeBSD ha declarado que "un uso menos publicitado e imprevisto de la GPL es que es muy favorable para las grandes empresas que quieren socavar el precio de las empresas de software. En otras palabras, la GPL es muy adecuada para su uso como arma de marketing, reduciendo potencialmente el beneficio económico general y contribuyendo al comportamiento monopolístico" y que la GPL puede "presentar un problema real para quienes desean comercializar y obtener beneficios a partir del software". [157]
Richard Stallman escribió sobre la práctica de vender excepciones de licencias a licencias de software libre como un ejemplo de práctica de comercialización éticamente aceptable. Vender excepciones significa que el titular de los derechos de autor de un software determinado lo libera (junto con el código fuente correspondiente) al público bajo una licencia de software libre, "y luego permite que los clientes paguen por el permiso para usar el mismo código bajo diferentes términos, por ejemplo, permitiendo su inclusión en aplicaciones propietarias". Stallman consideró que la venta de excepciones es "aceptable desde los años 90, y en ocasiones se lo he sugerido a las empresas. A veces, este enfoque ha hecho posible que programas importantes se conviertan en software libre". Aunque la FSF no practica la venta de excepciones, se propone una comparación con la licencia X11 (que es una licencia de software libre sin copyleft) para sugerir que esta técnica de comercialización debería considerarse éticamente aceptable. Liberar un programa determinado bajo una licencia de software libre sin copyleft permitiría incrustar el código en software propietario. Stallman comenta que "o bien tenemos que concluir que está mal publicar algo bajo la licencia X11 (una conclusión que me parece inaceptablemente extrema) o bien rechazar esta implicación. Utilizar una licencia que no sea copyleft es una opción débil y, por lo general, inferior, pero no está mal. En otras palabras, vender excepciones permite cierta incrustación en software propietario, y la licencia X11 permite incluso más incrustaciones. Si esto no hace que la licencia X11 sea inaceptable, tampoco hace que vender excepciones sea inaceptable". [158]
En 2000, el desarrollador y autor Nikolai Bezroukov publicó un análisis y una crítica exhaustiva de los fundamentos de la GPL y del modelo de desarrollo de software de Stallman, llamado "Laberinto de la libertad del software". [159] [160]
La versión 2 de la licencia pública WTFPL (Do What The Fuck You Want To) fue creada por el líder del proyecto Debian, Sam Hocevar, en 2004 como una parodia de la GPL. [161]
En 2005, el defensor del software de código abierto Eric S. Raymond cuestionó la relevancia de la GPL para el ecosistema del software libre, afirmando: "Ya no necesitamos la GPL. Se basa en la creencia de que el software de código abierto es débil y necesita protección. El código abierto tendría éxito más rápido si la GPL no pusiera nerviosa a mucha gente a la hora de adoptarla". [162] Richard Stallman respondió: "La GPL está diseñada para... garantizar que cada usuario de un programa obtenga las libertades esenciales: ejecutarlo, estudiar y cambiar el código fuente, redistribuir copias y publicar versiones modificadas ... [Raymond] aborda el tema en términos de diferentes objetivos y valores: los del 'código abierto', que no incluyen la defensa de la libertad de los usuarios de software para compartir y cambiar el software". [163]
En 2007, Allison Randal , que participó en el comité de borrador de la GPL, criticó la GPLv3 por ser incompatible con la GPLv2 [164] y por falta de claridad en la formulación. [165] De manera similar, Whurley profetizó en 2007 la caída de la GPL debido a la falta de enfoque para los desarrolladores con la GPLv3, lo que los llevaría hacia licencias permisivas. [166]
En 2009, David Chisnall describió en un artículo de InformIT , "El fracaso de la GPL", los problemas con la GPL, entre ellos la incompatibilidad y la complejidad del texto de la licencia. [167]
En 2014, el desarrollador de dtrace y CTO de Joyent, Bryan Cantrill, calificó la GPL copyleft como un " antipatrón corporativo de código abierto " por ser "anticolaborativo" y recomendó en su lugar licencias de software permisivas . [168]
Ya en septiembre de 2006, en el proceso de borrador de la GPLv3, varios desarrolladores de alto perfil del núcleo Linux, por ejemplo Linus Torvalds, Greg Kroah-Hartman y Andrew Morton , advirtieron sobre una división de la comunidad FOSS: "el lanzamiento de la GPLv3 presagia la balcanización de todo el universo de código abierto en el que confiamos". [37] De manera similar, Benjamin Mako Hill argumentó en 2006 sobre el borrador de la GPLv3, señalando que una comunidad unida y colaboradora es más importante que una licencia única. [169]
Tras la publicación de la GPLv3 en 2007, algunos periodistas [41] [127] [170] y el desarrollador de Toybox Rob Landley [44] [45] criticaron que con la introducción de la GPLv3 la división entre la comunidad de software libre y de código abierto se hizo más grande que nunca. Como la GPLv3, que se ha ampliado considerablemente, es esencialmente incompatible con la GPLv2, [99] la compatibilidad entre ambas sólo se da bajo la cláusula opcional "o posterior" de la GPL, que no fue adoptada, por ejemplo, por el núcleo Linux. [39] Bruce Byfield señaló que antes de la publicación de la GPLv3, la GPLv2 era un elemento unificador entre la comunidad de software libre y de código abierto. [127]
En cuanto a la LGPLv3, el mantenedor de GNU TLS, Nikos Mavrogiannopoulos, argumentó de manera similar: "Si asumimos que su objetivo principal [de la LGPLv3] es ser utilizada por software libre, entonces falla descaradamente en ese sentido", [171] después de que re-licenciara GNU TLS de LGPLv3 a LGPLv2.1 debido a problemas de compatibilidad de licencias. [172]
En 2007, el abogado y especialista en informática Lawrence Rosen elogió la forma en que la comunidad que utilizaba la licencia Apache podía ahora trabajar junto con la comunidad GPL de forma compatible, ya que los problemas de compatibilidad de la GPLv2 con el software con licencia Apache se habían resuelto con la GPLv3. Dijo: "Preveo que uno de los mayores éxitos de la GPLv3 será la constatación de que todo el universo del software libre y de código abierto puede combinarse así en soluciones integrales de código abierto para clientes de todo el mundo". [173]
En julio de 2013, el desarrollador de Flask, Armin Ronacher, llega a una conclusión menos optimista sobre la compatibilidad de la GPL en el ecosistema FOSS: "Cuando la GPL está involucrada, las complejidades de la concesión de licencias se convierten en una versión no divertida de un acertijo", señalando también que el conflicto entre la Licencia Apache 2.0 y la GPLv2 todavía tiene impacto en el ecosistema. [174]
... Esta página presenta la opinión de algunos colaboradores de Debian-legal sobre cómo ciertas licencias siguen las Pautas de software libre de Debian (DFSG). ... Las licencias que se encuentran actualmente en Debian main incluyen:
- ...
- Licencias de estilo MIT/Expat
- ...
... Esta es la última versión de la GPL de GNU: una licencia de software libre y una licencia copyleft. ... La GPLv3 no es compatible con la GPLv2 por sí sola. Sin embargo, la mayoría del software publicado bajo la GPLv2 también le permite utilizar los términos de versiones posteriores de la GPL. Cuando este sea el caso, puede utilizar el código bajo la GPLv3 para hacer la combinación deseada. ...
... Las siguientes licencias han sido aprobadas por la OSI. ...
- Licencia pública general GNU versión 2 (GPL-2.0)
- Licencia pública general GNU versión 3 (GPL-3.0)
- ...
... Esta es la versión anterior de la GPL de GNU: una licencia de software libre y una licencia copyleft. ... La GPLv2, por sí misma, no es compatible con la GPLv3. Sin embargo, la mayoría del software publicado bajo la GPLv2 también le permite utilizar los términos de versiones posteriores de la GPL. Cuando este sea el caso, puede utilizar el código bajo la GPLv3 para hacer la combinación deseada. ...
GPL 60,5%, lGPLv2 6,9%, GPLv2 1,9%, GPLv3 1,6%
So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved.
Showing comments in file 'gplv3-draft-1' ... found 962
Showing comments in file 'gplv3-draft-1' ... found 727
Showing comments in file 'gplv3-draft-3' ... found 649
Showing comments in file 'gplv3-draft-4' ... found 298
The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve. However, a deeper reading reveals several other problems with the current FSF draft: 5.1 DRM Clauses ... 5.2 Additional Restrictions Clause ... 5.3 Patents Provisions ... since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL-licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely.
Second, the war between Linus Torvalds and other Kernel developers and the Free Software Foundation over GPLv3 is continuing, with Torvalds saying he's fed up with the FSF.
[T]he only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
In some ways, Linux was the project that really made the split clear between what the FSF is pushing which is very different from what open source and Linux has always been about, which is more of a technical superiority instead of a -- this religious belief in freedom," Torvalds told Zemlin. So, the GPL Version 3 reflects the FSF's goals and the GPL Version 2 pretty closely matches what I think a license should do and so right now, Version 2 is where the kernel is.
The only one of any note that I'd like to point out directly is the clarification in the COPYING file, making it clear that it's only _that_particular version of the GPL that is valid for the kernel. This should not come as any surprise, as that's the same license that has been there since 0.12 or so, but I thought I'd make that explicit
No. Algunos de los requisitos de la GPLv3, como el requisito de proporcionar información de instalación, no existen en la GPLv2. Como resultado, las licencias no son compatibles: si intentara combinar código publicado bajo ambas licencias, violaría la sección 6 de la GPLv2. Sin embargo, si el código se publica bajo la GPL "versión 2 o posterior", es compatible con la GPLv3 porque la GPLv3 es una de las opciones que permite.
Tanto LibreCAD como FreeCAD quieren usar LibreDWG y tienen parches disponibles para soportar la biblioteca de formato de archivo DWG, pero no pueden integrarlos. Los programas tienen dependencias de la popular licencia GPLv2, mientras que la Free Software Foundation solo permite que LibreDWG tenga licencia para uso GPLv3, no GPLv2.
Creemos que a esta altura ya debería estar cerrado. Tenemos la respuesta final de la FSF. ... "No vamos a cambiar la licencia".
No es posible tomar prestado texto de un manual con licencia GFDL e incorporarlo en ningún programa de software libre. No se trata de una mera incompatibilidad de licencias. No se trata sólo de que la GFDL sea incompatible con esta o aquella licencia de software libre: es que es fundamentalmente incompatible con cualquier licencia de software libre. Por lo tanto, si escribe un programa nuevo y no tiene ningún compromiso sobre qué licencia quiere utilizar, salvo que sea una licencia libre, no puede incluir texto con licencia GFDL. La FDL de GNU, tal como está hoy, no cumple con las Directrices de Software Libre de Debian. Hay problemas significativos con la licencia, como se detalla más arriba; y, como tal, no podemos aceptar obras licenciadas bajo la FDL de GNU en nuestra distribución.
"License -> OSI: ... GNU General Public License (GPL) (32641 projects), GNU Library or Lesser General Public License (LGPL) (4889 projects" (of 45727, 82.1%)
Currently the decision to move from GPL v2 to GPL v3 is being hotly debated by many open source projects. According to Palamida, a provider of IP compliance software, there have been roughly 2489 open source projects that have moved from GPL v2 to later versions.
Since BusyBox can be found in so many embedded systems, it finds itself at the core of the GPLv3 anti-DRM debate. ... The real outcomes, however, are this: BusyBox will be GPLv2 only starting with the next release. It is generally accepted that stripping out the "or any later version" is legally defensible, and that the merging of other GPLv2-only code will force that issue in any case
Don't invent a straw man argument please. I consider licensing BusyBox under GPLv3 to be useless, unnecessary, overcomplicated, and confusing, and in addition to that it has actual downsides. 1) Useless: We're never dropping GPLv2.
[Blender's Toni Roosendaal:] "Blender is also still 'GPLv2 or later'. For the time being we stick to that, moving to GPL 3 has no evident benefits I know of."
The source code we develop at blender.org is default being licensed as GNU GPL Version 2 or later.
In 2001, VLC was released under the OSI-approved GNU General Public version 2, with the commonly-offered option to use 'any later version' thereof (though there was not any such later version at the time). Following the release by the Free Software Foundation (FSF) of the new version 3 of its GNU General Public License (GPL) on the 29th of June 2007, contributors to the VLC media player, and other software projects hosted at videolan.org, debated the possibility of updating the licensing terms for future version of the VLC media player and other hosted projects, to version 3 of the GPL. ... There is strong concern that these new additional requirements might not match the industrial and economic reality of our time, especially in the market of consumer electronics. It is our belief that changing our licensing terms to GPL version 3 would currently not be in the best interest of our community as a whole. Consequently, we plan to keep distributing future versions of VLC media player under the terms of the GPL version 2.
At the time, the decision seemed sensible in the face of a deadlock. But now, GPLv2 is used for 42.5% of free software, and GPLv3 for less than 6.5%, according to Black Duck Software.
From the above chart it is clear that the GPL family is the highest used (I had miscalculated it as MIT before). The other major licenses are MIT, BSD, the LGPL family, Artistic (for Perl packages), LPPL (fo[r] texlive packages), ASL.
The WTFPL is a parody of the GPL, which has a similar copyright header and list of permissions to modify (i.e. none), see for instance gnu.org/licenses/gpl-3.0.en.html. The purpose of the WTFPL wording is to give more freedom than the GPL does.
We don't need the GPL anymore. It's based on the belief that open source software is weak and needs to be protected. Open source would be succeeding faster if the GPL didn't make lots of people nervous about adopting it.
ESR addresses the issue in terms of different goals and values—those of "open source," which do not include defending software users' freedom to share and change software. Perhaps he thinks the GNU GPL is not needed to achieve those goals.
You might think the FSF would have to be insane to unleash this licensing hell. ... If the license were purely a cleaned up version of the GPLv2, there would be no incompatibility, the FSF would have no agenda involved in getting projects to update to the new license, and at the same time there would be no reason for projects to object to updating. Smooth sailing.
Looking at the near-finished draft, I have to say it's unlikely that they ever considered simplicity a priority, if they considered it at all. ... The language choices of an open source license can support that freedom, can empower the users and the developers. The GPLv3 doesn't.
Version 3 is going to distance Richard Stallman and the Free Software Foundation from the developers that make the organization so influential to begin.
Anti-pattern: Anti-collaborative licensing
The GPL is one thing that almost everyone in the free and open-source software communities have in common. For that reason, the revision has the potential to highlight disagreements, differences in opinion, differences in business models, and differences in tactics. ... We would be wise to remember that the potential for the GPL to hinder our ability to work together is far more dangerous than the even the most radical change textual change the FSF might suggest. ... Above all, we must remember that our community and its goals are more important than any single license -- no matter how widespread.
... the latest sign of a growing schism in the open source community between business-minded developers like Torvalds and free software purists.
LGPLv3 is the latest version of the GNU Lesser General Public License. It follows the successful LGPLv2.1 license, and was released by Free Software Foundation as a counterpart to its GNU General Public License version 3. The goal of the GNU Lesser General Public Licenses is to provide software that can be used by both proprietary and free software. This goal has been successfully handled so far by LGPLv2.1, and there is a multitude of libraries using that license. Now we have LGPLv3 as the latest, and the question is how successful is LGPLv3 on this goal? In my opinion, very little. If we assume that its primary goal is to be used by free software, then it blatantly fails that.
The License Compatibility Clusterfuck - When the GPL is involved the complexities of licensing becomes a non fun version of a riddle. So many things to consider and so many interactions to consider. And that GPL incompatibilities are still an issue that actively effects people is something many appear to forget. For instance one would think that the incompatibility of the GPLv2 with the Apache Software License 2.0 should be a thing of the past now that everything upgrades to GPLv3, but it turns out that enough people are either stuck with GPLv2 only or do not agree with the GPLv3 that some Apache Software licensed projects are required to migrate. For instance Twitter's Bootstrap is currently migrating from ASL2.0 to MIT precisely because some people still need GPLv2 compatibility. Among those projects that were affected were Drupal, WordPress, Joomla, the MoinMoin Wiki and others. And even that case shows that people don't care that much about licenses any more as Joomla 3 just bundled bootstrap even though they were not licenses in a compatible way (GPLv2 vs ASL 2.0). The other traditional case of things not being GPL compatible is the OpenSSL project which has a license that does not go well with the GPL. That license is also still incompatible with the GPLv3. The whole ordeal is particularly interesting as some not so nice parties have started doing license trolling through GPL licenses.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}