Licencia Pública General GNU

La versión 1 de la GNU GPL, publicada el 25 de febrero de 1989, fue escrita para proteger contra los dos métodos principales mediante los cuales los distribuidores de software restringían las libertades que definen el software libre. ^{[ 21 ] [ 22 ]}

El primer método consiste en publicar archivos binarios que solo son ejecutables, pero no legibles ni modificables por humanos. Para evitar esta restricción, la GPLv1 establece que la copia y distribución de copias de cualquier parte del programa también debe poner a disposición el código fuente legible por humanos bajo los mismos términos de licencia. ^{[ a ]}

El segundo método consiste en añadir restricciones, ya sea directamente a la licencia o combinando el software con otro software que tenga restricciones de distribución diferentes. La unión de dos conjuntos de restricciones de este tipo se aplicaría al trabajo combinado, añadiendo así restricciones inaceptables. Para evitar esta situación, la GPLv1 establece que las versiones modificadas, en su conjunto, deben distribuirse bajo los términos de la GPLv1. ^{[ b ]} Como resultado, el software distribuido bajo los términos de la GPLv1 podría combinarse con software distribuido bajo términos más permisivos, ya que esta combinación no alteraría los términos bajo los cuales se puede distribuir el conjunto. Sin embargo, el software distribuido bajo la GPLv1 no podría combinarse con software distribuido bajo una licencia más restrictiva, ya que esta combinación entraría en conflicto con el requisito de que el conjunto sea distribuible bajo los términos de la GPLv1.

Según Richard Stallman , el cambio principal en la versión 2 de la GPL fue la cláusula "Libertad o Muerte" (Sección 7). ^{[ 18 ]} Esta sección establece que los licenciatarios solo pueden distribuir una obra cubierta por la GPL si cumplen con todas las obligaciones de la licencia, independientemente de cualquier otra obligación legal que puedan tener. En otras palabras, las obligaciones de la licencia no pueden disociarse debido a obligaciones contradictorias. Esta disposición tiene como objetivo disuadir a cualquier parte de utilizar una demanda por infracción de patente u otro tipo de litigio para menoscabar la libertad de los usuarios bajo la licencia. ^{[ 18 ]}

Para 1990, se hizo evidente que una licencia menos restrictiva sería estratégicamente útil para dos tipos de bibliotecas: la biblioteca estándar de C y las bibliotecas de software que manejaban las mismas tareas que las bibliotecas propietarias existentes. ^{[ 23 ]} Cuando se publicó la GPLv2 en junio de 1991, se introdujo una segunda licencia al mismo tiempo; esta fue la Licencia Pública General de Bibliotecas de GNU (LGPL), numerada como versión 2 para mostrar que las dos licencias eran complementarias. ^{[ 24 ]} Los números de versión divergieron en 1999 cuando se publicó la versión 2.1 de la LGPL, renombrada como Licencia Pública General Reducida de GNU para reflejar su papel en la filosofía. La GPLv2 se actualizó para hacer referencia al nuevo nombre de la LGPL, pero el número de versión de la GPL permaneció igual. Como resultado, la GPLv2 original no fue reconocida por el Intercambio de Datos de Paquetes de Software (SPDX) . ^{[ 25 ]}

La GPL incluye instrucciones para especificar "la versión 2 de la Licencia, o (a su elección) cualquier versión posterior", para permitir el uso flexible de la versión 2 o la 3, pero algunos desarrolladores modifican estas instrucciones para especificar solo "la versión 2".

A finales de 2005, la Free Software Foundation (FSF) anunció que estaba trabajando en la versión 3 de la GPL. El 16 de enero de 2006 se publicó el primer borrador de discusión de la GPLv3 y se inició la consulta pública. La FSF publicó la versión oficial de la GPLv3 el 29 de junio de 2007. La GPLv3 fue redactada por Richard Stallman, con el asesoramiento legal de Eben Moglen y Richard Fontana del Software Freedom Law Center . ^{[ 26 ] [ 27 ]}

Según Stallman, los cambios más importantes involucraron patentes de software , compatibilidad de licencias de software libre , la definición de "código fuente" y restricciones de hardware en modificaciones de software (como la tivoización ). ^{[ 26 ] [ 28 ]} Otros cambios involucraron la internacionalización, el manejo de violaciones de licencia y la concesión de permisos adicionales por parte del titular de los derechos de autor. El término propagación de software se definió explícitamente como la copia y duplicación de software.

El proceso de consulta pública fue coordinado por la Free Software Foundation con la asistencia del Software Freedom Law Center , la Free Software Foundation Europe y otros grupos de software libre. ^{[ 29 ]} Se recogieron comentarios del público a través del portal web gplv3.fsf.org , ^{[ 30 ]} utilizando un software desarrollado específicamente para ello llamado stet . Al finalizar el período de comentarios, se habían presentado un total de 2636 comentarios. ^{[ 31 ]}

El tercer borrador de la GPLv3 se publicó el 28 de marzo de 2007. ^{[ 32 ]} Este borrador incluía un lenguaje destinado a prevenir acuerdos relacionados con patentes, como el controvertido acuerdo entre Microsoft y Novell ; además, restringía las cláusulas anti-tivoización a las definiciones legales de "usuario" y "producto de consumo". El borrador también eliminó explícitamente la sección sobre "Limitaciones geográficas", cuya probable eliminación se había anunciado en el inicio de la consulta pública.

El cuarto y último borrador de discusión se publicó el 31 de mayo de 2007. ^{[ 33 ]} Introdujo la compatibilidad con la versión 2.0 de la Licencia Apache (ya que las versiones anteriores son incompatibles); aclaró el papel de los contratistas externos; e hizo una excepción para evitar problemas percibidos con un acuerdo al estilo Microsoft-Novell, estableciendo en la Sección 11, párrafo 6, lo siguiente:

No podrá transmitir una obra protegida si es parte de un acuerdo con un tercero que se dedica a la distribución de software, en virtud del cual usted realiza un pago a dicho 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 protegida de usted, una licencia de patente discriminatoria  ...

Esta excepción tenía como objetivo hacer ineficaces tales acuerdos futuros. La licencia también pretendía obligar a Microsoft a tomar medidas: extender las licencias de patente que había otorgado a los clientes de Novell para el uso del software GPLv3 a todos los usuarios de dicho software; esta extensión solo era posible si Microsoft era legalmente un "distribuidor" del software GPLv3. ^{[ 34 ]}

Los primeros borradores de la GPLv3 también permitían a los licenciantes añadir un requisito similar al de la AGPL que habría resuelto una laguna en la GPL relativa a los proveedores de servicios de aplicaciones . ^{[ 35 ] [ 36 ]} La libertad de ejecutar, estudiar y compartir el código fuente, así como garantizar las protecciones de copyleft, resulta algo ambigua en el contexto de los servicios web. Sin embargo, surgieron preocupaciones sobre los costes administrativos de comprobar el código para los requisitos adicionales propuestos en los primeros borradores de la GPLv3; finalmente se decidió mantener separadas la GPL y la AGPL. ^{[ 37 ]}

Otros encuestados —en particular desarrolladores de alto perfil del kernel de Linux como Linus Torvalds , Greg Kroah-Hartman y Andrew Morton— utilizaron comentarios en los medios y declaraciones públicas para objetar partes de los borradores de la GPLv3. ^{[ 38 ]} Los desarrolladores del kernel desaprobaron las cláusulas sobre DRM (y tivoización), patentes y "restricciones adicionales"; además, advirtieron sobre una " balcanización " del "Universo del Código Abierto". ^{[ 38 ] [ 39 ]} Linus Torvalds, quien optó por no adoptar la GPLv3 para el kernel de Linux, ^{[ 40 ]} reiteró su crítica varios años después. ^{[ 41 ] [ 42 ]}

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 la que no se podía combinar la GPLv2). ^{[ 43 ]} Sin embargo, el software GPLv3 solo podía combinarse y compartir código con software GPLv2 si se cumplían dos condiciones: la licencia GPLv2 utilizada contení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, ^{[ 44 ]} el desarrollador de Toybox, Rob Landley, la describió como una cláusula de rescate . ^{[ c ]} Entre los proyectos de software licenciados con la cláusula opcional "o posterior" se incluyen Joomla ^{[ 47 ]} y el Proyecto GNU , ^{[ 48 ]} mientras que un ejemplo destacado sin esta cláusula es el kernel de Linux. ^{[ 40 ] [ 49 ]}

La versión final del texto de la licencia GPLv3 se publicó el 29 de junio de 2007. ^{[ 50 ]}

El software bajo la GPL puede utilizarse para cualquier propósito, incluidos los comerciales, e incluso como herramienta para crear software propietario , como cuando se utilizan compiladores con licencia GPL . ^{[ 52 ]} Los usuarios o empresas que distribuyen obras con licencia GPL (por ejemplo, software) pueden cobrar una tarifa por las copias o proporcionarlas gratuitamente. Esto distingue a la GPL de otros dos tipos de licencia: las licencias de software shareware que permiten la copia para uso personal pero prohíben la distribución comercial, y las licencias propietarias donde la copia está prohibida por la ley de derechos de autor . La FSF afirma que el software libre que respeta la libertad no debe restringir el uso y la distribución comercial (incluida la redistribución): ^{[ 51 ] [ 53 ]}

Para uso exclusivamente privado (o interno), sin venta ni distribución, el código del software puede modificarse y reutilizarse parcialmente sin necesidad de publicar el código fuente. Para su venta o distribución, es necesario que el código fuente completo esté disponible para los usuarios finales, incluyendo cualquier modificación o adición. En ese caso, se aplica la licencia copyleft para garantizar que los usuarios finales conserven las libertades mencionadas anteriormente.

Sin embargo, el software que se ejecuta como un programa de aplicación bajo un sistema operativo con licencia GPL (como Linux) no requiere tener licencia GPL ni distribuirse con disponibilidad de código fuente; la licencia depende únicamente de las bibliotecas y componentes de software utilizados, pero no de la plataforma subyacente. ^{[ 54 ]} Por ejemplo, si un programa consta únicamente de 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 ni necesitan poner su código fuente a disposición; incluso si el sistema operativo subyacente utilizado tiene licencia GPL, las aplicaciones que se ejecutan en el sistema no se consideran obras derivadas. ^{[ 54 ]} Solo si se utilizan partes con licencia GPL en un programa (y el programa se distribuye) todo el demás código fuente del programa debe ponerse a disposición bajo los mismos términos de licencia. La Licencia Pública General Reducida de GNU (LGPL) fue diseñada para tener un copyleft más débil que la GPL, ya que la LGPL no exige que el código fuente desarrollado a medida (a diferencia de las partes con licencia LGPL) esté disponible bajo los mismos términos de licencia.

La quinta sección de la GPLv3 establece que ningún código con licencia GPL se considerará una "medida de protección técnica" efectiva, según lo define el Artículo 11 del Tratado de la OMPI sobre Derecho de Autor , y que quienes distribuyen 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 mediante el ejercicio de los derechos conferidos por esta Licencia con respecto a la obra protegida". Esta declaración significa que los usuarios no pueden ser considerados responsables por eludir la gestión de derechos digitales (DRM) implementada en el código con licencia GPLv3, según leyes como la Ley de Derechos de Autor del Milenio Digital (DMCA) de los Estados Unidos. ^{[ 55 ]}

Los derechos de distribución otorgados por la GPL para versiones modificadas de una obra no son incondicionales. Cuando una persona distribuye una obra con licencia GPL junto con sus propias modificaciones, los requisitos para distribuir la obra completa no pueden ser mayores que los establecidos en la GPL. Este requisito se conoce como copyleft y su validez legal se deriva del uso de los derechos de autor en los programas informáticos.

Dado que una obra bajo licencia GPL está protegida por derechos de autor, el licenciatario no tiene derecho a redistribuirla, salvo bajo los términos de la licencia. Solo se requiere el cumplimiento de los términos de la GPL para ejercer derechos normalmente restringidos por la ley de derechos de autor, como la redistribución. Por el contrario, si una persona distribuye copias de la obra sin respetar los términos de la GPL (por ejemplo, manteniendo el código fuente en secreto), el autor original puede demandarla en virtud de la ley de derechos de autor.

Históricamente, la ley de derechos de autor se ha utilizado para impedir la distribución de obras por parte de personas no autorizadas por el creador. Copyleft utiliza las mismas leyes de derechos de autor para lograr un objetivo muy diferente. Copyleft otorga derechos de distribución a todas las partes, siempre que estas otorguen los mismos derechos a las partes subsiguientes, y estas a las siguientes, y así sucesivamente. De esta manera, la GPL y otras licencias copyleft intentan garantizar el acceso libre a la obra y a todos sus derivados. ^{[ 56 ]}

Muchos distribuidores de programas con licencia GPL incluyen el código fuente junto con los ejecutables . Una forma alternativa de cumplir con el copyleft es ofrecer por escrito el código fuente en un soporte físico (como un CD) previa solicitud. En la práctica, muchos programas con licencia GPL se distribuyen por internet, y el código fuente se pone a disposición mediante el protocolo FTP o HTTP . Para la distribución por internet, este método cumple con la licencia.

Copyleft se aplica solo cuando una persona busca redistribuir el programa. Los desarrolladores pueden crear versiones privadas modificadas sin obligación de divulgar las modificaciones, siempre que no distribuyan el software modificado a ninguna otra persona. Copyleft se aplica solo al software, pero no a su salida (a menos que esa salida sea en sí misma una obra derivada del programa). ^{[ e ]} Por ejemplo, un portal web público que ejecuta una versión modificada de un sistema de gestión de contenido con licencia GPL no está obligado a distribuir sus cambios al software subyacente; esto se debe a que el portal web modificado no se está redistribuyendo, sino que se está alojando, y también a que la salida del portal web no es una obra derivada del sistema de gestión de contenido con licencia GPL.

Algunas personas han debatido si la publicación de código fuente ofuscado constituye una violación de la GPLv1 , por ejemplo, en casos donde el autor no está dispuesto a hacerlo público. El consenso del debate consideró que dicha publicación era poco ética, pero no una violación de la licencia. El problema se aclaró cuando la GPL se modificó en la versión 2 para exigir que se pusiera a disposición la versión "preferida" del código fuente. ^{[ 58 ]}

La GPL fue diseñada como una licencia , no como un contrato. ^{[ 59 ]} En algunas jurisdicciones de derecho anglosajón , la distinción legal entre una licencia y un contrato es importante: los contratos son exigibles por el derecho contractual , mientras que las licencias se hacen cumplir bajo el derecho de autor . Sin embargo, esta distinción no es útil en muchas jurisdicciones sin diferencias entre contratos y licencias, como los sistemas de derecho civil . ^{[ 60 ]}

Las personas que rechazan 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 ni obras derivadas. Sin embargo, si estas personas no redistribuyen el programa con licencia GPL, aún pueden usar el software dentro de su organización como deseen, y las obras (incluidos los programas) creadas utilizando el programa no tienen por qué estar cubiertas por esta licencia. ^{[ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ]}

En 2007, la desarrolladora de software Allison Randal argumentó que la GPLv3 (como licencia) es innecesariamente confusa para los lectores no especializados, y que podría simplificarse manteniendo las mismas condiciones y fuerza legal. ^{[ 68 ]}

En abril de 2017, un tribunal federal de EE. UU. dictaminó que una licencia de código abierto es un contrato ejecutable. ^{[ 69 ]}

En octubre de 2021, la organización Software Freedom Conservancy (como usuario final) demandó a la empresa Vizio (como titular de los derechos de autor) por incumplimiento de contrato; el objetivo de la demanda era obtener el código fuente de los televisores de Vizio. Un juez federal dictaminó provisionalmente que la GPL es un contrato exigible por los usuarios finales, así como una licencia para los titulares de los derechos de autor. ^{[ 70 ]}

La Licencia Pública General Modificada GNAT (abreviada: GPL Modificada , GMGPL ) es una versión de la Licencia Pública General de GNU específicamente modificada para unidades compiladas y para la característica genérica que se encuentra en el lenguaje de programación Ada . La modificación es la siguiente:

Como excepción especial, si otros archivos instancian genéricos a partir de esta unidad, o si se enlaza esta unidad con otros archivos para generar un ejecutable, esta unidad por sí sola no hace que el ejecutable resultante esté cubierto por la Licencia Pública General de GNU. Sin embargo, esta excepción no invalida ninguna otra razón por la que el archivo ejecutable pudiera estar cubierto por la Licencia Pública General de GNU.

El compilador GNAT Ada puede automatizar las comprobaciones de conformidad para algunos problemas de licencias de software GPL mediante una directiva del compilador . Úsela pragma License (Modified_GPL);para activar la comprobación contra la GPL modificada. El Manual de referencia de GNAT ^{[ 74 ]} documenta la directiva License ^{[ 75 ]} junto con otras directivas del compilador.

Según la FSF, «La GPL no exige que publiques tu versión modificada ni ninguna parte de ella. Eres libre de hacer modificaciones y usarlas de forma privada, sin publicarlas jamás». ^{[ 76 ]} Sin embargo, si una persona publica una entidad con licencia GPL, surge una cuestión sobre el enlace, concretamente, si un programa propietario que utiliza una biblioteca GPL infringe la GPL.

La cuestión clave radica en si el software que no se rige por la GPL puede enlazarse de forma estática o dinámica con bibliotecas GPL de manera legal. Existen diferentes opiniones al respecto. La GPL es clara al exigir que todas las obras derivadas de código bajo su licencia también deben estar bajo la misma licencia. La ambigüedad surge en lo que respecta al uso de bibliotecas GPL y la inclusión de software GPL en un paquete más grande (quizás integrado en un archivo binario mediante enlace estático).

El mero hecho de comunicarse con otros programas no requiere, por sí solo, que todo el software sea GPL; tampoco lo requiere distribuir software GPL junto con software que no lo sea. Sin embargo, deben cumplirse ciertas condiciones menores que garantizan que no se restrinjan los derechos del software GPL. A continuación, se cita una parte de las preguntas frecuentes sobre la GPL (en gnu.org ), que describe hasta qué punto se permite que el software se comunique con programas GPL y se incluya en paquetes con ellos: ^{[ 86 ]}

¿Cuál es la diferencia entre un "agregado" y otros tipos de "versiones modificadas"?

Un «conjunto» consta de varios programas independientes, distribuidos juntos en un mismo CD-ROM u otro soporte. La GPL permite crear y distribuir un conjunto, incluso cuando las licencias del resto del software no son libres o son incompatibles con la GPL. La única condición es que no se puede distribuir el conjunto bajo una licencia que impida a los usuarios ejercer los derechos que les otorgaría la licencia individual de cada programa.

¿Dónde está el límite entre dos programas separados y un programa dividido en 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 (ejecución, tuberías, RPC, llamadas a funciones dentro de un espacio de direcciones compartido, etc.) como de la semántica de la comunicación (qué tipo de información se intercambia).

Si los módulos se incluyen en el mismo archivo ejecutable, sin duda se combinan en un solo programa. Si los módulos están diseñados para ejecutarse enlazados en un espacio de direcciones compartido, casi con toda seguridad se combinan en un solo programa.

En cambio, las tuberías, los sockets y los argumentos de línea de comandos son mecanismos de comunicación que normalmente se utilizan entre dos programas distintos. Por lo tanto, cuando se emplean para la comunicación, los módulos suelen ser programas independientes. Sin embargo, si la semántica de la comunicación es lo suficientemente compleja, con el intercambio de estructuras de datos internas complejas, esto también podría justificar considerar las dos partes como integradas en un programa mayor.

La FSF, por lo tanto, establece una distinción entre "biblioteca" y "otro programa" a través de dos aspectos de la situación: la "complejidad" y la "intimidad" del intercambio de información, y el mecanismo (más que la semántica). Sin embargo, la fundación reconoce que la cuestión no es sencilla y que la jurisprudencia determinará el resultado en situaciones complejas.

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 (para teléfonos inteligentes y PC). El problema radica en el derecho a "hacer una copia para el prójimo", ya que este derecho se ve vulnerado por los sistemas de gestión de derechos digitales (DRM) integrados en la plataforma para impedir la copia de software de pago. Incluso si la aplicación es gratuita en la tienda de aplicaciones en cuestión, copiarla podría constituir una violación de los términos de dicha tienda. ^{[ 155 ]}

Existe una distinción entre una tienda de aplicaciones , que vende software con restricciones DRM bajo licencias propietarias, y el concepto más general de distribución digital a través de algún tipo de repositorio de software en línea . Prácticamente todos los sistemas Unix modernos y las distribuciones de Linux tienen repositorios de aplicaciones, incluidos NetBSD , FreeBSD , Ubuntu , Fedora y Debian . 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). ^{[ 156 ]} En otros casos, como la tienda de aplicaciones de Ubuntu , las aplicaciones de software comercial propietarias y las aplicaciones con licencia GPL están disponibles a través del mismo sistema. La Mac App Store (junto con proyectos similares) no es incompatible con las aplicaciones con licencia GPL por razones inherentes al concepto de una tienda de aplicaciones; más bien, la incompatibilidad se debe específicamente al requisito de los términos de uso de Apple: que todas las aplicaciones en la tienda utilicen las restricciones DRM de Apple. ^{[ 155 ]} Por el contrario, la tienda de aplicaciones de Ubuntu no tiene tal requisito: "Estos términos no limitan ni restringen sus derechos bajo ninguna licencia de software de código abierto aplicable." ^{[ 157 ]}

En 2001, el CEO de Microsoft, Steve Ballmer, se refirió a Linux como "un cáncer que se adhiere, en términos de propiedad intelectual, a todo lo que toca". ^{[ 158 ] [ 159 ]} En respuesta a los ataques de Microsoft contra la GPL, varios desarrolladores y defensores prominentes del software libre publicaron una declaración conjunta en apoyo de la licencia. ^{[ 160 ]} Microsoft lanzó Microsoft Windows Services para UNIX , que contiene código con licencia GPL. En julio de 2009, Microsoft publicó un conjunto de aproximadamente 20 000 líneas de código de controlador de Linux bajo la GPL. ^{[ 161 ]} El código del hipervisor Hyper-V en esta versión utilizó componentes de código abierto con licencia GPL; este código estaba originalmente vinculado estáticamente a partes binarias propietarias, lo cual no está permitido en el software con licencia GPL. ^{[ 162 ]}

El proyecto FreeBSD ha declarado que «un uso menos conocido e involuntario de la GPL es que resulta muy favorable para las grandes empresas que desean competir con las compañías de software. En otras palabras, la GPL es muy adecuada para usarse como arma de marketing, lo que podría reducir el beneficio económico general y contribuir a comportamientos monopolísticos». El proyecto también afirmó que la GPL puede «representar un verdadero problema para quienes desean comercializar software y obtener beneficios». ^{[ 169 ]}

Richard Stallman escribió sobre un ejemplo de práctica de comercialización éticamente aceptable: la práctica de vender excepciones a las licencias de software libre. Esta práctica implica que el titular de los derechos de autor de un software determinado toma dos medidas:

• Libera el software (junto con el código fuente correspondiente) al público bajo una licencia de software libre.
• "[Luego permite a los clientes pagar por el permiso para usar el mismo código bajo diferentes condiciones, por ejemplo, permitiendo su inclusión en aplicaciones propietarias".

Stallman consideraba que la práctica de vender excepciones era "aceptable desde la década de 1990, y en ocasiones la he sugerido a empresas. A veces, este enfoque ha permitido que programas importantes se conviertan en software libre". Si bien la FSF no practica la venta de excepciones, propone una comparación con la licencia X11 (una licencia de software libre sin copyleft) para sugerir que esta técnica de comercialización se considere éticamente aceptable. Publicar un programa bajo una licencia de software libre sin copyleft permitiría integrar el código en software propietario. Stallman comenta que «o bien debemos concluir que es incorrecto publicar cualquier cosa bajo la licencia X11 —una conclusión que me parece inaceptablemente extrema— o bien rechazar esta implicación. Usar una licencia que no sea copyleft es débil y, por lo general, una opción inferior, pero no es incorrecto. En otras palabras, vender excepciones permite cierta integración en software propietario, y la licencia X11 permite aún más integración. Si esto no hace que la licencia X11 sea inaceptable, tampoco hace que vender excepciones sea inaceptable». ^{[ 170 ]}

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, titulado "El laberinto de la libertad del software". ^{[ 171 ] [ 172 ]}

Como parodia de la GPL, la versión 2 de la Licencia Pública Haz Lo Que Te Dé La Mano (WTFPL) fue creada por el líder del proyecto Debian, Sam Hocevar, en 2004. ^{[ 173 ]}

En 2005, el defensor del software de código abierto Eric S. Raymond cuestionó la relevancia de la GPL en ese momento para el ecosistema FOSS, afirmando que «Ya no necesitamos la GPL. Se basa en la creencia de que el software de código abierto es débil y necesita ser protegido. El código abierto tendría más éxito si la GPL no pusiera nerviosa a mucha gente a la hora de adoptarlo». ^{[ 174 ]} Richard Stallman respondió que «La GPL está diseñada para... garantizar que cada usuario de un programa obtenga las libertades esenciales: ejecutarlo, estudiar y modificar el código fuente, redistribuir copias y publicar versiones modificadas  ... [Raymond] aborda el tema en términos de objetivos y valores diferentes: los del "código abierto", que no incluyen la defensa de la libertad de los usuarios de software para compartir y modificar el software». ^{[ 175 ]}

En 2007, Allison Randal , quien participó en el comité de redacción de la GPL, criticó la GPLv3 por ser incompatible con la GPLv2 ^{[ 176 ]} y por carecer de claridad en su formulación. ^{[ 68 ]} De manera similar, ese mismo año, William Hurley (también conocido como Whurly) previó el declive de la GPL debido a su falta de enfoque en los desarrolladores con la GPLv3, lo que los alentaría a adoptar licencias permisivas. ^{[ 177 ]}

En un artículo de 2009 en el sitio web de InformIT , David Chisnall describió "El fracaso de la GPL": problemas como su incompatibilidad y la complejidad de su texto de licencia. ^{[ 178 ]}

En 2014, el desarrollador y ejecutivo Bryan Cantrill calificó la licencia GPL de copyleft como un " antipatrón de código abierto corporativo " por ser "anticolaborativa"; recomendó en su lugar licencias de software permisivas . ^{[ 179 ]}

En septiembre de 2006, durante el proceso de redacción de la GPLv3, varios desarrolladores destacados del kernel de Linux —como Linus Torvalds, Greg Kroah-Hartman y Andrew Morton— advirtieron sobre una división en la comunidad FOSS: «la publicación de la GPLv3 presagia la balcanización de todo el universo de código abierto del que dependemos». ^{[ 38 ]} De manera similar, Benjamin Mako Hill argumentó casi al mismo tiempo que una comunidad unida y colaborativa es más importante que una sola licencia. ^{[ 180 ]}

Después de que se publicó la GPLv3 en 2007, algunos periodistas ^{[ 42 ] [ 139 ] [ 181 ]} y el desarrollador de Toybox , Rob Landley ^{[ 45 ] [ 46 ]} criticaron la publicación: con la introducción de la GPLv3, la división entre las comunidades de código abierto y software libre se había ampliado, porque la GPLv3 significativamente extendida es esencialmente incompatible con la GPLv2. ^{[ 111 ]} La compatibilidad solo se proporciona bajo la cláusula opcional "o posterior" de la GPL; esta opción no fue seguida por el kernel de Linux, entre otros programas. ^{[ 40 ]} Antes de la publicación de la GPLv3, Bruce Byfield señaló que la GPLv2 era un elemento unificador entre las comunidades de código abierto y software libre. ^{[ 139 ]}

Para la LGPLv3, el mantenedor de GNU TLS, Nikos Mavrogiannopoulos, argumentó de manera similar: "Si asumimos que el objetivo principal [de la LGPLv3] es ser utilizada por software libre, entonces claramente no lo logra"; esta declaración se hizo después de que Mavrogiannopoulos cambiara la licencia de la biblioteca GnuTLS de LGPLv3 a LGPLv2.1, debido a problemas de compatibilidad de licencias. ^{[ 182 ] [ 183 ]}

En 2007, Lawrence Rosen , abogado y especialista en informática, elogió cómo la comunidad que utilizaba la licencia Apache podía colaborar 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. En este sentido, afirmó: «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». ^{[ 184 ]}

En julio de 2013, Armin Ronacher (creador del framework Flask ) llegó a una conclusión menos optimista sobre la compatibilidad de la GPL en el ecosistema FOSS: "Cuando interviene la GPL, las complejidades de las licencias se convierten en una versión poco divertida de un acertijo"; también señaló que el conflicto entre la Licencia Apache 2.0 y la GPLv2 seguía teniendo un impacto en el ecosistema. ^{[ 185 ]}