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 GPL fue la primera licencia 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 a alguien explotar 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 un "usuario" y un "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, salvo 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 figuran 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 licencia copyleft es proporcionar una oferta por escrito para proporcionar el código fuente en un medio físico (como un CD) si se lo 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 realizar versiones modificadas privadas sin obligación de divulgar las modificaciones, siempre que 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 los 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ática 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 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 sea 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 las 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 una obra derivada. [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 le 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 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 había vendido 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 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 de otros y la contribución de código. [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 enlaces dinámicos o no. Algunos ejemplos de dichas 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 ser incorporado en 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 elegibles 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 archivo de software libre más grande, 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 de 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 publica (junto con el código fuente correspondiente) 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. Publicar 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 atención a los desarrolladores con 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 como su 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]
En septiembre de 2006, durante el proceso de borrador de la GPLv3, varios desarrolladores de alto perfil del núcleo Linux como Linus Torvalds, Greg Kroah-Hartman y Andrew Morton , advirtieron sobre una división en 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 también argumentó en 2006 durante el borrador de la GPLv3 que una comunidad unida y colaboradora es más importante que una licencia única. [169]
Tras el lanzamiento 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 código abierto y la de software libre se hizo más grande que nunca porque la significativamente ampliada GPLv3 es esencialmente incompatible con la GPLv2. [99] La compatibilidad sólo se da bajo la cláusula opcional "o posterior" de la GPL, que no fue adoptada por el núcleo Linux, entre otros. [39] Bruce Byfield señaló que antes del lanzamiento de la GPLv3, la GPLv2 era un elemento unificador entre la comunidad de código abierto y la de software libre. [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 volvió a licenciar 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 en conjunto con la comunidad GPL de manera 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, llegó 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%
Así, mientras que los BSD han perdido energía cada vez que una empresa se involucra, los programas con licencia GPL ganan cada vez que una empresa se involucra.
Mostrando comentarios en el archivo 'gplv3-draft-1'
... encontrados 962
Mostrando comentarios en el archivo 'gplv3-draft-1'
... encontrados 727
Mostrando comentarios en el archivo 'gplv3-draft-3' ... encontrados 649
Mostrando comentarios en el archivo 'gplv3-draft-4' ... encontrados 298
La versión actual (borrador de discusión 2) de la GPLv3 en primera lectura no supera la prueba de necesidad de la sección 1 sobre la base de que no hay ningún problema sustancial e identificado con la GPLv2 que esté tratando de resolver. Sin embargo, una lectura más profunda revela varios otros problemas con el borrador actual de la FSF: 5.1 Cláusulas DRM
... 5.2 Cláusula de restricciones adicionales
... 5.3 Disposiciones sobre patentes
... dado que la FSF está proponiendo cambiar todos sus proyectos a GPLv3 y aplicar presión a todos los demás proyectos con licencia GPL para que se muevan, prevemos que el lanzamiento de GPLv3 presagia la
balcanización
de todo el universo de código abierto en el que confiamos.
En segundo lugar, la guerra entre Linus Torvalds y otros desarrolladores del kernel y la Free Software Foundation sobre la GPLv3 continúa, y Torvalds dice que está harto de la FSF.
[L]a única versión válida de la GPL en lo que respecta al núcleo es _esta_ versión particular de la licencia (es decir, v2, no v2.2 o v3.x o cualquier otra), a menos que se indique explícitamente lo contrario.
En cierto modo, Linux fue el proyecto que realmente dejó clara la división entre lo que la FSF está impulsando, que es muy diferente de lo que siempre ha sido el código abierto, y Linux, que es más una superioridad técnica en lugar de una creencia religiosa en la libertad", dijo Torvalds a Zemlin. Por lo tanto, la versión 3 de la GPL refleja los objetivos de la FSF y la versión 2 de la GPL coincide bastante con lo que creo que debería hacer una licencia y, por lo tanto, en este momento, la versión 2 es donde está el kernel.
El único punto importante que me gustaría señalar directamente es la aclaración en el archivo COPYING, que deja claro que solo _esa_ versión particular de la GPL es válida para el núcleo. Esto no debería sorprender a nadie, ya que es la misma licencia que ha estado allí desde la versión 0.12 aproximadamente, pero pensé que sería mejor dejarlo explícito.
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.
... la desafortunada situación con el soporte para archivos DWG en software CAD libre a través de LibreDWG. 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 cualquier 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.
"Licencia -> OSI: ... Licencia Pública General GNU (GPL) (32641 proyectos), Licencia Pública General Reducida o de Biblioteca GNU (LGPL) (4889 proyectos)" (de 45727, 82,1%)
Según Palamida, un proveedor de software de cumplimiento de IP, ha habido aproximadamente 2489 proyectos de código abierto que han pasado de la GPL v2 a versiones posteriores.
Dado que BusyBox se puede encontrar en tantos sistemas integrados, se encuentra en el centro del debate anti-DRM de la GPLv3.
... Los resultados reales, sin embargo, son estos: BusyBox será GPLv2 solamente a partir de la próxima versión. Se acepta generalmente que eliminar el "o cualquier versión posterior" es legalmente defendible, y que la fusión de otro código que sólo sea GPLv2 forzará esa cuestión en cualquier caso
No inventes un argumento falaz, por favor. Considero que licenciar BusyBox bajo GPLv3 es inútil, innecesario, demasiado complicado y confuso, y además de eso tiene desventajas reales. 1) Inútil: nunca abandonaremos GPLv2.
[Toni Roosendaal de Blender:] "Blender también sigue siendo 'GPLv2 o posterior'. Por el momento nos atenemos a eso, pasar a GPL 3 no tiene beneficios evidentes que yo sepa".
El código fuente que desarrollamos en blender.org tiene licencia GNU GPL versión 2 o posterior de manera predeterminada.
En 2001, VLC se lanzó bajo la versión 2 de la GNU General Public aprobada por OSI, con la opción comúnmente ofrecida de usar "cualquier versión posterior" de la misma (aunque no había ninguna versión posterior de ese tipo en ese momento). Tras el lanzamiento por parte de la Free Software Foundation (FSF) de la nueva versión 3 de su Licencia Pública General GNU (GPL) el 29 de junio de 2007, los 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 futuras versiones del reproductor multimedia VLC y otros proyectos alojados, a la versión 3 de la GPL.
... Existe una gran preocupación de que estos nuevos requisitos adicionales podrían no coincidir con la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Creemos que cambiar los términos de nuestra licencia a la versión 3 de la GPL no sería lo mejor para nuestra comunidad en su conjunto. Por lo tanto, tenemos previsto seguir distribuyendo futuras versiones del reproductor multimedia VLC bajo los términos de la versión 2 de la GPL.
En su momento, la decisión parecía sensata ante un punto muerto. Pero ahora, la GPLv2 se utiliza para el 42,5% del software libre y la GPLv3 para menos del 6,5%, según Black Duck Software.
Del cuadro anterior se desprende claramente que la familia GPL es la más utilizada (antes había calculado mal que era MIT). Las otras licencias principales son MIT, BSD, la familia LGPL, Artistic (para paquetes Perl), LPPL (para paquetes texlive) y ASL.
La propiedad viral estimula la proliferación de licencias y contribuye a la "pesadilla impuesta por la GPL" - una situación en la que muchas otras licencias son lógicamente incompatibles con la GPL y hacen la vida innecesariamente difícil para los desarrolladores que trabajan en el entorno Linux (KDE es un buen ejemplo en este caso, Python es un ejemplo menos conocido).
La WTFPL es una parodia de la GPL, que tiene un encabezado de copyright similar y una lista de permisos para modificar (es decir, ninguno); consulte, por ejemplo, gnu.org/licenses/gpl-3.0.en.html. El propósito de la redacción de la WTFPL es dar más libertad que la que otorga 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 nerviosas a muchas personas a la hora de adoptarla.
ESR 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 modificar el software. Tal vez crea que la GPL de GNU no es necesaria para alcanzar esos objetivos.
Se podría pensar que la FSF tendría que estar loca para desatar este infierno de licencias.
... Si la licencia fuera puramente una versión limpia de la GPLv2, no habría incompatibilidad, la FSF no tendría ninguna agenda involucrada en lograr que los proyectos se actualicen a la nueva licencia y, al mismo tiempo, no habría ninguna razón para que los proyectos se opongan a la actualización. Todo viento en popa.
Al observar el borrador casi terminado, debo decir que es poco probable que alguna vez hayan considerado la simplicidad como una prioridad, si es que la consideraron en absoluto.
... Las opciones de lenguaje de una licencia de código abierto pueden respaldar esa libertad, pueden empoderar a los usuarios y a los desarrolladores. La GPLv3 no lo hace.
La versión 3 va a distanciar a Richard Stallman y a la Free Software Foundation de los desarrolladores que hacen que la organización sea tan influyente para empezar.
Antipatrón: licencias anticolaborativas
software libre y de código abierto tienen en común. Por esa razón, la revisión tiene el potencial de resaltar desacuerdos, diferencias de opinión, diferencias en los modelos de negocios y diferencias en las tácticas.
... Sería prudente recordar que el potencial de la GPL para obstaculizar nuestra capacidad de trabajar juntos es mucho más peligroso que incluso el cambio textual más radical que la FSF podría sugerir.
... Por encima de todo, debemos recordar que nuestra comunidad y sus objetivos son más importantes que cualquier licencia individual, sin importar cuán extendida esté.
... la última señal de un creciente cisma en la comunidad de código abierto entre desarrolladores con mentalidad empresarial como Torvalds y puristas del software libre.
La LGPLv3 es la última versión de la Licencia Pública General Reducida de GNU. Sigue a la exitosa licencia LGPLv2.1 y fue publicada por la Free Software Foundation como contraparte de su Licencia Pública General de GNU versión 3. El objetivo de las Licencias Públicas Generales Reducidas de GNU es proporcionar software que pueda ser utilizado tanto por software propietario como libre. Este objetivo ha sido manejado exitosamente hasta ahora por la LGPLv2.1 y hay una multitud de bibliotecas que utilizan esa licencia. Ahora tenemos la LGPLv3 como la última, y la pregunta es ¿qué tan exitosa es la LGPLv3 en este objetivo? En mi opinión, muy poco. Si asumimos que su objetivo principal es ser utilizada por software libre, entonces falla descaradamente en eso.
El lío de la compatibilidad de licencias: cuando se trata de la GPL, las complejidades de las licencias se convierten en una versión nada divertida de un acertijo. Hay tantas cosas que considerar y tantas interacciones que considerar. Y que las incompatibilidades de la GPL siguen siendo un problema que afecta activamente a la gente es algo que muchos parecen olvidar. Por ejemplo, uno podría pensar que la incompatibilidad de la GPLv2 con la Licencia de Software Apache 2.0 debería ser algo del pasado ahora que todo se actualiza a la GPLv3, pero resulta que hay suficientes personas que están atascadas solo con la GPLv2 o que no están de acuerdo con la GPLv3, por lo que algunos proyectos con licencia de software Apache deben migrar. Por ejemplo, Bootstrap de Twitter está migrando actualmente de ASL2.0 a MIT precisamente porque algunas personas aún necesitan compatibilidad con la GPLv2. Entre los proyectos afectados se encuentran Drupal, WordPress, Joomla, la Wiki MoinMoin y otros. Y hasta ese caso demuestra que a la gente ya no le importan tanto las licencias, ya que Joomla 3 simplemente incluyó bootstrap a pesar de que no eran licencias compatibles (GPLv2 frente a ASL 2.0). El otro caso tradicional de cosas que no son compatibles con la GPL es el proyecto OpenSSL, que tiene una licencia que no se lleva bien con la GPL. Esa licencia también sigue siendo incompatible con la GPLv3. Todo este calvario es particularmente interesante, ya que algunas partes no tan agradables han comenzado a trollear las licencias a través de las licencias GPL.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}