La Licencia Pública General GNU ( GNU GPL o simplemente GPL ) es una serie de licencias de software libre o copyleft ampliamente utilizadas que garantizan a los usuarios finales las cuatro libertades para ejecutar, estudiar, compartir y modificar el software. [7] La licencia fue el primer 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 informático los derechos de la Definición de Software Libre . [8] Estas series 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 Reducida y aún más distinta de las licencias de software permisivas más utilizadas 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 gratuitos destacados con licencia GPL se incluyen el kernel de 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 , dando a los programadores que contribuyeron al kernel 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 devolver nada 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 actualizada, 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. Los proyectos de software con licencia con la cláusula opcional "o posterior" incluyen el Proyecto GNU, mientras que el kernel de Linux, por ejemplo, solo tiene licencia GPLv2.
La cláusula "o cualquier versión posterior" a veces se conoce como cláusula de bote salvavidas, ya que permite combinaciones entre diferentes versiones de software con licencia GPL para mantener la compatibilidad.
La GPL fue escrita por Richard Stallman en 1989, para su uso con programas lanzados como parte del proyecto GNU. La GPL original se basó en una unificación de licencias similares utilizadas para las primeras versiones de GNU Emacs (1985), [14] GNU Debugger y GNU C Compiler . [15] Estas licencias contenían disposiciones similares a las de la GPL moderna, pero eran específicas de 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 que muchos proyectos compartan código.
La segunda versión de la licencia, la versión 2, se lanzó en 1991. Durante los siguientes 15 años, los miembros de la comunidad de software libre comenzaron a preocuparse por problemas en la licencia GPLv2 que podrían permitir a alguien explotar el software con licencia GPL de maneras contrarias a las de la licencia. intención. [17] Estos problemas incluían 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 Licencia Pública General Affero y acuerdos de patentes entre Microsoft y distribuidores de software libre y gratuito. software de código abierto, que algunos vieron como un intento de utilizar las patentes como arma contra la comunidad del software libre.
La versión 3 se desarrolló para intentar abordar estas preocupaciones y se publicó oficialmente el 29 de junio de 2007. [18]
La versión 1 de GNU GPL, [19] publicada el 25 de febrero de 1989, [20] evitó lo que entonces eran las dos formas principales en que los distribuidores de software restringían las libertades que definen el software libre. El primer problema fue que los distribuidores sólo pueden publicar archivos binarios que sean ejecutables, pero no legibles ni modificables por humanos. Para evitar esto, GPLv1 declaró que copiar y distribuir copias de cualquier parte del programa también debe hacer que el código fuente legible por humanos esté disponible bajo los mismos términos de licencia. [a]
El segundo problema era que los distribuidores podían agregar restricciones, ya sea a la licencia o combinando el software con otro software que tenía otras restricciones de distribución. La unión de dos conjuntos de restricciones se aplicaría al trabajo combinado, añadiendo así restricciones inaceptables. Para evitar esto, la GPLv1 estableció que las versiones modificadas, en su conjunto, debían distribuirse según los términos de la GPLv1. [b] Por lo tanto, el software distribuido bajo los términos de GPLv1 podría combinarse con software bajo términos más permisivos, ya que esto no cambiaría los términos bajo los cuales podría distribuirse el conjunto. Sin embargo, el software distribuido bajo GPLv1 no podría combinarse con software distribuido bajo una licencia más restrictiva, ya que esto entraría en conflicto con el requisito de que todo sea distribuible bajo los términos de GPLv1.
Según Richard Stallman, el cambio más importante en la GPLv2 fue la cláusula "Libertad o Muerte", como él la llama [16] – Sección 7. La sección dice que los licenciatarios pueden distribuir una obra cubierta por la GPL sólo si pueden satisfacer todos los requisitos. obligaciones de la licencia, sin perjuicio de cualesquiera otras obligaciones legales que pudieran tener. En otras palabras, las obligaciones de la licencia no pueden separarse debido a obligaciones contradictorias. Esta disposición tiene como objetivo disuadir a cualquier parte de utilizar un reclamo por infracción de patente u otro litigio para afectar la libertad de los usuarios bajo la licencia. [dieciséis]
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 esencialmente hacían el trabajo de las existentes; [21] cuando se lanzó 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 Biblioteca GNU, numerada con la versión 2 para mostrar que ambas eran complementarias. [22] Los números de versión divergieron en 1999 cuando se lanzó la versión 2.1 de LGPL, que la renombró Licencia Pública General Reducida GNU para reflejar su lugar en la filosofía. La GPLv2 también se modificó para referirse al nuevo nombre de LGPL, pero su número de versión siguió siendo el mismo, lo que provocó que el Software Package Data Exchange (SPDX) no reconociera la GPLv2 original. [23] [ verificación fallida ]
La licencia incluye instrucciones para especificar "la 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 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 (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 planeó originalmente para entre nueve y quince meses, pero finalmente se extendió a dieciocho meses y se publicaron cuatro borradores. La GPLv3 oficial fue publicada por la FSF el 29 de junio de 2007. 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 produjeron en relación con las patentes de software , la compatibilidad de las licencias de software libre , la definición de "código fuente" y las restricciones de hardware en las modificaciones de software, como la tivoización . [24] [26] Otros cambios relacionados con la internacionalización, cómo se manejan las violaciones de licencia y cómo el titular de los derechos de autor podría otorgar permisos adicionales. Se definió explícitamente el concepto de "propagación de software", como término para 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 , [27] y otros grupos de software libre. Los comentarios se recopilaron del público a través del portal web gplv3.fsf.org, [28] utilizando un software especialmente diseñado llamado stet .
Durante el proceso de consulta pública se presentaron 962 comentarios al 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 lenguaje destinado a evitar acuerdos relacionados con patentes, como el controvertido acuerdo de patentes Microsoft-Novell , y restringía las cláusulas anti-tivoización a una definición legal de "usuario". y un "producto de consumo". También eliminó explícitamente la sección sobre "Limitaciones geográficas", cuya probable eliminación había sido anunciada 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 estilo Microsoft-Novell, que dice 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 la distribución de software, en virtud del cual realiza un pago al tercero en función del alcance de su actividad de transmisión de la obra, y bajo el cual el tercero otorga, a cualquiera de las partes que recibiría de usted el trabajo cubierto, una licencia de patente discriminatoria ...
Esto tenía como objetivo hacer que futuros acuerdos de este tipo sean ineficaces. La licencia también tenía como objetivo que Microsoft extendiera las licencias de patente que otorgó 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 fuera legalmente un "transmisor" del software GPLv3. [33]
Los primeros borradores de GPLv3 también permitieron a los licenciantes agregar un requisito similar a Affero que habría tapado la laguna 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 la licencia GPL y Affero separadas. [36]
Otros, en particular algunos desarrolladores de kernel de Linux de alto perfil como Linus Torvalds , Greg Kroah-Hartman y Andrew Morton , comentaron en 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] El kernel Los desarrolladores se refirieron al borrador de cláusulas 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, quien decidió no adoptar la GPLv3 para el kernel de Linux, [39] reiteró sus críticas varios años después. [40] [41]
GPLv3 mejoró la compatibilidad con varias licencias de software libre, como la licencia Apache, versión 2.0, y la licencia pública general GNU Affero, con la que no se podía combinar GPLv2. [42] Sin embargo, el software GPLv3 solo podría combinarse 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 actualizó a GPLv3. Si bien la FSF considera que la cláusula "GPLv2 o cualquier versión posterior" es la forma más común de concesión de licencia de software GPLv2, [43] el desarrollador de Toybox , Rob Landley, la describió como una cláusula de bote salvavidas . [c] Los proyectos de software con licencia con la cláusula opcional "o posterior" incluyen el Proyecto GNU , [ cita requerida ] mientras que un ejemplo destacado sin la cláusula es el kernel de 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 estar disponibles para cualquiera que reciba una copia del trabajo al que se le aplica una GPL ("el licenciatario"). Cualquier licenciatario que cumpla con los términos y condiciones recibe permiso para modificar el trabajo, así como para copiar y redistribuir el trabajo 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 establece además que un distribuidor no puede imponer "más restricciones a los derechos otorgados por la GPL". Esto prohíbe actividades como la distribución del software en virtud de un acuerdo o contrato de confidencialidad.
La cuarta sección para la versión 2 de la licencia y la séptima sección de la versión 3 requieren que los programas distribuidos como binarios precompilados vayan acompañados de una copia del código fuente, una oferta por escrito para distribuir el código fuente a través del mismo mecanismo que el pre -binario compilado, 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 requieren entregar "a todos los destinatarios una copia de esta Licencia junto con el Programa". La versión 3 de la licencia permite que el código fuente esté disponible de formas adicionales en cumplimiento de la séptima sección. Estos 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 esté disponible y haya "instrucciones claras" sobre dónde encontrar el código fuente.
La FSF no posee los derechos de autor de una obra publicada bajo la GPL a menos que un autor asigne explícitamente los derechos de autor a la FSF (lo que rara vez ocurre, excepto para los programas que forman parte del proyecto GNU). Sólo los titulares de derechos de autor individuales tienen la autoridad para demandar cuando se sospecha una violación de la licencia.
El software bajo GPL se puede ejecutar para todos los fines, incluidos fines 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 bajo licencia GPL (por ejemplo, software), pueden cobrar una tarifa por las copias o entregarlas de forma gratuita. Esto distingue 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 de propiedad donde la copia está prohibida por la ley de derechos de autor . La FSF sostiene que el software libre que respeta la libertad tampoco debería restringir el uso y la distribución comerciales (incluida la redistribución): [48]
En uso puramente privado (o interno), sin ventas ni distribución, el código del software se puede modificar y reutilizar partes sin necesidad de publicar el código fuente. Para la venta o distribución, todo el código fuente debe estar disponible para los usuarios finales, incluidos los cambios y adiciones al código; en ese caso, se aplica copyleft para garantizar que los usuarios finales conserven las libertades definidas anteriormente. [50]
Sin embargo, el software que se ejecuta como programa de aplicación bajo un sistema operativo con licencia GPL, como Linux, no necesita tener licencia GPL ni distribuirse con disponibilidad de código fuente; la licencia depende únicamente de las bibliotecas y componentes de software utilizados y no de la plataforma subyacente. [51] 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 y no es necesario que su código fuente esté disponible; Incluso si el sistema operativo subyacente utilizado tiene la licencia GPL, las aplicaciones que se ejecutan en él no se consideran trabajos derivados. [51] Sólo si se utilizan partes 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 (LGPL) de GNU se creó para tener un copyleft más débil que la GPL, ya que no requiere que un código fuente desarrollado a medida (distinto de las partes 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 técnica de protección" efectiva tal como se define en el artículo 11 del Tratado de Copyright de la OMPI , y que quienes transmiten 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 previstos en esta Licencia con respecto a la obra cubierta". Esto significa que los usuarios no pueden ser considerados responsables por eludir el DRM implementado utilizando código con licencia GPLv3 según leyes como la Ley de Derechos de Autor del Milenio Digital (DMCA) de EE. UU. [52]
Los derechos de distribución otorgados por la GPL para versiones modificadas de la obra no son incondicionales. Cuando alguien distribuye una obra sujeta a la GPL más sus propias modificaciones, los requisitos para distribuir la obra completa no pueden ser mayores que los requisitos de la GPL.
Este requisito se conoce como copyleft. Obtiene su poder legal del uso de derechos de autor en programas de software. Debido a que una obra GPL tiene derechos de autor, el licenciatario no tiene derecho a redistribuirla, ni siquiera en forma modificada (salvo el uso legítimo ), excepto según los términos de la licencia. Sólo se requiere cumplir con los términos de la GPL si se 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 respetar los términos de la GPL (por ejemplo, manteniendo el código fuente en secreto), el autor original puede demandarlo 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 partes no autorizadas por el creador. Copyleft utiliza las mismas leyes de derechos de autor para lograr un objetivo muy diferente. Otorga derechos de distribución a todas las partes en la medida en que proporcionen los mismos derechos a las siguientes, y éstas a las siguientes, etc. De esta manera, la GPL y otras licencias copyleft intentan imponer el acceso libre a la obra y a todos sus derivados. [53]
Muchos distribuidores de programas bajo GPL incluyen el código fuente con los ejecutables . Un método alternativo para satisfacer el copyleft es proporcionar una oferta por escrito para proporcionar el código fuente en un medio físico (como un CD) previa solicitud. En la práctica, muchos programas con licencia GPL se distribuyen a través de Internet y el código fuente está disponible a través de FTP o HTTP . Para la distribución por Internet, esto cumple con la licencia.
El copyleft se aplica sólo cuando una persona busca redistribuir el programa. Los desarrolladores pueden crear versiones modificadas privadas sin obligación de divulgar las modificaciones, siempre y cuando no distribuyan el software modificado a nadie más. Copyleft se aplica sólo al software, y no a su salida (a menos que esa salida sea en sí misma 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 GPL no está obligado a distribuir sus cambios al software subyacente, porque el portal web modificado no se redistribuye sino que se aloja, y también porque El resultado del portal web tampoco es un trabajo derivado del sistema de gestión de contenido GPL.
Ha habido un debate sobre 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 está menos dispuesto a hacer que el código fuente esté disponible. El consenso fue que, si bien no era ético, no se consideraba una violación. El problema se aclaró cuando se modificó la licencia con v2 para exigir que la versión "preferida" del código fuente estuviera disponible. [55]
La GPL fue diseñada como una licencia , más que como un contrato. [56] En algunas jurisdicciones de Common Law , la distinción legal entre una licencia y un contrato es importante: los contratos se pueden hacer cumplir mediante la ley contractual , mientras que las licencias se hacen cumplir según la ley de derechos de autor . Sin embargo, esta distinción no es útil en muchas jurisdicciones donde no existen 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 u trabajos derivados con licencia GPL. Sin embargo, si no redistribuyen el programa GPL, aún pueden usar el software dentro de su organización como quieran, y no es necesario que los trabajos (incluidos los programas) construidos mediante el uso del programa estén cubiertos por esta licencia.
La desarrolladora de software Allison Randal argumentó que la GPLv3 como licencia es innecesariamente confusa para los lectores no especializados y podría simplificarse manteniendo las mismas condiciones y fuerza legal. [58]
En abril de 2017, un tribunal federal de EE. UU. dictaminó que una licencia de código abierto es un contrato ejecutable. [59]
En octubre de 2021, SFC demandó a Vizio por incumplimiento de contrato como usuario final para solicitar el código fuente para los televisores de Vizio; mientras tanto, un juez federal dictaminó que la GPL es un contrato ejecutable por parte de los usuarios finales, así como una licencia para los titulares de derechos de autor. [60]
El texto de la GPL tiene derechos de autor , y los derechos de autor pertenecen a la Free Software Foundation.
La FSF permite a las personas crear nuevas licencias basadas en la GPL, siempre que las licencias derivadas no utilicen el preámbulo de la GPL sin permiso. Sin embargo, se desaconseja esto, ya que dicha licencia podría ser incompatible con la GPL [61] y provocar una percepción de proliferación 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 .
El texto de la GPL no está bajo la GPL. Los derechos de autor de la licencia no permiten la modificación de la licencia. 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 preguntas frecuentes 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 el permiso para utilizarlo de la Free Software Foundation (FSF). [63]
Según la FSF, "La GPL no requiere que usted publique su versión modificada o cualquier parte de ella. Usted es libre de realizar modificaciones y utilizarlas de forma privada, sin siquiera publicarlas". [64] Sin embargo, si uno hace pública una entidad con licencia GPL, existe un problema relacionado con la vinculación: es decir, si un programa propietario que utiliza una biblioteca GPL viola la GPL.
Esta disputa clave es si el software que no es GPL puede vincularse legalmente de forma estática o dinámica a bibliotecas GPL. Existen diferentes opiniones sobre este tema. La GPL es clara al exigir que todos los trabajos derivados de código bajo la GPL deben estar ellos mismos bajo la GPL. Surge ambigüedad con respecto al uso de bibliotecas GPL y la agrupación de software GPL en un paquete más grande (quizás mezclado en un binario mediante enlaces estáticos). En última instancia, esta no es una cuestión de la GPL per se , sino de cómo la ley de derechos de autor define las obras derivadas. Existen los siguientes puntos de vista:
La Free Software Foundation (que posee los derechos de autor de varios productos de software notables con licencia GPL y del propio texto de la licencia) afirma que un ejecutable que utiliza una biblioteca vinculada dinámicamente es de hecho un trabajo derivado. Sin embargo, esto no se aplica a programas separados que se comunican entre sí. [sesenta y cinco]
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 fin de "usar la biblioteca".
Richard Stallman y la FSF alientan específicamente a los escritores de bibliotecas a obtener licencias bajo la GPL para que los programas propietarios no puedan usar las bibliotecas, en un esfuerzo por proteger el mundo del software libre dándole más herramientas que el mundo propietario. [66]
Algunas personas creen que si bien los enlaces estáticos producen trabajos derivados, no está claro si un ejecutable que se vincula dinámicamente a un código GPL debe considerarse un trabajo derivado (ver copyleft débil ). El autor de Linux, Linus Torvalds, está de acuerdo en que los enlaces dinámicos pueden crear trabajos derivados, 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 existencia de controladores propietarios del kernel de Linux puede evidenciar que los enlaces dinámicos tienen buenas intenciones. [68]
En Galoob v. Nintendo , el Tribunal de Apelaciones del Noveno Circuito de los Estados Unidos definió una obra derivada como si tuviera " 'forma' o permanencia" y señaló que "la obra infractora debe incorporar de alguna forma una parte de la obra protegida por derechos de autor", [69] pero no ha habido decisiones judiciales claras para resolver este conflicto en particular.
Según un artículo del 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 una pieza de software es un trabajo derivado ; más importante es la pregunta sobre si el software estaba destinado a interactuar con el software y/o las bibliotecas del cliente. [70] Afirma: "La indicación principal de si un nuevo programa es un trabajo derivado es si el código fuente del programa original fue utilizado [en el sentido de copiar y pegar], modificado, traducido o cambiado de alguna manera para crear el nuevo programa. Si no, entonces yo diría que no es un trabajo derivado", [70] y enumera muchos otros puntos relacionados con la intención, la agrupación y el mecanismo de vinculación. Además, sostiene en el sitio web de su empresa [71] que esos factores "basados en el mercado" son más importantes que la técnica de vinculación.
También existe la cuestión específica de si un complemento o módulo (como los módulos del kernel de la tarjeta gráfica NVidia o ATI ) también debe ser GPL si razonablemente se puede considerar que es su propio trabajo. Este punto de vista sugiere que complementos razonablemente separados, o complementos para software diseñado para utilizar complementos, podrían obtenerse 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) 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 en su totalidad sin costo alguno para todos los terceros según los términos de esta Licencia. . ... Estos requisitos se aplican a la obra modificada en su conjunto. 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 distribuye como trabajos separados. Pero cuando distribuye las mismas secciones como parte de un todo que es un trabajo basado en el Programa, la distribución del todo debe realizarse según los términos de esta Licencia, cuyos permisos para otros licenciatarios se extienden al todo completo y, por tanto, a cada uno de ellos. y cada parte independientemente de quién la escribió.
La GPLv3 tiene una cláusula diferente:
Puede transmitir un trabajo basado en el Programa, o las modificaciones para producirlo a partir del Programa, en forma de código fuente según los términos de la Sección 4, siempre que también cumpla con todas estas condiciones: ...
c) Debe licenciar la obra completa, en su totalidad, bajo esta Licencia a cualquiera que entre en posesión de una copia. Por lo tanto, esta Licencia se aplicará, junto con los términos adicionales aplicables de la Sección 7, a la totalidad del trabajo y a 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 lo ha recibido por separado. ... Una recopilación de una obra cubierta con otras obras separadas e independientes, que no son por su naturaleza extensiones de la obra cubierta y que no se combinan con ella para formar un programa más amplio, en o sobre un volumen de un medio de almacenamiento o distribución, se denomina "agregado" si la compilación y los derechos de autor resultantes 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 cubierta en un agregado no hace que esta Licencia se aplique a las otras partes del agregado.
Como estudio de caso, algunos complementos y temas / máscaras supuestamente propietarios para software CMS GPLv2 , como Drupal y WordPress, han sido criticados, con ambos lados del argumento. [72]
La FSF diferencia cómo se invoca el complemento. Si el complemento se invoca a través de un enlace dinámico y realiza llamadas de función al programa GPL, lo más probable es que se trate de un trabajo derivado. [73]
El mero hecho de comunicarse con otros programas no requiere, por sí solo, que todo el software sea GPL; ni distribuir software GPL con software que no sea GPL. Sin embargo, se deben seguir condiciones menores que garanticen que los derechos del software GPL no estén restringidos. La siguiente es una cita de las preguntas frecuentes sobre la GPL de gnu.org , que describe 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 "agregado" consta de varios programas separados, distribuidos juntos en el mismo CD-ROM u otro medio. La GPL le permite crear y distribuir un agregado, incluso cuando las licencias del otro software no son libres o son incompatibles con la GPL. La única condición es que no se puede publicar el agregado 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 entre dos programas separados y un programa con dos partes? Ésta es una cuestión jurídica, 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, definitivamente 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 canalizaciones, los sockets y los argumentos de la línea de comandos son mecanismos de comunicación que normalmente se utilizan entre dos programas separados. Entonces, cuando se utilizan para 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 combinadas en un programa más grande.
Así, la FSF traza la línea entre "biblioteca" y "otro programa" a través de 1) la "complejidad" y la "intimidad" del intercambio de información y 2) el mecanismo (en lugar de la semántica), pero renuncia a 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 admitir 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 infracción de derechos de autor y marcas registradas 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 GPL de MySQL con la tabla NuSphere Gemini sin cumplir con la licencia. Después de una audiencia preliminar ante la jueza Patti Saris el 27 de febrero de 2002, las partes entablaron 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 GNU GPL es una licencia vinculante y ejecutable". [77]
En agosto de 2003, el Grupo SCO declaró que creía que la GPL no tenía validez legal y que pretendía entablar demandas por secciones de código supuestamente copiadas de SCO Unix al kernel de Linux . Esta fue una posición problemática para ellos, ya que habían distribuido Linux y otro código 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 necesaria ] 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 reclamos restantes y proporcionaron un plan para avanzar hacia la sentencia final. [78] Las reclamaciones restantes giraban en torno al Proyecto Monterey y finalmente fueron resueltas 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 Munich después de que Sitecom se negara a desistir de distribuir el software 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 como sentencia definitiva contra Sitecom. [80] La justificación del tribunal fue que:
Esto refleja exactamente las predicciones dadas anteriormente por Eben Moglen de la FSF. Este fallo fue importante porque era la primera vez que un tribunal confirmaba que violar los términos de la GPL podía ser una violación de los derechos de autor y establecía jurisprudencia sobre la aplicabilidad de la GPLv2 según la ley alemana. [81]
En mayo de 2005, Daniel Wallace presentó una demanda contra la Free Software Foundation en el Distrito Sur de Indiana , sosteniendo que la GPL es un intento ilegal de fijar precios (a cero). La demanda fue desestimada en marzo de 2006, basándose en que Wallace no había presentado un reclamo antimonopolio válido; 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 modificar aún más su denuncia 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 importante en un caso que trataba de secretos comerciales derivados de trabajos bajo licencia GPL. [83] Los demandados argumentaron que, dado que es imposible mantener secretos comerciales mientras se cumple con la GPL y se distribuye el trabajo, no infringen los secretos comerciales. Este argumento se consideró infundado.
El 6 de septiembre de 2006, el proyecto gpl-violations.org prevaleció en un litigio judicial contra D-Link Germany GmbH por el uso infractor de derechos de autor por parte de D-Link de partes del kernel de Linux en los dispositivos de almacenamiento que distribuían. [84] La sentencia declaró que la GPL es válida, jurídicamente vinculante y válida ante los tribunales alemanes. [85]
A finales de 2007, los desarrolladores de BusyBox y el Software Freedom Law Center se embarcaron en un programa para lograr el cumplimiento de la GPL por parte de los distribuidores de BusyBox en sistemas integrados , demandando a quienes no cumplieran. Se afirmó que estos eran los primeros usos de los tribunales en Estados Unidos para hacer cumplir las obligaciones de la GPL. (Consulte las demandas de BusyBox GPL ).
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 coreutils , readline , Parted , Wget , GNU Compiler Collection , binutils y GNU Debugger con licencia GPL de la FSF , que Linksys distribuye el firmware Linux [86] de sus enrutadores inalámbricos WRT54G , así como de muchos otros dispositivos, incluidos módems DSL y de cable, dispositivos de almacenamiento conectado a la red, puertas de enlace de voz sobre IP, dispositivos de red privada virtual y sistemas de cine en casa/medios. dispositivo reproductor. [87]
Después de seis años de repetidas quejas a Cisco por parte de la FSF, afirmaciones de Cisco de que corregirían, o estaban corrigiendo, sus problemas de cumplimiento (no proporcionando copias completas de todo el código fuente y sus modificaciones), de repetidas nuevas violaciones descubiertas y reportadas ante más productos y 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 lleva cinco años funcionando [87] ), la FSF los llevó a los tribunales.
Cisco resolvió el caso seis meses después al aceptar "nombrar un director de software libre para Linksys" para garantizar el cumplimiento, "notificar a los destinatarios anteriores de productos Linksys que contienen programas FSF sobre sus derechos bajo la GPL", crear código fuente de programas FSF libremente. disponible en su sitio web, y realizar una contribución monetaria al FSF. [88]
En 2011 se descubrió que GNU Emacs había estado publicando accidentalmente durante dos años algunos archivos binarios sin el código fuente correspondiente, en contra del espíritu pretendido por la GPL , lo que provocó 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 intermedio que, sin saberlo, también violó la GPL al distribuir estos binarios.
En 2017, Artifex, el creador de Ghostscript , demandó a Hancom , el fabricante de una suite ofimática que incluía Ghostscript. Artifex ofrece dos licencias para Ghostscript; una es la licencia Affero GPL y la otra es una licencia comercial. Hancom no adquirió una licencia comercial de Artifex ni lanzó su paquete ofimático como software gratuito. Artifex demandó a Hancom en el Tribunal de Distrito de Estados Unidos e hizo dos reclamaciones. Primero, el uso de Ghostscript por parte de Hancom fue una violación de los derechos de autor; y segundo, el uso de Ghostscript por parte de Hancom constituía una infracción de 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 había realizado sólo ligeras modificaciones al código 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á productos que contengan el código Stockfish, aunque informará de este hecho a sus clientes con un aviso apropiado 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 financiera. [95] [96] [97]
El código con licencia 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 habituales 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 GPLv3, es unilateralmente compatible que los materiales (como texto y otros medios) bajo la licencia internacional Creative Commons Attribution-ShareAlike 4.0 se mezclen con los materiales con licencia GPL (principalmente software), y no al revés, para casos de uso específicos como los juegos. motor (GPL) con scripts de juego (CC BY-SA). [106] [107]
David A. Wheeler ha abogado por que los desarrolladores de software libre/de código abierto utilicen únicamente licencias compatibles con GPL, porque de lo contrario resulta difícil para otros participar y contribuir con código. [108] Como ejemplo específico de incompatibilidad de licencia, ZFS de Sun Microsystems no se puede incluir en el kernel de Linux con licencia GPL, porque tiene la licencia de distribución y desarrollo común incompatible con GPL . Además, ZFS está protegido por patentes, por lo que distribuir una implementación GPL desarrollada de forma independiente aún 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 deseen combinar el paquete con código propietario, utilizando enlaces dinámicos o no. Ejemplos de este tipo de empresas incluyen 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 (los productos 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 realizar cambios en ella") . [110] Sin embargo, para manuales y libros de texto, 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 bajo licencia GFDL no puede incorporarse al software GPL). . [112] [113] Además, la fundación FLOSS Manuals , una organización dedicada a la creación de manuales para software libre, decidió evitar la GFDL en favor de la GPL para sus textos en 2007. [114]
Si la GPL se utiliza para fuentes de computadora , es posible que cualquier documento o imagen creado con dichas fuentes también deba distribuirse según los términos de la GPL. Este no es el caso en países que reconocen los tipos de letra (la apariencia de las fuentes) como un artículo útil y, por lo tanto, no elegibles para derechos de autor , sino los archivos de fuentes como software informático protegido por 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 forzar su publicación bajo la GPL, pero una representación rasterizada de la fuente no estaría sujeta a la GPL). La FSF establece una excepción para los casos en los 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 realizada en 1997 sobre MetaLab , entonces el mayor archivo de software libre, mostró que la GPL representaba aproximadamente la mitad del software licenciado en él. [116] De manera similar, una encuesta de 2000 sobre Red Hat Linux 7.1 encontró que el 53% del código fuente tenía licencia GPL. [9] En 2003 [actualizar], alrededor del 68% de todos los proyectos y el 82,1% de los proyectos con licencia certificada de la industria de código abierto enumerados en SourceForge.net eran de la familia de licencias GPL. [118] En agosto de 2008 [actualizar], la familia GPL representaba el 70,9% de los 44.927 proyectos de software libre enumerados en Freecode . [10]
Después del lanzamiento de la GPLv3 en junio de 2007, se discutió mucho la adopción de esta nueva versión de la GPL [119] y algunos proyectos decidieron no actualizarla. Por ejemplo, el kernel de Linux, [39] [41] MySQL , [120] BusyBox , [121] AdvFS , [122] Blender , [123] [124] VLC media player , [125] y MediaWiki [126] decidieron no adoptar GPLv3. Por otro lado, en 2009, dos años después del lanzamiento de 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 de código abierto con licencia que habían pasado de GPLv2 a GPLv3 era del 50%, contando los proyectos. alojado en Google Code . [11]
En 2011, cuatro años después del lanzamiento de GPLv3, el 6,5% de todos los proyectos de licencias de código abierto son GPLv3, mientras que el 42,5% son GPLv2, según datos de Black Duck Software. [127] [128] Posteriormente, en 2011, el analista de 451 Group, Matthew Aslett, argumentó en una publicación de blog que las licencias copyleft disminuyeron y las licencias permisivas aumentaron, según 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]
Walter van Holst extrajo las estadísticas de uso de GPL de 2009 a 2013 a partir de datos de Freecode mientras analizaba la proliferación de licencias . [12]
En agosto de 2013, según Black Duck Software, los datos del sitio web muestran que la familia de licencias GPL es utilizada por el 54% de los proyectos de código abierto, con un desglose de las licencias individuales que se muestra en la siguiente tabla. [117] Sin embargo, un estudio posterior en 2013 mostró que el software con licencia bajo la familia de licencias GPL ha aumentado, y que incluso los datos de Black Duck Software han mostrado un aumento total de proyectos de software con licencia GPL. El estudio utilizó información pública recopilada de los repositorios del Proyecto Debian y criticó a Black Duck Software por no publicar la 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 las resultado de Black Duck Software. [134]
En 2015, según Black Duck, GPLv2 perdió su primera posición frente a la licencia MIT y ahora ocupa la segunda, 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 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 realizado por whitesourcesoftware.com en abril de 2018 del ecosistema FOSS vio a GPLv3 en tercer lugar (18%) y a 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 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 es violado por los sistemas de gestión de derechos digitales integrados en la plataforma para impedir la copia de software 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 algún tipo de repositorio de software en línea. Prácticamente todos los sistemas Unix y distribuciones de Linux modernos tienen repositorios de aplicaciones, incluidos NetBSD , FreeBSD , Ubuntu , Fedora y Debian . Todos estos repositorios de aplicaciones específicas 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 Ubuntu App Store , las aplicaciones de software comercial patentado y las aplicaciones con licencia GPL están disponibles a través del mismo sistema; La razón por la que Mac App Store (y proyectos similares) es incompatible con aplicaciones con licencia GPL no es inherente al concepto de tienda de aplicaciones, sino que se debe específicamente al requisito de términos de uso de Apple [143] de que todas las aplicaciones en la tienda utiliza restricciones DRM de Apple. La tienda de aplicaciones de Ubuntu no exige tal requisito: "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, en el sentido de propiedad intelectual, se adhiere 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 lanzado Microsoft Windows Services para UNIX , que contiene código con licencia GPL. En julio de 2009, la propia Microsoft publicó un conjunto de alrededor de 20.000 líneas de código de controlador de Linux bajo la GPL. [149] El código Hyper-V que forma parte del código presentado utiliza componentes de código abierto con licencia GPL y originalmente estaba vinculado estáticamente a partes binarias patentadas, siendo estas últimas inadmisibles en software con licencia GPL. [150]
La descripción de la GPL como "viral" , cuando se le llama 'Virus público general' o 'Virus público GNU' (GPV), se remonta a un año después del lanzamiento de la GPLv1. [151]
En 2001, el término recibió una atención pública más amplia cuando Craig Mundie , vicepresidente senior de Microsoft, describió la GPL como "viral". [152] Mundie sostiene que la GPL tiene un efecto "viral" en el sentido de que sólo 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 ni distribuir. .
En 2006, Richard Stallman respondió en una entrevista que la metáfora de Mundie de un "virus" es incorrecta ya que el software bajo la GPL no "ataca" ni "infecta" otro software. En consecuencia, Stallman cree que comparar la GPL con un virus es inapropiado, y que una mejor metáfora para el software bajo la GPL sería una planta araña : si uno toma un trozo y lo coloca en otro lugar, también crece allí. [153]
Por otro lado, el concepto de naturaleza viral de la GPL fue retomado más tarde por otros. [154] [155] Por ejemplo, un artículo de 2008 decía: "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 con licencia GPL anterior también debe tener la licencia GPL". [156]
El proyecto FreeBSD ha afirmado que "un uso menos publicitado y no intencionado de la GPL es que es muy favorable para las grandes empresas que quieren debilitar a las empresas de software. En otras palabras, la GPL es muy adecuada para su uso como arma de marketing, reduciendo potencialmente beneficio económico general y contribuye al comportamiento monopolístico" y que la GPL puede "presentar un problema real para quienes desean comercializar y beneficiarse del software". [157]
Richard Stallman escribió sobre la práctica de vender excepciones de licencia a licencias de software libre como un ejemplo de práctica de comercialización éticamente aceptable. Vender excepciones aquí significa que el titular de los derechos de autor de un determinado software lo libera (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 términos, por ejemplo permitiendo su inclusión en aplicaciones propietarias". Stallman consideró que vender excepciones "es aceptable desde los años 90, y en ocasiones lo he sugerido a las empresas. En ocasiones, 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. Lanzar un programa determinado bajo una licencia de software libre sin copyleft permitiría incrustar el código en software propietario. Stallman comenta que "o tenemos que concluir que está mal publicar algo bajo la licencia X11 (una conclusión que considero inaceptablemente extrema) o rechazar esta implicación. Usar una licencia sin copyleft es débil y, por lo general, una opción inferior, pero no lo es". mal. En otras palabras, la venta de excepciones permite cierta incrustación en software propietario, y la licencia X11 permite aún más incrustación. Si esto no hace que la licencia X11 sea inaceptable, no hace que la venta de 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 WTFPL (Licencia pública Haz lo que quieras) 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 FOSS, afirmando: "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 éxito más rápidamente 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 software". [163]
En 2007, Allison Randal , que participó en el comité borrador de la GPL, criticó la GPLv3 por ser incompatible con la GPLv2 [164] y por faltar claridad en la formulación. [165] De manera similar, Whurley profetizó en 2007 la caída de la GPL debido a la falta de enfoque de 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, entre ellos la incompatibilidad y la complejidad del texto de la licencia. [167]
En 2014, el desarrollador de dtrace y CTO de Joyent , Bryan Cantrill, llamó a la GPL copyleft un " antipatrón corporativo de código abierto " por ser "anticolaborativo" y recomendó en su lugar licencias de software permisivas . [168]
Ya en septiembre de 2006, durante el proceso de redacción de la GPLv3, varios desarrolladores destacados del kernel Linux, como por ejemplo Linus Torvalds, Greg Kroah-Hartman y Andrew Morton , advirtieron sobre una división de la comunidad FOSS: "la liberación de GPLv3 presagia la balcanización de todo el universo de código abierto del que dependemos". [37] De manera similar, Benjamin Mako Hill argumentó en 2006 sobre el borrador de GPLv3, señalando 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 de software libre se hizo más amplia. alguna vez. Como la GPLv3 significativamente extendida es esencialmente incompatible con la GPLv2, [99] la compatibilidad entre ambas sólo se da bajo la cláusula opcional "o posterior" de la GPL, que no fue tomada por ejemplo por el kernel de Linux. [39] Bruce Byfield señaló que antes del lanzamiento de la GPLv3, la GPLv2 era un elemento unificador entre la comunidad de software libre y de código abierto. [127]
Para LGPLv3, el mantenedor de GNU TLS , Nikos Mavrogiannopoulos, argumentó de manera similar: "Si asumimos que su objetivo principal [el LGPLv3] es ser utilizado por software libre, entonces falla descaradamente", [171] después de que volvió a otorgar la licencia de GNU TLS de LGPLv3 vuelve a LGPLv2.1 debido a problemas de compatibilidad de licencias. [172]
Lawrence Rosen , abogado y especialista en informática, elogió en 2007 cómo la comunidad que utilizaba la licencia Apache ahora podía trabajar junto con la comunidad GPL de manera compatible, ya que los problemas de compatibilidad de GPLv2 con el software con licencia Apache se resolvían con GPLv3. Dijo: "Predigo que una de las mayores historias de éxito de GPLv3 será la comprensión de que todo el universo de software gratuito y de código abierto puede combinarse en soluciones integrales de código abierto para clientes de todo el mundo". [173]
En julio de 2013, el desarrollador de Flask , Armin Ronacher, llega a una conclusión menos optimista sobre la compatibilidad de la GPL en el ecosistema FOSS: "Cuando la GPL está involucrada, las complejidades de la licencia 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 GPLv2 todavía tienen impacto en el ecosistema. [174]
... Esta página presenta la opinión de algunos contribuyentes legales de Debian sobre cómo ciertas licencias siguen las Directrices de software libre de Debian (DFSG). ... Las licencias que se encuentran actualmente en Debian main incluyen:
- ...
- Licencias estilo expatriado/MIT
- ...
... Esta es la última versión de GNU GPL: una licencia de software libre y una licencia copyleft. ... GPLv3 no es compatible con GPLv2 por sí solo. Sin embargo, la mayoría del software publicado bajo GPLv2 también le permite utilizar los términos de versiones posteriores de GPL. Cuando este sea el caso, puede utilizar el código bajo GPLv3 para realizar 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 GNU GPL: una licencia de software libre y una licencia copyleft. ... GPLv2, por sí sola, no es compatible con GPLv3. Sin embargo, la mayoría del software publicado bajo GPLv2 también le permite utilizar los términos de versiones posteriores de GPL. Cuando este sea el caso, puede utilizar el código bajo GPLv3 para realizar 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 GPL ganan cada vez que una empresa se involucra.
Mostrando comentarios en el archivo 'gplv3-draft-1'
... encontrado 962
Mostrando comentarios en el archivo 'gplv3-draft-1'
... encontrado 727
Mostrando comentarios en el archivo 'gplv3-draft-3' ... encontrado 649
Mostrando comentarios en el archivo 'gplv3-draft-4' ... encontrado 298
La versión actual (Borrador de discusión 2) de GPLv3 en primera lectura no pasa la prueba de necesidad de la sección 1 debido a que no hay ningún problema sustancial e identificado con 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
... ya que la FSF propone cambiar todos sus proyectos a GPLv3 y aplicar presión Para que todos los demás proyectos con licencia GPL avancen, prevemos que el lanzamiento de GPLv3 presagia la
balcanización
de todo el universo de código abierto del que dependemos.
En segundo lugar, la guerra entre Linus Torvalds y otros desarrolladores del Kernel y la Free Software Foundation por 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 kernel es _esta_ versión particular de la licencia (es decir, v2, no v2.2 o v3.x o lo que sea), 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 impulsa la FSF, que es muy diferente de lo que siempre ha sido el código abierto y Linux, que es más una superioridad técnica que una creencia religiosa. en libertad", dijo Torvalds a Zemlin. Entonces, la Versión 3 de GPL refleja los objetivos de la FSF y la Versión 2 de 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 núcleo.
La única nota que me gustaría señalar directamente es la aclaración en el archivo COPYING, que deja claro que sólo esa versión particular de la GPL es válida para el kernel. Esto no debería sorprendernos, ya que es la misma licencia que existe desde la versión 0.12 aproximadamente, pero pensé en hacerlo explícito.
No. Algunos de los requisitos de GPLv3, como el requisito de proporcionar información de instalación, no existen en GPLv2. Como resultado, las licencias no son compatibles: si intentara combinar el código publicado bajo ambas licencias, violaría la sección 6 de GPLv2. Sin embargo, si el código se publica bajo GPL "versión 2 o posterior", eso es compatible con GPLv3 porque GPLv3 es una de las opciones que permite.
Tanto LibreCAD como FreeCAD quieren usar LibreDWG y tienen parches disponibles para admitir la biblioteca de formatos de archivos DWG, pero no pueden integrarlos. Los programas dependen de la popular licencia GPLv2, mientras que la Free Software Foundation solo permitirá que LibreDWG tenga licencia para uso GPLv3, no GPLv2.
... la desafortunada situación con la compatibilidad con archivos DWG en el software CAD gratuito a través de LibreDWG. Creemos que 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 GFDL e incorporarlo en ningún programa de software gratuito. No se trata de una mera incompatibilidad de licencia. No se trata sólo de que la GFDL sea incompatible con tal o cual licencia de software libre: es que es fundamentalmente incompatible con cualquier licencia de software libre. Entonces, si escribe un programa nuevo y no tiene ningún compromiso sobre qué licencia desea usar, salvo que sea una licencia gratuita, no puede incluir texto GFDL. GNU FDL, tal como está hoy, no cumple con las Directrices de software libre de Debian. Existen problemas importantes con la licencia, como se detalla anteriormente; y, como tal, no podemos aceptar obras bajo licencia GNU FDL en nuestra distribución.
"Licencia -> OSI: ... Licencia Pública General GNU (GPL) (32641 proyectos), Biblioteca GNU o Licencia Pública General Reducida (LGPL) (4889 proyectos" (de 45727, 82,1%)
Actualmente, muchos proyectos de código abierto están debatiendo acaloradamente la decisión de pasar de GPL v2 a GPL v3. Según Palamida, un proveedor de software de cumplimiento de IP, ha habido aproximadamente 2489 proyectos de código abierto que han pasado de 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 GPLv3.
... Los resultados reales, sin embargo, son los siguientes: BusyBox será GPLv2 sólo a partir de la próxima versión. En general, se acepta que eliminar "o cualquier versión posterior" es legalmente defendible, y que la combinación de otro código exclusivo de GPLv2 forzará ese problema en cualquier caso.
No inventes un argumento de hombre de paja, por favor. Considero que licenciar BusyBox bajo GPLv3 es inútil, innecesario, demasiado complicado y confuso, y además tiene desventajas reales. 1) Inútil: nunca abandonaremos la 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 por defecto la licencia GNU GPL Versión 2 o posterior.
En 2001, VLC se lanzó bajo la versión 2 de GNU General Public aprobada por OSI, con la opción comúnmente ofrecida de usar "cualquier versión posterior" del mismo (aunque no existía ninguna versión posterior en ese momento). Tras el lanzamiento por parte de la Free Software Foundation (FSF) de la nueva versión 3 de su Licencia Pública General GNU (GPL) el 29 de junio de 2007, los contribuyentes al 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 no se ajusten a la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Creemos que cambiar nuestros términos de licencia a la versión 3 de GPL actualmente no sería lo mejor para nuestra comunidad en su conjunto. En consecuencia, planeamos seguir distribuyendo versiones futuras del reproductor multimedia VLC bajo los términos de la versión 2 de GPL.
En aquel momento, la decisión parecía sensata ante el estancamiento. Pero ahora, GPLv2 se utiliza para el 42,5% del software libre y GPLv3 para menos del 6,5%, según Black Duck Software.
Del cuadro anterior queda claro que la familia GPL es la más utilizada (antes la había calculado mal como MIT). Las otras licencias importantes son MIT, BSD, la familia LGPL, Artistic (para paquetes Perl), LPPL (para paquetes texlive), ASL.
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 brindar más libertad que la GPL.
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 éxito más rápidamente si la GPL no pusiera nerviosa a mucha gente 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 cambiar software. Quizás piense que la GNU GPL no es necesaria para lograr 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 proyectos para oponerse a la actualización. Viento en popa.
Mirando el borrador casi terminado, debo decir que es poco probable que alguna vez consideraran la simplicidad como una prioridad, si es que la consideraron.
... Las opciones de idioma de una licencia de código abierto pueden respaldar esa libertad y empoderar a los usuarios y desarrolladores. La GPLv3 no lo hace.
La versión 3 distanciará a Richard Stallman y la Free Software Foundation de los desarrolladores que, para empezar, hacen que la organización sea tan influyente.
Antipatrón: licencias anticolaborativas
La GPL es algo que casi todos los miembros de las comunidades de 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 modelos de negocios y diferencias en tácticas.
... Sería prudente recordar que la posibilidad de que la GPL obstaculice nuestra capacidad de trabajar juntos es mucho más peligrosa que incluso el cambio textual más radical que el FSF podría sugerir.
... Sobre todo, debemos recordar que nuestra comunidad y sus objetivos son más importantes que cualquier licencia individual, sin importar cuán extendida sea.
... 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.
LGPLv3 es la última versión de la Licencia pública general reducida GNU. Sigue la exitosa licencia LGPLv2.1 y fue lanzada por la Free Software Foundation como contraparte de su Licencia Pública General GNU versión 3. El objetivo de las Licencias Públicas Generales Reducidas GNU es proporcionar software que pueda ser utilizado tanto por propietarios como por software libre. software. LGPLv2.1 ha logrado este objetivo con éxito hasta ahora y hay una multitud de bibliotecas que utilizan esa licencia. Ahora tenemos LGPLv3 como el último, y la pregunta es ¿qué tan exitoso es LGPLv3 en este objetivo? En mi opinión, muy poco. Si asumimos que su objetivo principal es ser utilizado por software libre, entonces fracasa descaradamente.
El desastre de la compatibilidad de licencias: cuando la GPL está involucrada, las complejidades de las licencias se convierten en una versión nada divertida de un acertijo. Tantas cosas que considerar y tantas interacciones que considerar. Y que las incompatibilidades de la GPL siguen siendo un problema que afecta activamente a las personas 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 cosa del pasado ahora que todo se actualiza a la GPLv3, pero resulta que muchas personas se quedan con la GPLv2 únicamente o no están de acuerdo con la GPLv3 que algunos proyectos con licencia de software Apache deben migrar. Por ejemplo, Bootstrap de Twitter está migrando actualmente de ASL2.0 al MIT precisamente porque algunas personas todavía necesitan compatibilidad con GPLv2. Entre los proyectos que se vieron afectados se encuentran Drupal, WordPress, Joomla, MoinMoin Wiki y otros. E incluso ese caso muestra que a la gente ya no le importan mucho las licencias, ya que Joomla 3 simplemente incluía bootstrap a pesar de que no eran licencias de manera compatible (GPLv2 vs ASL 2.0). El otro caso tradicional de cosas que no son compatibles con GPL es el proyecto OpenSSL que tiene una licencia que no va bien con la GPL. Esa licencia también sigue siendo incompatible con la GPLv3. Todo este asunto es particularmente interesante ya que algunas partes no tan agradables han comenzado a hacer trolling de licencias a través de licencias GPL.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}