La compatibilidad de licencias es un marco legal que permite distribuir juntos piezas de software con diferentes licencias de software . La necesidad de un marco de este tipo surge porque las diferentes licencias pueden contener requisitos contradictorios, lo que hace imposible combinar legalmente el código fuente de software con licencia independiente para crear y publicar un nuevo programa. [1] [2] [ verificación fallida ] Las licencias propietarias generalmente son específicas del programa e incompatibles; los autores deben negociar para combinar el código. Las licencias copyleft suelen ser deliberadamente incompatibles con las licencias propietarias, con el fin de evitar que el software copyleft se vuelva a licenciar bajo una licencia propietaria, convirtiéndolo en software propietario . Muchas licencias copyleft permiten explícitamente la relicencia bajo otras licencias copyleft. Las licencias permisivas son (con pequeñas excepciones) compatibles con todo, incluidas las licencias propietarias; por lo tanto, no hay garantía de que todos los trabajos derivados permanezcan bajo una licencia permisiva. [3]
La compatibilidad de licencias se puede definir en torno a los conceptos de "obra colectiva/combinada/agregada" y " obra derivada ". La primera definición de compatibilidad de licencias de " obra colectiva " permite el uso de obras con distintas licencias en un contexto combinado:
la característica de dos (o más) licencias según la cual los códigos distribuidos bajo estas licencias pueden agruparse para crear un software distribuible más grande . [énfasis añadido]
— Philippe Laurent, La GPLv3 y los problemas de compatibilidad, EOLE 2008 [4] : 3 [ se necesita una fuente mejor ]
Una definición más estricta incluye la capacidad de cambiar la licencia. El ejemplo más destacado es la exigencia de la licencia copyleft de que el "trabajo derivado" combinado a partir de código bajo varias licencias se aplique en su totalidad a la licencia copyleft.
Compatibilidad de licencias: Característica de una licencia según la cual el código distribuido bajo esta licencia puede integrarse en un software más grande que se distribuirá bajo otra licencia . [énfasis añadido]
— Philippe Laurent, La GPLv3 y los problemas de compatibilidad, EOLE 2008 [4] : 4 [ se necesita una mejor fuente ]
Una obra combinada consta de varias partes con licencias diferentes (evitando la renovación de la licencia ). Para lograr una obra combinada que incluya componentes con licencia copyleft (que tienen una propiedad viral que potencialmente conduce a una obra derivada ), es necesario mantener un aislamiento/separación adecuados.
En el caso de los archivos de código fuente con licencia individual , se pueden separar varias licencias no recíprocas (como licencias permisivas o código propietario propio), mientras que el programa compilado combinado podría volver a licenciarse (pero esto no es obligatorio). Esta separación de archivos de código fuente es demasiado débil para las licencias copyleft/recíprocas (como la GPL), ya que exigen que el trabajo completo vuelva a licenciarse bajo la licencia recíproca como si fuera derivado.
Un enfoque ligeramente más fuerte es tener una separación en la etapa de enlace con código objeto binario ( enlace estático ), donde todos los componentes del programa resultante son parte del mismo proceso y espacio de direcciones . Esto satisface las obras combinadas de "copyleft débil/recíproco estándar" (como las licenciadas con LGPL), pero no las obras combinadas de "copyleft fuerte/recíproco fuerte". Si bien se acepta comúnmente que el enlace ( enlace estático e incluso dinámico ) constituye un derivado de una obra con copyleft fuerte, [6] [7] [8] [9] existen interpretaciones alternativas. [10] [11]
Para trabajos combinados con módulos "copyleft fuertes", se requiere un aislamiento más fuerte. Esto se puede lograr separando los programas mediante un proceso propio y permitiendo la comunicación solo a través de ABIs binarias u otros medios indirectos. [7] Algunos ejemplos son la separación del espacio del kernel del usuario con el espacio del kernel de Android a través de Bionic , o las distribuciones de Linux que tienen blobs binarios propietarios incluidos a pesar de tener un kernel copyleft fuerte . [5] [12]
Si bien para algunos dominios existe un acuerdo sobre si un aislamiento es adecuado, hay dominios en disputa que hasta ahora no han sido probados en los tribunales. Por ejemplo, en 2015 la SFC demandó a VMware en una disputa en curso sobre si los módulos de kernel cargables (LKM) son trabajos derivados del kernel Linux con licencia GPL o no. [13] [14]
Las licencias comunes para el software libre y de código abierto (FOSS) no son necesariamente compatibles entre sí, [16] y esto puede hacer que sea legalmente imposible mezclar (o vincular ) código de código abierto si los componentes tienen licencias diferentes. Por ejemplo, el software que combina código publicado bajo la versión 1.1 de la Licencia Pública de Mozilla (MPL) con código bajo la Licencia Pública General de GNU (GPL) no podría distribuirse sin violar uno de los términos de las licencias; [17] [ se necesita una mejor fuente ] esto a pesar de que ambas licencias están aprobadas tanto por la Iniciativa de Código Abierto [18] como por la Free Software Foundation . [19]
La compatibilidad de licencias entre una licencia copyleft y otra licencia es a menudo sólo una compatibilidad unidireccional, lo que hace que la licencia copyleft (GPL y la mayoría de las otras licencias copyleft) sea incompatible con licencias comerciales propietarias, así como con muchas licencias no propietarias. [20] [ ¿fuente autopublicada? ] [21] [ ¿ fuente autopublicada? ] Esta característica de "compatibilidad unidireccional" ha sido criticada por la Apache Foundation , que licencia bajo la licencia Apache más permisiva , [22] siendo dichas licencias no copyleft a menudo menos complicadas y permitiendo una mejor compatibilidad de licencias. [23] [24]
Un ejemplo de una licencia que tiene una excelente compatibilidad con otras licencias FOSS es la Licencia Artística 2.0, debido a su cláusula de re-licenciamiento que permite la redistribución del código fuente bajo cualquier otra licencia FOSS. [25]
Puede distribuir su versión modificada como fuente (gratis o por una tarifa de distribución, y con o sin una forma compilada de la versión modificada) [...] siempre que realice al menos UNA de las siguientes acciones: […]
(c) permitir que cualquier persona que reciba una copia de la Versión Modificada ponga a disposición de otros la forma Fuente de la Versión Modificada
(i) la Licencia Original o
(ii) una licencia que permite al licenciatario copiar, modificar y redistribuir libremente la Versión Modificada utilizando los mismos términos de licencia que se aplican a la copia que recibió el licenciatario, y requiere que la forma Fuente de la Versión Modificada, y de cualquier trabajo derivado de ella, se ponga a disposición libremente, estando prohibidos los honorarios de licencia pero permitidos los Honorarios de Distribuidor. [énfasis añadido]
La Licencia de Desarrollo y Distribución Común (CDDL), una licencia copyleft débil entre la licencia GPL y las licencias permisivas BSD / MIT , intenta abordar los problemas de compatibilidad de licencias al permitir, sin volver a licenciar, la mezcla de archivos de código fuente con licencia CDDL con archivos de código fuente bajo otras licencias, al disponer que el binario resultante pueda licenciarse y venderse bajo una licencia diferente siempre que el código fuente aún esté disponible bajo CDDL. [26] [27] [28] [ ¿ código fuente generado por el usuario? ]
Para minimizar la proliferación de licencias y las incompatibilidades de licencias en el ecosistema FOSS , algunas organizaciones (la Free Software Foundation, por ejemplo) e individuos (David A. Wheeler), argumentan que la compatibilidad con la ampliamente utilizada GPL es una característica importante de las licencias de software. [29] [ ¿ fuente autopublicada? ] Muchas de las licencias de software libre más comunes, especialmente las licencias permisivas , como la licencia MIT/X original , las licencias BSD (en las formas de tres y dos cláusulas, aunque no la forma original de cuatro cláusulas), MPL 2.0 y LGPL , son compatibles con la GPL . Es decir, su código se puede combinar con un programa bajo la GPL sin conflicto, y la nueva combinación tendría la GPL aplicada al conjunto (pero la otra licencia no se aplicaría así).
Las licencias de software copyleft no son inherentemente compatibles con la GPL; incluso la licencia GPLv2 por sí misma no es compatible con la GPLv3 o la LGPLv3. [8] [30] [31] Si un desarrollador intentara combinar código publicado bajo cualquiera de las licencias GPL posteriores con código GPLv2, eso violaría la sección 6 de la GPLv2, la fuente de la incompatibilidad. Sin embargo, el código bajo las licencias posteriores se puede combinar con código licenciado bajo la versión 2 o posterior de la GPL. [32] [ ¿ Fuente autopublicada? ] La mayoría del software publicado bajo la GPLv2 también le permite usar los términos de versiones posteriores de la GPL, y algunos tienen cláusulas de excepción que permiten combinarlos con software que está bajo diferentes licencias o versiones de licencia. [33] El núcleo Linux es una excepción notable que se distribuye exclusivamente bajo los términos de la GPLv2. [34] [35]
La Licencia de Documentación Libre GNU recomendada por la Free Software Foundation [8] es incompatible con la licencia GPL, y el texto licenciado bajo la GFDL no puede incorporarse al software GPL. [ cita requerida ] Por lo tanto, el proyecto Debian decidió, en una resolución de 2006, licenciar la documentación bajo la GPL. [36] La fundación FLOSS Manuals siguió a Debian en 2007. [37] En 2009, la Fundación Wikimedia cambió de la GFDL a una licencia Creative Commons CC-BY-SA como licencia principal para sus proyectos. [38] [39]
Las licencias de IA responsable (o RAIL) generalmente no son compatibles con la GPL. [40] Esto se debe a que las RAIL incluyen "restricciones de uso" que limitan las formas en que los usuarios pueden hacer uso de los materiales licenciados bajo RAIL, mientras que la GPL prohíbe dichas restricciones.
Otro caso en el que la compatibilidad con GPL es problemática es el sistema de archivos ZFS con licencia CDDL con el núcleo Linux con licencia GPLv2 . [41] A pesar de que ambos son software libre bajo una licencia copyleft, ZFS no se distribuye con la mayoría de las distribuciones de Linux como Debian [42] [43] (pero se distribuye con FreeBSD ) ya que la Free Software Foundation y algunas partes con relaciones con la FSF consideran que el CDDL es incompatible con el núcleo Linux con licencia GPL. [19] [44] La interpretación legal (de si esta combinación constituye un trabajo combinado o un trabajo derivado del núcleo con licencia GPL) es ambigua y controvertida. [45] En 2015, la cuestión de la compatibilidad entre CDDL y GPL resurgió cuando la distribución de Linux Ubuntu anunció que incluiría OpenZFS de forma predeterminada. [46] En 2016, Ubuntu anunció que una revisión legal dio como resultado la conclusión de que es legalmente seguro usar ZFS como un módulo binario del núcleo en Linux. [47] Otros aceptaron la conclusión de Ubuntu; por ejemplo, el abogado James EJ Bottomley argumentó que no se puede desarrollar "una teoría convincente del daño", lo que hace imposible llevar el caso a los tribunales. [48] [ fuente autopublicada ] Eben Moglen , coautor de la GPLv3 y fundador de la SFLC , argumentó que si bien las letras de la GPL pueden ser violadas, se respeta el espíritu de ambas licencias, lo que sería el tema relevante en los tribunales. [49] Por otro lado, Bradley M. Kuhn y Karen M. Sandler , de Software Freedom Conservancy , argumentaron que Ubuntu violaría ambas licencias, ya que un módulo binario de ZFS sería un trabajo derivado del núcleo Linux, y anunciaron su intención de lograr claridad en esta cuestión, incluso yendo a los tribunales. [50]
El 8 de octubre de 2015, Creative Commons concluyó que la CC BY-SA 4.0 es compatible con la GPLv3. [51]
Las licencias Creative Commons se utilizan ampliamente para el contenido, pero no todas las combinaciones de las siete licencias recomendadas y admitidas son compatibles entre sí. Además, a menudo se trata de una compatibilidad unidireccional, que requiere que una obra completa esté licenciada bajo la licencia más restrictiva de las obras originales. [ cita requerida ]
El desarrollador de JSON Douglas Crockford , inspirado por las palabras del entonces presidente Bush, formuló la licencia JSON para "malhechores" ("El software se utilizará para el bien, no para el mal"). Esta cláusula de licencia subjetiva y moral condujo a problemas de incompatibilidad de licencia con otras licencias de código abierto , [54] y resultó en que la licencia JSON no fuera una licencia libre y de código abierto. [55] [56] [57]
A veces los proyectos terminan con licencias incompatibles, y la única forma factible de resolverlo es la renovación de la licencia de las partes incompatibles. La renovación de la licencia se logra contactando a todos los desarrolladores involucrados y otras partes y obteniendo su acuerdo para la licencia modificada. Si bien en el dominio del código abierto y libre lograr un acuerdo del 100% es a menudo imposible, debido a los muchos contribuyentes involucrados, el proyecto de renovación de licencias de Mozilla asume que lograr el 95% es suficiente para la renovación de la licencia de la base de código completa. [58] [ ¿ fuente poco confiable? ] Otros en el dominio del FOSS, como Eric S. Raymond , llegaron a conclusiones diferentes con respecto a los requisitos para renovar la licencia de una base de código completa. [59]
Un ejemplo temprano de un proyecto que logró renovar con éxito la licencia por razones de incompatibilidad de licencias es el proyecto Mozilla y su navegador Firefox . El código fuente del navegador Communicator 4.0 de Netscape se publicó originalmente en 1998 bajo la Licencia Pública Netscape / Licencia Pública Mozilla [60] pero fue criticado por la Free Software Foundation (FSF) y OSI por ser incompatible con la Licencia Pública General GNU (GPL). [61] [62] Alrededor de 2001 Time Warner , ejerciendo sus derechos bajo la Licencia Pública Netscape, y a petición de la Fundación Mozilla, renovó la licencia [63] de todo el código en Mozilla que estaba bajo la Licencia Pública Netscape (incluyendo el código de otros colaboradores) a una tri-licencia MPL 1.1/GPL 2.0/ LGPL 2.1 , logrando así la compatibilidad con la GPL. [64] [ ¿ Fuente autopublicada? ]
La biblioteca Vorbis fue originalmente licenciada como LGPL , pero en 2001, con el respaldo de Richard Stallman , la licencia se cambió a la licencia BSD , menos restrictiva , para acelerar la adopción de la biblioteca. [65] [66]
El proyecto VLC tiene un historial de licencias complicado debido a la incompatibilidad de licencias, y en 2007 el proyecto decidió, por compatibilidad de licencias, no actualizar a la recién lanzada GPLv3 . [67] En octubre de 2011, después de que VLC hubiera sido eliminado de la App Store de Apple a principios de 2011, el proyecto VLC volvió a licenciar la biblioteca VLC, de la GPLv2 a la LGPLv2, para lograr una mejor compatibilidad. [68] [69] En julio de 2013, el software volvió a licenciarse bajo la Licencia Pública de Mozilla , la aplicación VLC luego se volvería a enviar a la App Store de iOS . [70]
La versión 1.2 de la Licencia de Documentación Libre GNU de la Free Software Foundation no es compatible con la ampliamente utilizada licencia Creative Commons Attribution-ShareAlike , lo que fue un problema para Wikipedia , por ejemplo. [71] [ ¿ fuente autopublicada? ] Por lo tanto, a petición de la Fundación Wikimedia , la FSF agregó una sección limitada en el tiempo, a la versión 1.3 de la GFDL, que permitía a tipos específicos de sitios web que usaban la GFDL ofrecer adicionalmente su trabajo bajo la licencia CC BY-SA. [72] Después de esto, en junio de 2009, la Fundación Wikimedia migró sus proyectos ( Wikipedia , etc.) mediante una licencia dual a la licencia Creative Commons Attribution-ShareAlike como su licencia principal, además de la GFDL utilizada anteriormente , [38] para tener una compatibilidad de licencia mejorada con el ecosistema de contenido libre más amplio . [39] [73]
Otro caso interesante fue la renovación de la licencia por parte de Google de los archivos de encabezado del núcleo Linux con licencia GPLv2 a la licencia BSD para su biblioteca Android Bionic . Google afirmó que los archivos de encabezado estaban limpios de cualquier trabajo sujeto a derechos de autor, reduciéndolos a "hechos" no sujetos a derechos de autor, y por lo tanto no cubiertos por la GPL. [74] [75] Esta interpretación fue cuestionada por Raymond Nimmer, un profesor de derecho en el Centro de Derecho de la Universidad de Houston . [76] Las aplicaciones y controladores de Android, que proporcionan una cantidad cada vez mayor de la funcionalidad de Android, han sido gradualmente relicenciados de licencias permisivas a licencias propietarias. [77]
En 2014, el proyecto FreeCAD cambió su licencia de GPL a LGPLv2, debido a incompatibilidades entre GPLv3 y GPLv2. [78] [79] También en 2014, Gang Garrison 2 fue re-licenciado de GPLv3 a MPL para mejorar la compatibilidad de la biblioteca. [80] [81]
El sistema operativo móvil KaiOS se derivó del sistema operativo Firefox OS/Boot to Gecko , que se lanzó bajo la licencia permisiva MPL 2.0 . No se redistribuye bajo la misma licencia, por lo que ahora presumiblemente tiene una nueva licencia y es propietario (pero sigue siendo mayoritariamente de código abierto). [82] [83] KaiOS también utiliza el núcleo Linux GPL que también se utiliza en Android. [84]
¿Qué constituye la combinación de dos partes en un solo programa? 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 […] como de la semántica de la comunicación […]. Si los módulos están incluidos en el mismo archivo ejecutable, definitivamente están combinados en un solo programa. Si los módulos están diseñados para ejecutarse enlazados entre sí en un espacio de direcciones compartido, eso casi seguramente significa combinarlos en un solo programa. […]
'Utilizar una biblioteca' significa […] vincular […].
Recuerde que la GPL exige que cualquier cosa que enlace estáticamente a cualquier código bajo la GPL también se coloque bajo la GPL.
La propiedad viral estimula la proliferación de licencias y contribuye a la "pesadilla impuesta por la GPL" - una situación en la que muchas otras licencias son lógicamente incompatibles con la GPL y hacen la vida innecesariamente difícil para los desarrolladores que trabajan en el entorno Linux (KDE es un buen ejemplo en este caso, Python es un ejemplo menos conocido).
La GPL y la compatibilidad de licencias: dado que el objetivo principal de los autores de la GPL es la promoción del software libre, crearon deliberadamente la licencia para que fuera imposible mezclar código GPL en programas propietarios. […] Cualquier trabajo derivado, es decir, cualquier trabajo que contenga una cantidad no trivial de código GPL, debe distribuirse bajo la GPL. No se pueden imponer restricciones adicionales a la redistribución del trabajo original o de un trabajo derivado.
Por lo tanto, el software Apache 2 puede incluirse en proyectos GPLv3, porque la licencia GPLv3 acepta nuestro software en trabajos GPLv3. Sin embargo, el software GPLv3 no puede incluirse en proyectos Apache. Las licencias son incompatibles en una sola dirección, y es el resultado de la filosofía de licencias de ASF y la interpretación de la ley de derechos de autor por parte de los autores de GPLv3.
Las licencias permisivas simplifican las cosas Una de las razones por las que el mundo empresarial, y cada vez más desarrolladores [...], favorecen las licencias permisivas es la simplicidad de la reutilización. La licencia normalmente solo se refiere al código fuente que está licenciado y no intenta inferir ninguna condición sobre ningún otro componente, y debido a esto no hay necesidad de definir qué constituye un trabajo derivado. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que todas son compatibles.
Las licencias para distribuir software libre o de código abierto (FOSS) se dividen en dos familias: permisivas y copyleft. Las licencias permisivas (BSD, MIT, X11, Apache, Zope) son generalmente compatibles e interoperables con la mayoría de las demás licencias, tolerando la fusión, combinación o mejora del código cubierto y su redistribución bajo muchas licencias (incluidas las no libres o propietarias).
La GPL impone restricciones adicionales al código y, por lo tanto, es incompatible. Se puede combinar código con licencia APSL, MPL, CDDL, Apache y BSD en el mismo proyecto fácilmente, pero solo se puede combinar uno de ellos con código GPLv2. Ni siquiera la Free Software Foundation puede hacerlo bien. La versión 3 de la LGPL, por ejemplo, es incompatible con la versión 2 de la GPL. Esto ha causado un problema recientemente para algunos proyectos de bibliotecas GNU que querían migrar a la LGPLv3 pero que eran utilizados por otros proyectos que solo eran GPLv2.
La GPLv3 dividió "la" GPL en bifurcaciones incompatibles que no pueden compartir código.
También tenga en cuenta que la única versión válida de la GPL en lo que respecta al núcleo es _esta_ versión particular de la licencia (es decir, v2, no v2.2 o v3.x o cualquier otra), a menos que se indique explícitamente lo contrario.
El único punto importante que me gustaría señalar directamente es la aclaración en el archivo COPYING, que deja claro que solo _esa_ versión particular de la GPL es válida para el núcleo. Esto no debería sorprender a nadie, ya que es la misma licencia que ha estado allí desde la versión 0.12 aproximadamente, pero pensé que sería mejor dejarlo explícito.
El proyecto ZoL [3] sostiene la opinión de que en este caso la combinación de los dos en el mismo binario crearía un trabajo derivado, por lo que esto no es aceptable para la redistribución. Aceptamos la interpretación de que este último caso no es aceptable para la redistribución. Por lo tanto, nuestro paquete no envía (y nunca enviará) ni facilitará la creación de un núcleo personalizado donde el controlador ZFS de ZoL esté integrado en un binario monolítico, en lugar de construirse como un LKM dinámico independiente.
Nuestro consenso fue que este paquete parece violar el espíritu de la GPL como mínimo y puede causar problemas legales. Los jueces a menudo interpretan los documentos como se supone que deben leerse, los trucos para cumplir con la letra pero no con la intención no son vistos con buenos ojos. Esto puede ser algo difícil de aceptar para los técnicos, pero en los casos legales, uno normalmente no está tratando con técnicos. Por lo tanto, este paquete ha sido rechazado.
In der Praxis no está escrito en absoluto, ob en el módulo Kernel como "trabajo derivado" se retractó el director muss. Die Auseinandersetzungen um Binär-Treiber für Linux warden it Heftiest geführt. Man word world night für sämtliche Kernel module in einheitliche Antwort find können: Wann in Kernel module von Linux »abgeleitet« ist, hängt stark von der Technische Umsetzung ab und Richter enfermo cada guarida en la pierna oscura diez Criterios. […] Existen incluso aludiendo mucho a Kernelmodule, die älter y como Linux, dos das Dateisystem AFS. Dort light es Auf der Hand, dass sie as funcional eigenständig Anzu luego envía, da sie gear night »für Linux« GE Chr Eben sein können.
{{cite book}}: |work=ignorado ( ayuda )Lo que muestra el análisis anterior es que, aunque supusimos que la combinación de las obras de la GPLv2 y la CDDL es una violación técnica, no hay forma de enjuiciar dicha violación porque no podemos desarrollar una teoría convincente del daño resultante. Como esto hace imposible llevar el caso a los tribunales, efectivamente se debe concluir que la combinación de la GPLv2 y la CDDL, siempre que se siga un régimen de cumplimiento de la GPLv2 para todo el código, es permisible.
En última instancia, varios tribunales del mundo tendrán que decidir sobre la cuestión más general de las combinaciones de Linux. La organización se compromete a trabajar para lograr claridad sobre estas cuestiones a largo plazo. Ese trabajo comenzó en serio el año pasado con la demanda de VMware, y nuestro trabajo en esta área continuará indefinidamente, según lo permitan los recursos. Debemos hacerlo, porque, con demasiada frecuencia, las empresas son complacientes con el cumplimiento. Si bien nosotros y otras organizaciones impulsadas por la comunidad hemos evitado históricamente las demandas a cualquier costo en el pasado, la ausencia de litigios sobre estas cuestiones provocó que muchas empresas trataran la GPL como un copyleft más débil de lo que realmente es. […] Conservancy (como titular de derechos de autor de Linux),
[
cita requerida
]
junto con los miembros de nuestra coalición en el Proyecto de Cumplimiento de la GPL para Desarrolladores de Linux, todos están de acuerdo en que Canonical y otros infringen los derechos de autor de Linux cuando distribuyen zfs.ko.
GPLv3: La Licencia Pública General GNU versión 3 fue declarada una 'Licencia Compatible con BY-SA' para la versión 4.0 el 8 de octubre de 2015. Tenga en cuenta que la compatibilidad con la GPLv3 es unidireccional, lo que significa que puede licenciar sus contribuciones a adaptaciones de materiales BY-SA 4.0 bajo la GPLv3, pero no puede licenciar sus contribuciones a adaptaciones de proyectos GPLv3 bajo la BY-SA 4.0.
Alguien que trabaja con muchos abogados en cuestiones de derechos de autor de software libre me dijo más tarde que no es necesario obtener el permiso del 100% de los titulares de los derechos de autor. Bastaría con que hubiera permiso de los titulares de los derechos de autor del 95% del código fuente y ninguna objeción de los titulares del otro 5%. Me han dicho que así fue como Mozilla pudo renovar la licencia GPL en 2003 a pesar de años de contribuciones de la comunidad.
Cambiar una licencia existente […] Puede cambiar la licencia de un fragmento de código bajo cualquiera de las siguientes condiciones: Si es el único titular de los derechos de autor […] Si es el único titular de los derechos de autor registrado […] Si obtiene el consentimiento de todos los demás titulares de los derechos de autor […] Si ningún otro titular de los derechos de autor podría verse perjudicado por el cambio.
Hace algún tiempo, mozilla.org anunció su intención de solicitar la renovación de la licencia del código de Mozilla bajo un nuevo esquema de licencias que abordaría las incompatibilidades percibidas de la Licencia Pública de Mozilla (MPL) con la Licencia Pública General de GNU (GPL) y la Licencia Pública General Reducida de GNU (LGPL).
Con el lanzamiento de la Beta 4, las bibliotecas Ogg Vorbis se han trasladado a la licencia BSD. El cambio de LGPL a BSD se realizó para permitir el uso de Ogg Vorbis en todas las formas de software y hardware. Jack Moffitt dice: "Estamos cambiando la licencia en respuesta a los comentarios de muchas partes. Nos ha quedado claro que la adopción de Ogg Vorbis se acelerará aún más con el uso de una licencia menos restrictiva que sea más amigable con los sistemas de software y hardware propietarios. Queremos que todos puedan usar Ogg Vorbis".
En 2001, VLC fue lanzado 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" de la misma (aunque no había ninguna versión posterior de ese tipo en ese momento). Después del 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 podrían no coincidir con la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Creemos que cambiar los términos de nuestra licencia a la versión 3 de la GPL no sería lo mejor para nuestra comunidad en su conjunto. Por lo tanto, planeamos seguir distribuyendo futuras versiones del reproductor multimedia VLC bajo los términos de la versión 2 de la GPL. […] continuaremos distribuyendo el código fuente del reproductor multimedia VLC bajo la GPL 'versión 2 o cualquier versión posterior' hasta nuevo aviso.
Tal vez la razón más importante para elegir CC-BY-SA como nuestra licencia de contenido principal fue la compatibilidad con muchos de los otros esfuerzos admirables que existen para compartir y desarrollar el conocimiento libre.
Microsoft lanza una nueva demanda contra Android, la opinión de Linus Torvalds sobre los encabezados del kernel de Linux y Android
[…] la desafortunada situación con el soporte para archivos DWG en software CAD libre a través de LibreDWG. Creemos que, a esta altura, debería estar cerrado. Tenemos la respuesta final de la FSF. […] 'No vamos a cambiar la licencia'.
Licencias utilizadas en FreeCAD - FreeCAD utiliza dos licencias diferentes, una para la aplicación en sí y otra para la documentación: Licencia Pública General Menor, versión 2 o superior (LGPL2+) […] Licencia de Publicación Abierta
tl;dr: La licencia actual nos impide usar ciertas bibliotecas y marcos de trabajo agradables y (gratuitos), por lo que queremos cambiarla. La nueva licencia (MPL) sería estrictamente más libre que la anterior, y es la misma que también usa Firefox.