Articulo de referencia

Compatibilidad de licencias

La compatibilidad de licencias es un marco legal que permite distribuir conjuntamente software con diferentes licencias . La necesidad de dicho marco surge porque las distintas ...

La compatibilidad de licencias es un marco legal que permite distribuir conjuntamente software con diferentes licencias . La necesidad de dicho marco surge porque las distintas licencias pueden contener requisitos contradictorios, lo que imposibilita la combinación legal del código fuente de software con licencias separadas para crear y publicar un nuevo programa. [ 1 ] [ 2 ] Las licencias propietarias suelen ser 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, para evitar que el software copyleft se vuelva a licenciar bajo una licencia propietaria, convirtiéndolo así en software propietario . Muchas licencias copyleft permiten explícitamente la relicencia bajo otras licencias copyleft. Las licencias permisivas son (con algunas excepciones menores) compatibles con todo, incluidas las licencias propietarias; por lo tanto, no hay garantía de que todas las obras derivadas permanezcan bajo una licencia permisiva. [ 3 ]

Definiciones

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, " obra colectiva ", permite el uso de obras con diversas 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 combinarse para crear un software distribuible de mayor tamaño . [énfasis añadido]

Philippe Laurent, La GPLv3 y los problemas de compatibilidad, EOLE 2008 [ 4 ] : 3

Una definición más estricta incluye la capacidad de modificar la licencia. El ejemplo más destacado es la exigencia de la licencia copyleft de que la "obra derivada", compuesta a partir de código bajo diversas 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

Tipos de trabajos combinados

Compatibilidad de licencias para obras derivadas y obras combinadas de código propio del desarrollador y código con licencia de código abierto desarrollado externamente (adaptado de Välimäki 2005 [ 5 ] : 119 )

Una obra combinada consta de varias partes con diferentes licencias (evitando la relicenciación ). Para lograr una obra combinada que incluya componentes con licencia copyleft (que poseen una propiedad viral que puede dar lugar a una obra derivada ), es necesario mantener un aislamiento/separación adecuados.

Con 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 (aunque 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 estas requieren que la obra completa se vuelva a licenciar bajo la licencia recíproca por ser derivada.

Un enfoque ligeramente más estricto consiste en separar el código objeto binario en la etapa de enlace ( enlace estático ), donde todos los componentes del programa resultante forman parte del mismo proceso y espacio de direcciones . Esto satisface las obras combinadas de "copyleft débil"/reciprocidad estándar (como las licenciadas por LGPL), pero no las obras combinadas de "copyleft fuerte"/reciprocidad fuerte. Si bien se acepta comúnmente que el 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 de "copyleft fuerte", se requiere un aislamiento más estricto. Esto se puede lograr separando los programas mediante un proceso propio y permitiendo la comunicación solo a través de ABI binarios u otros medios indirectos. [ 7 ] Ejemplos de ello son la separación del espacio del kernel al espacio de usuario de Android mediante Bionic , o las distribuciones de Linux que incluyen blobs binarios propietarios a pesar de tener un kernel de copyleft fuerte . [ 5 ] [ 12 ]

Si bien para algunos dominios existe un acuerdo sobre si el aislamiento es adecuado, hay dominios en disputa y que hasta ahora no han sido sometidos a juicio. Por ejemplo, en 2015 la SFC demandó a VMware en una disputa en curso sobre si los módulos de kernel cargables (LKM) son obras derivadas del kernel de Linux bajo licencia GPL o no. [ 13 ] [ 14 ]

Compatibilidad de las licencias FOSS

Compatibilidad de licencias entre licencias de software FOSS comunes según David A. Wheeler (2007): las flechas indican una compatibilidad unidireccional, por lo tanto, mejor compatibilidad en el lado izquierdo que en el lado derecho. [ 15 ]

Las licencias comunes al 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 enlazar ) 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 ] esto a pesar de que ambas licencias están aprobadas tanto por la Open Source Initiative [ 18 ] como por la Free Software Foundation . [ 19 ]

La compatibilidad de licencias entre una licencia copyleft y otra suele ser unidireccional, lo que hace que la licencia copyleft (GPL y la mayoría de las demás licencias copyleft) sea incompatible con las licencias comerciales propietarias, así como con muchas licencias no propietarias. [ 20 ] [ 21 ] Esta característica de "compatibilidad unidireccional" ha sido criticada por la Fundación Apache , que licencia bajo la licencia Apache , más permisiva , [ 22 ] ya que dichas licencias no copyleft suelen ser menos complejas y ofrecen 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 relicenciamiento que permite la redistribución del código fuente bajo cualquier otra licencia FOSS. [ 25 ]

Usted puede distribuir su versión modificada como código fuente (ya sea de forma gratuita o a cambio de una tarifa de distribución, y con o sin una versión compilada de la versión modificada) [...] siempre que cumpla al menos UNA de las siguientes condiciones: [...]

(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ó, y que exige que la forma fuente de la Versión Modificada, y de cualquier obra derivada de ella, esté disponible gratuitamente, prohibiéndose el cobro de tarifas de licencia pero permitiendo las tarifas de distribución. [énfasis añadido]

La Licencia Común de Desarrollo y Distribución (CDDL), una licencia copyleft débil situada entre la licencia GPL y las licencias permisivas BSD / MIT , intenta abordar los problemas de compatibilidad de licencias permitiendo, sin necesidad de volver a licenciar, la mezcla de archivos de código fuente con licencia CDDL con archivos de código fuente bajo otras licencias, al establecer que el binario resultante puede licenciarse y venderse bajo una licencia diferente siempre que el código fuente siga estando disponible bajo CDDL. [ 26 ] [ 27 ] [ 28 ]

Compatibilidad con GPL

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 GPL, ampliamente utilizada, es una característica importante de las licencias de software. [ 29 ] 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 GPL . Es decir, su código puede combinarse con un programa bajo la GPL sin conflicto, y la nueva combinación tendría la GPL aplicada a todo (pero la otra licencia no se aplicaría de esa manera).

Licencias Copyleft y GPL

Las licencias de software copyleft no son inherentemente compatibles con la GPL; incluso la licencia GPLv2 por sí sola no es compatible con GPLv3 o LGPLv3. [ 8 ] [ 30 ] [ 31 ] Si un desarrollador intentara combinar código publicado bajo cualquiera de las licencias GPL posteriores con código GPLv2, violaría la sección 6 de 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 de la GPL o posterior. [ 32 ] La mayoría del software publicado bajo GPLv2 permite usar también 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 kernel de Linux es una excepción notable que se distribuye exclusivamente bajo los términos de GPLv2. [ 34 ] [ 35 ]

GFDL y GPL

La licencia de documentación libre de 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. 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 ]

RAILs y GPL

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 utilizar los materiales licenciados bajo RAIL, mientras que la GPL prohíbe tales restricciones.

CDDL y GPL

Otro caso donde la compatibilidad con GPL es problemática es el sistema de archivos ZFS con licencia CDDL con el kernel de 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 CDDL es considerada incompatible con el kernel de Linux con licencia GPL, por la Free Software Foundation y algunas partes con relaciones con la FSF. [ 19 ] [ 44 ] La interpretación legal —de si y cuándo esta combinación constituye una obra combinada u obra derivada del kernel con licencia GPL— es ambigua y controvertida. [ 45 ] En 2015, la cuestión de la compatibilidad de CDDL con GPL resurgió cuando la distribución de Linux Ubuntu anunció que incluiría OpenZFS por defecto. [ 46 ] En 2016, Ubuntu anunció que una revisión legal resultó en la conclusión de que es legalmente seguro usar ZFS como un módulo binario del kernel 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 ] Eben Moglen , coautor de la GPLv3 y fundador de la SFLC , argumentó que si bien las letras de la GPL podrían violarse, el espíritu de ambas licencias se respeta, lo cual 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 ZFS sería una obra derivada del núcleo de Linux, y anunciaron su intención de lograr claridad en esta cuestión, incluso acudiendo a los tribunales. [ 50 ]

CC BY-SA y GPLv3

El 8 de octubre de 2015, Creative Commons declaró que las contribuciones a las adaptaciones de obras con licencia CC BY-SA 4.0 pueden licenciarse bajo la GPLv3 (aunque no al revés), lo que permite efectivamente el uso de material CC BY-SA 4.0 en proyectos GPLv3. [ 51 ]

Compatibilidad con licencias Creative Commons

Las licencias Creative Commons se utilizan ampliamente para la creación de contenido, pero no todas las combinaciones de las siete licencias recomendadas y compatibles son compatibles entre sí. Además, esta compatibilidad suele ser unidireccional, lo que requiere que la obra completa se licencie bajo la licencia más restrictiva de las obras originales.

Licencia JSON

El desarrollador de JSON, Douglas Crockford , inspirado por las palabras del entonces presidente Bush, formuló la licencia JSON para "malhechores" ("El software debe usarse para el bien, no para el mal"). Esta cláusula de licencia subjetiva y moral provocó problemas de incompatibilidad 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 ]

Re-licencia para compatibilidad

A veces, los proyectos terminan con licencias incompatibles, y la única solución viable es el cambio de licencia de las partes incompatibles. Este cambio se logra contactando a todos los desarrolladores y demás partes involucradas y obteniendo su consentimiento para la nueva licencia. Si bien en el ámbito del software libre y de código abierto suele ser imposible lograr un acuerdo del 100% debido a la gran cantidad de colaboradores, el proyecto de cambio de licencia de Mozilla asume que un 95% es suficiente para el cambio de licencia de todo el código base. [ 58 ] Otros en el ámbito del software libre y de código abierto, como Eric S. Raymond , llegaron a conclusiones diferentes respecto a los requisitos para el cambio de licencia de todo un código base. [ 59 ]

Ejemplos de renovación de licencias

Un ejemplo temprano de un proyecto que cambió de licencia con éxito 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 de Netscape / Licencia Pública de Mozilla [ 60 ] , pero fue criticado por la Free Software Foundation (FSF) y la OSI por ser incompatible con la Licencia Pública General de GNU (GPL). [ 61 ] [ 62 ] Alrededor de 2001, Time Warner , ejerciendo sus derechos bajo la Licencia Pública de Netscape, y a petición de la Fundación Mozilla , cambió la licencia [ 63 ] de todo el código de Mozilla que estaba bajo la Licencia Pública de Netscape (incluido el código de otros colaboradores) a una triple licencia MPL 1.1/GPL 2.0/ LGPL 2.1 , logrando así la compatibilidad con la GPL. [ 64 ]

La biblioteca Vorbis se licenció originalmente bajo la licencia 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 fuera retirado de la App Store de Apple a principios de 2011, el proyecto VLC volvió a licenciar la biblioteca VLC, de GPLv2 a LGPLv2, para lograr una mejor compatibilidad. [ 68 ] [ 69 ] En julio de 2013, el software volvió a licenciarse bajo la Licencia Pública de Mozilla , y la aplicación VLC se volvió 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 licencia Creative Commons Atribución-CompartirIgual , ampliamente utilizada, lo que supuso un problema para Wikipedia , por ejemplo. [ 71 ] Por consiguiente, a petición de la Fundación Wikimedia , la FSF añadió una sección temporal a la versión 1.3 de la GFDL que permitía a determinados tipos de sitios web que utilizaban la GFDL ofrecer también su trabajo bajo la licencia CC BY-SA. [ 72 ] Posteriormente, en junio de 2009, la Fundación Wikimedia migró sus proyectos ( Wikipedia , etc.) mediante una doble licencia a Creative Commons Atribución-CompartirIgual como licencia principal, además de la GFDL utilizada anteriormente , [ 38 ] para mejorar la compatibilidad de la licencia con el ecosistema de contenido libre en general . [ 39 ] [ 73 ]

Otro caso interesante fue el cambio de licencia de Google de los archivos de cabecera del kernel de Linux con licencia GPLv2 a la licencia BSD para su biblioteca de Android Bionic . Google afirmó que los archivos de cabecera estaban libres de cualquier obra protegible por derechos de autor, reduciéndolos a "hechos" no protegibles por derechos de autor y, por lo tanto, no cubiertos por la GPL. [ 74 ] [ 75 ] Esta interpretación fue cuestionada por Raymond Nimmer, profesor de derecho en el Centro de Derecho de la Universidad de Houston . [ 76 ] Las aplicaciones y los controladores de Android, que proporcionan una cantidad cada vez mayor de la funcionalidad de Android, han sido gradualmente cambiados 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 cambió su licencia 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 publicó bajo la permisiva licencia MPL 2.0 . No se redistribuye bajo la misma licencia, por lo que presumiblemente ahora tiene una nueva licencia y es propietario (aunque sigue siendo mayoritariamente de código abierto). [ 82 ] [ 83 ] KaiOS también utiliza el kernel de Linux GPL , que también se usa en Android. [ 84 ]

Véase también

Referencias

  1. O'Riordan, Ciaran (10 de noviembre de 2006). "Cómo la GPLv4 aborda la proliferación de licencias" . LinuxDevices.com. Archivado del original el 18 de diciembre de 2007.
  2. Neary, Dave (15 de febrero de 2012). "Áreas grises en las licencias de software" . LWN.net . Eklektix . Recuperado el 27 de febrero de 2016 .
  3. Stallman, Richard (29 de diciembre de 2021). "Compatibilidad de licencias y relicenciamiento" . GNU . Archivado del original el 24 de octubre de 2023.
  4. 1 2 Laurent, Philippe (24 de septiembre de 2008). "La GPLv3 y los problemas de compatibilidad" (PDF) . Evento de abogados europeos de código abierto 2008. Evento europeo de derecho de código abierto y software libre . Recuperado el 30 de mayo de 2015 .
  5. 1 2 Välimäki, Mikko (2005). El auge de las licencias de código abierto: un desafío para el uso de la propiedad intelectual en la industria del software (tesis doctoral). Universidad Tecnológica de Helsinki . Recuperado el 30 de diciembre de 2015 .
  6. Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. , 964 F.2d 965 , ¶10 (9th Cir. 21 de mayo de 1992).
  7. 1 2 «Preguntas frecuentes sobre la versión 2 de la GNU GPL» . Proyecto GNU . Fundación del Software Libre. 29 de mayo de 2015. ¿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 se incluyen en el mismo archivo ejecutable, sin duda se combinan en un solo programa. Si los módulos están diseñados para ejecutarse enlazados en un espacio de direcciones compartido, eso casi con seguridad significa combinarlos en un solo programa. […]
  8. 1 2 3 "Preguntas frecuentes sobre las licencias GNU" . Proyecto GNU . Fundación del Software Libre. 26 de mayo de 2016.'Usar una biblioteca' significa […] enlazar […].
  9. "Los orígenes de Linux y la LGPL" . Proyecto FreeBSD . Recuerda que la GPL exige que todo lo que enlace estáticamente con cualquier código bajo la GPL también se coloque bajo la GPL.
  10. Torvalds, Linus (17 de diciembre de 2006). "Re: Módulos solo GPL" (mensaje de correo electrónico) . LKML.ORG - Archivo de la lista de correo del kernel de Linux .
  11. Rosen, Lawrence (1 de enero de 2003). "Obras derivadas" . Linux Journal .
  12. Troan, Larry (2005). "Código abierto desde una perspectiva propietaria" (PDF) . Red Hat Summit 2006. Red Hat. Archivado del original (PDF) el 6 de marzo de 2016. Recuperado el 29 de diciembre de 2015 .
  13. Williamson, Aaron (5 de marzo de 2015). "Nueva demanda apunta a 'intermediarios' entre Linux y código propietario" . Tor Ekeland, PC .
  14. "La organización conservacionista anuncia financiación para la demanda por incumplimiento de la GPL" . Software Freedom Conservancy . 5 de marzo de 2015.
  15. Wheeler, David A. (27 de septiembre de 2007). "La diapositiva de la licencia de software libre/de código abierto (FLOSS)" . Página web personal de David A. Wheeler .
  16. Gordon, Thomas F. (15 de junio de 2010). "Informe sobre el alcance y la definición del problema de compatibilidad de licencias OSS" (PDF) . Qualipso.
  17. "Preguntas frecuentes sobre MPL 1.1 - Solo para uso histórico" . Mozilla . Consultado el 26 de febrero de 2012 .
  18. "Iniciativa de Código Abierto OSI - Licencia Pública de Mozilla 1.1 (MPL-1.1): Licencias" . Iniciativa de Código Abierto . Consultado el 26 de febrero de 2012 .
  19. 1 2 "Licencias de software libre incompatibles con la GPL" . Proyecto GNU . Fundación del Software Libre. 8 de julio de 2016. Recuperado el 26 de febrero de 2012 .
  20. Bezroukov, Nikolai . "Méritos comparativos de las licencias GPL, BSD y Artistic (Crítica de la naturaleza viral de la GPL v.2 - o En defensa de la idea de la doble licencia)" . Archivado del original el 22 de diciembre de 2001. 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 dificultan innecesariamente la vida de los desarrolladores que trabajan en el entorno Linux (KDE es un buen ejemplo, Python es un ejemplo menos conocido).
  21. Fogel, Karl. "La GPL y la compatibilidad de licencias" . Produciendo software de código abierto: cómo ejecutar un proyecto de software libre exitoso . Recuperado el 29 de noviembre de 2015. 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, diseñaron deliberadamente la licencia para que fuera imposible mezclar código GPL en programas propietarios. […] Cualquier obra derivada, es decir, cualquier obra 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 de la obra original o de una obra derivada.
  22. "Compatibilidad entre la Licencia Apache v2.0 y la GPL" . Apache Software Foundation . Consultado el 30 de mayo de 2015. Por lo tanto, el software Apache 2 puede incluirse en proyectos GPLv3, ya que la licencia GPLv3 acepta nuestro software como obras GPLv3. Sin embargo, el software GPLv3 no puede incluirse en proyectos Apache. Las licencias son incompatibles en una sola dirección, y esto se debe a la filosofía de licenciamiento de la ASF y a la interpretación de la ley de derechos de autor por parte de los autores de GPLv3.
  23. Hanwell, Marcus D. (28 de enero de 2014). "¿Debería usar una licencia permisiva? ¿Copyleft? ¿O algo intermedio?" . Opensource.com . Recuperado el 30 de mayo de 2015 . Las licencias permisivas simplifican las cosas Una razón por la que el mundo empresarial, y cada vez más desarrolladores […], prefieren las licencias permisivas es la simplicidad de la reutilización. La licencia generalmente 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 una obra derivada. Tampoco he visto nunca una tabla de compatibilidad de licencias para licencias permisivas; parece que todas son compatibles.
  24. "Compatibilidad de licencias" . Licencia pública de la Unión Europea . Joinup. 11 de junio de 2015. Archivado del original el 17 de junio de 2015. Recuperado el 30 de mayo de 2015. 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).
  25. "Entrevista con Allison Randal sobre la licencia artística 2.0" . El blog de CPAN . Archivado del original el 5 de septiembre de 2015.
  26. "Descripción de la Licencia Común de Desarrollo y Distribución (CDDL) y Resumen de Alto Nivel de los Cambios" . Sun Microsystems . Archivado del original el 14 de febrero de 2005.
  27. Tan, Aaron (14 de septiembre de 2005). "McNealy: CDDL es 'lo mejor de ambos mundos'"" . ZDNet .
  28. "Licencia común de desarrollo y distribución (CDDL-1.0)" . tl;drLegal . FOSSA. Archivado del original el 16 de marzo de 2016. Consultado el 11 de abril de 2016 .
  29. Wheeler, David A. (16 de febrero de 2014). "Haga que su software de código abierto sea compatible con la GPL. O aténgase a las consecuencias" . Página web personal de David A. Wheeler .
  30. Chisnall, David (31 de agosto de 2009). "El fracaso de la GPL" . InformIT . Pearson Education . Recuperado el 24 de enero de 2016. La GPL impone restricciones adicionales al código y, por lo tanto, es incompatible. Se puede combinar fácilmente código con licencias APSL, MPL, CDDL, Apache y BSD en el mismo proyecto, pero solo se puede combinar una de estas con código GPLv2. Ni siquiera la Free Software Foundation logra 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 LGPLv3 pero eran utilizados por otros proyectos que solo usaban GPLv2.
  31. Asay, Clark D. "La Licencia Pública General Versión 3.0: ¿Creando o destruyendo el Movimiento Foss?" . Revista de Derecho de Telecomunicaciones y Tecnología de Michigan . 14 (2). Facultad de Derecho de la Universidad de Michigan.
  32. Landley, Rob. "Charla de CELF 2013 Toybox" (texto sin formato) . landley.net . Consultado el 21 de agosto de 2013. La GPLv3 dividió la GPL en bifurcaciones incompatibles que no pueden compartir código.
  33. "Licencias de software libre compatibles con GPL" . Proyecto GNU . Fundación del Software Libre. 20 de noviembre de 2014. Consultado el 29 de diciembre de 2014 .
  34. Torvalds, Linus. "COPIANDO" . kernel.org . Consultado el 13 de agosto de 2013. Tenga en cuenta también que la ú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 cualquier otra), a menos que se indique explícitamente lo contrario.
  35. Linus Torvalds (8 de septiembre de 2000). "Linux-2.4.0-test8" . lkml.iu.edu . Consultado el 21 de noviembre de 2015. El único punto destacable que quisiera señalar directamente es la aclaración en el archivo COPYING, que deja claro que solo esa versión específica de la GPL es válida para el kernel. Esto no debería sorprender, ya que es la misma licencia que ha estado presente desde la versión 0.12 aproximadamente, pero pensé que sería conveniente dejarlo explícito.
  36. "Resolución: Por qué la Licencia de Documentación Libre de GNU no es adecuada para Debian" . Debian . 12 de marzo de 2006. Consultado el 20 de mayo de 2009 .
  37. "Cambio de licencia" . 6 de junio de 2007. Consultado el 20 de junio de 2009 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  38. 1 2 "Resolución: aprobación de la actualización de licencias" . Fundación Wikimedia . 23 de mayo de 2009.
  39. 1 2 Linksvayer, Mike (22 de junio de 2009). "Wikipedia + CC BY-SA = ¡Gana la cultura libre!" . Creative Commons .
  40. Contractor, Danish; McDuff, Daniel; Haines, Julia Katherine; Lee, Jenny; Hines, Christopher; Hecht, Brent; Vincent, Nicholas; Li, Hanlin (2022). «Licencias de uso conductual para una IA responsable» . Conferencia ACM 2022 sobre equidad, responsabilidad y transparencia . págs. 778–788 . doi : 10.1145/3531146.3533143 . ISBN  9781450393522.
  41. "2.2 ¿Cuál es el problema de licencias?" . zfsonlinux.com . Archivado del original el 26 de septiembre de 2010.
  42. Xu, Aron (28 de agosto de 2014). " [ zfs-discuss ] Resumen de ZFS en Linux para Debian (antes: zfs-linux_0.6.2-1_amd64.changes RECHAZADO)" (mensaje de correo electrónico) . ZFS en Linux . Recuperado el 14 de enero de 2016. El proyecto ZoL upstream [3] sostiene 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 incluye (ni incluirá nunca) ni facilita la creación de un kernel personalizado donde el controlador ZoL ZFS esté integrado en un binario monolítico, en lugar de compilado como un LKM dinámico independiente.
  43. Tagliamonte, Paul Richards (26 de agosto de 2014). "Pkg-zfsonlinux-devel -zfs-linux_0.6.2-1_amd64.changes RECHAZADO" . Archivado del original el 22 de febrero de 2016. Nuestro consenso fue que este paquete parece violar el espíritu de la GPL como mínimo y puede causar problemas legales. Los jueces suelen interpretar los documentos según su intención, y las soluciones alternativas para cumplir con la letra pero no con la intención no son bien vistas. Esto puede ser difícil de aceptar para los técnicos, pero en los casos legales, normalmente no se trata con personas técnicas. Por lo tanto, este paquete ha sido rechazado.
  44. jake (11 de septiembre de 2014). "Yao: El estado de ZFS en Linux" . LWN.net . Eklektix.
  45. ^ Jaeger, hasta (1 de marzo de 2005). Die GPL commenters und erklärt (PDF) (en alemán). Institut für Rechtsfragen der Freien und Open Source Software. pag. 70.ISBN  3-89721-389-3. Archivado desde el original (PDF) el 28 de julio de 2011 . Consultado el 12 de enero de 2016 . 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 )
  46. Larabel, Michael (6 de agosto de 2015). "Ubuntu planea convertir el sistema de archivos ZFS en una oferta 'estándar'" . Phoronix .
  47. Kirkland, Dustin (10 de febrero de 2016). "Licencias ZFS y Linux" . Ubuntu Insights . Canonical.
  48. Bottomley, James EJ (23 de febrero de 2016). "¿Son incompatibles GPLv2 y CDDL?" . Páginas aleatorias de James Bottomley . El análisis anterior muestra que, aunque presumimos que la combinación de GPLv2 y CDDL constituye una infracción técnica, no hay forma de procesarla judicialmente porque no podemos desarrollar una teoría convincente del daño resultante. Dado que esto imposibilita llevar el caso a los tribunales, en la práctica debe concluirse que la combinación de GPLv2 y CDDL, siempre que se siga un régimen de cumplimiento de GPLv2 para todo el código, es permisible.
  49. Moglen, Eben; Choudhary, Mishi (26 de febrero de 2016). "El núcleo de Linux, CDDL y cuestiones relacionadas" . Software Freedom Law Center .
  50. Kuhn, Bradley M.; Sandler, Karen M. (25 de febrero de 2016). "Violaciones de la GPL relacionadas con la combinación de ZFS y Linux" . Software Freedom Conservancy . En última instancia, varios tribunales del mundo tendrán que pronunciarse sobre la cuestión más general de las combinaciones de Linux. La conservancy está comprometida 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 históricamente hemos evitado las demandas a cualquier costo en el pasado, la ausencia de litigios sobre estas cuestiones hizo 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 nosotros mismos), junto con los miembros de nuestra coalición en el Proyecto de Cumplimiento de la GPL para Desarrolladores de Linux, todos estamos de acuerdo en que Canonical y otros infringen los derechos de autor de Linux cuando distribuyen zfs.ko.
  51. "Licencias compatibles" . Creative Commons . 8 de octubre de 2015. GPLv3: La Licencia Pública General GNU versión 3 fue declarada "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.
  52. "Preguntas frecuentes" . Creative Commons . 14 de julio de 2016. Consultado el 1 de agosto de 2016 .
  53. Las licencias Creative Commons sin requisitos de uso no comercial ni de no creación de obras derivadas, incluidas las de dominio público/CC0, son compatibles entre sí. Las licencias no comerciales son compatibles entre sí y con licencias menos restrictivas, excepto la de Atribución-CompartirIgual. Las licencias sin creación de obras derivadas no son compatibles con ninguna otra licencia, ni siquiera consigo mismas.
  54. Apache y la licencia JSON en LWN.net por Jake Edge (30 de noviembre de 2016)
  55. JSON en gnu.org
  56. Tanguy Ortolo considera que la licencia JSON es perjudicial (09-03-2012)
  57. Licencia JSON No en Fedoraproject.org
  58. O'Riordan, Ciaran (6 de octubre de 2006). "(Acerca de GPLv3) ¿Puede el núcleo de Linux cambiar de licencia?" . Free Software Foundation Europe . Recuperado el 28 de mayo de 2015 . Alguien que trabaja con muchos abogados en temas 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%. Según me dijeron, así fue como Mozilla pudo cambiar de licencia a la GPL en 2003 a pesar de años de contribuciones de la comunidad.
  59. Raymond, Eric Steven; Raymond, Catherine Olanich. "Licensing HOWTO" . Recuperado el 21 de noviembre de 2015. Cambiar una licencia existente […] Puede cambiar la licencia de un fragmento de código bajo cualquiera de las siguientes condiciones: Si usted es el único titular de los derechos de autor […] Si usted es el único titular registrado de los derechos de autor […] 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 resultar perjudicado por el cambio.
  60. "Preguntas frecuentes sobre la licencia pública de Netscape" . Mozilla . Archivado del original el 27 de agosto de 2015.
  61. "Licencias por nombre" . Iniciativa de código abierto . Consultado el 27 de agosto de 2014 .
  62. Stallman, Richard (14 de diciembre de 2015). "Sobre la Licencia Pública de Netscape" . Proyecto GNU . Fundación del Software Libre.
  63. "Preguntas frecuentes sobre el cambio de licencia de Mozilla, versión 1.1" . Mozilla . 14 de agosto de 2007. Archivado del original el 13 de mayo de 2010. Hace algún tiempo, mozilla.org anunció su intención de buscar un cambio de licencia para el código de Mozilla bajo un nuevo esquema de licencia 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).
  64. Markham, Gervase (31 de marzo de 2006). "Re-licencia completada" . Hacking for Christ .
  65. Moffitt, Jack (26 de febrero de 2001). " [ vorbis ] Xiph.org anuncia Vorbis Beta 4 y la Fundación Xiph.org" (mensaje de correo electrónico) . Xiph.Org . Con el lanzamiento de la Beta 4, las bibliotecas Ogg Vorbis se han pasado a la licencia BSD. El cambio de LGPL a BSD se realizó para permitir el uso de Ogg Vorbis en todo tipo de software y hardware. Jack Moffitt afirma: "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 y más favorable a los sistemas de software y hardware propietarios. Queremos que todo el mundo pueda usar Ogg Vorbis".
  66. Stallman, Richard (26 de febrero de 2001). "RMS en la licencia Ogg Vorbis" (mensaje de correo electrónico) . LWN.net .
  67. Denis-Courmont, Rémi. "El reproductor multimedia VLC seguirá bajo la versión 2 de la GNU GPL" . VideoLAN . Consultado el 21 de noviembre de 2015. En 2001, VLC se lanzó bajo la versión 2 de la GNU General Public, aprobada por la OSI, con la opción comúnmente ofrecida de usar "cualquier versión posterior" de la misma (aunque no existía tal 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 GNU General Public License (GPL) el 29 de junio de 2007, los colaboradores del reproductor multimedia VLC y otros proyectos de software alojados en videolan.org debatieron la posibilidad de actualizar los términos de la 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 puedan no coincidir con la realidad industrial y económica de nuestro tiempo, especialmente en el mercado de la electrónica de consumo. Consideramos que cambiar nuestros términos de licencia a la GPL versión 3 no sería lo más conveniente para nuestra comunidad en general. Por consiguiente, planeamos seguir distribuyendo las futuras versiones del reproductor multimedia VLC bajo los términos de la GPL versión 2. […] Continuaremos distribuyendo el código fuente del reproductor multimedia VLC bajo la GPL versión 2 o cualquier versión posterior hasta nuevo aviso.
  68. Kempf, Jean-Baptiste (7 de septiembre de 2011). "Cambio de la licencia del motor VLC a LGPL" . Recuperado el 23 de octubre de 2011 .
  69. Vaughan-Nichols, Steven J. (8 de enero de 2011). "No se permiten aplicaciones GPL en la App Store de Apple" . ZDNet . Archivado del original el 9 de enero de 2011. Consultado el 23 de agosto de 2011 .
  70. Johnston, Casey (18 de julio de 2013). "El reproductor multimedia VLC regresa a la App Store de iOS después de 30 meses de ausencia" . Ars Technica . Consultado el 10 de octubre de 2013 .
  71. Ménard, Delphine. "Por qué los proyectos de Wikimedia no deberían usar GFDL como licencia independiente para imágenes" . notablog .
  72. "Preguntas frecuentes sobre GFDL v1.3" . Proyecto GNU . Fundación del Software Libre. 12 de abril de 2014. Consultado el 7 de noviembre de 2011 .
  73. Moeller, Erik (30 de junio de 2009). "Actualización de licencia implementada en todas las wikis de Wikimedia" . Blog de Wikimedia . Quizás la razón más importante para elegir CC-BY-SA como nuestra licencia de contenido principal fue ser compatibles con muchos de los otros esfuerzos admirables que existen para compartir y desarrollar conocimiento libre.
  74. Metz, Cade (29 de marzo de 2011). "Los encabezados 'limpios' de Linux de Google: ¿son realmente tan sucios?" . The Register .
  75. Proffitt, Brian (21 de marzo de 2011). "Android: Demandado por Microsoft, no por Linux" . ITworld . Microsoft lanza una nueva demanda contra Android, la opinión de Linus Torvalds sobre los encabezados del kernel de Linux y Android.
  76. Nimmer, Raymond (2011). "Riesgo de infracción y divulgación en el desarrollo en plataformas copyleft" . Contemporary Intellectual Property, Licensing & Information Law . Archivado del original el 7 de enero de 2016.
  77. Amadeo, Ron (21 de julio de 2018). "El férreo control de Google sobre Android: Controlar el código abierto por cualquier medio necesario" . Ars Technica .
  78. Prokoudine, Alexandre (27 de diciembre de 2012). "Drama de LibreDWG: ¿el final o el nuevo comienzo?" . Libre Arts . Recuperado el 9 de marzo de 2025. […] la desafortunada situación con la compatibilidad de archivos DWG en software CAD libre a través de LibreDWG. Creemos que, a estas alturas, debería estar cerrado. Tenemos la respuesta final de la FSF. […] 'No vamos a cambiar la licencia'.
  79. "Licencia" . FreeCAD . Consultado el 25 de marzo de 2015. Licencias utilizadas en FreeCAD: FreeCAD utiliza dos licencias diferentes, una para la propia aplicación y otra para la documentación: Licencia Pública General Reducida, versión 2 o superior (LGPL2+) […] Licencia de Publicación Abierta
  80. "License.txt" . Gang-Garrison-2 . GitHub. 9 de noviembre de 2014. Consultado el 23 de marzo de 2015 .
  81. MedO (23 de agosto de 2014). "Cambio de licencia previsto (GPL -> MPL), se necesita ayuda" (publicación en el foro) . Foros de Gang Garrison 2. Consultado el 23 de marzo de 2015. Resumen: La licencia actual nos impide usar ciertas bibliotecas/frameworks buenos y gratuitos, así 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.
  82. "¿Puedo acceder al código fuente? : KaiOS" . Support.kaiostech.com . 
  83. "Repositorio KaiOS/B2G" . GitHub . 3 de junio de 2021.
  84. "KaiOS está funcionando bien en India, pero también está obteniendo cifras importantes en EE. UU." . Android Authority . 1 de marzo de 2019.
  • Re-licensing Combined Datasets (ReCoDa) – Verificación de compatibilidad de licencias en línea