Me gustaría lanzar una biblioteca de software escrita en un lenguaje de programación orientado a objetos (Java) basado en clases en un servicio de alojamiento de código fuente basado en la web , que permita fusionar los tenedores del proyecto en el proyecto principal (GitHub a través de pull peticiones). He investigado en la web y he pensado mucho en cómo licenciar el software. ¿Estoy en lo correcto en los siguientes supuestos (desde una perspectiva IANAL )?

• Tanto LGPL como MPL promueven el intercambio de modificaciones al software con licencia LGPL / MPL que se utiliza dentro de otros proyectos de software. En lugar de exigir a los usuarios de la biblioteca modificada que alojen una bifurcación separada de la biblioteca, puedo promover la contribución a la biblioteca original (por ejemplo, a través de solicitudes de extracción).

• La principal diferencia es cómo el código de licencia MPL / LGPL debe estar vinculado al proyecto. Los archivos de código fuente MPL pueden copiarse directamente en un (posiblemente) proyecto de software propietario ( enlace estático ), mientras que el código con licencia LGPL debe vincularse dinámicamente (vincularse libremente al proyecto de software posiblemente propietario, para que los usuarios finales puedan cambiar el software con licencia biblioteca para otra versión de la biblioteca de software con licencia).

• El enlace dinámico y, por lo tanto, LGPL impone obstáculos adicionales para empaquetar el producto de software patentado, sin promover más contribuciones a la biblioteca de software de código abierto que tener un enlace estático (y, por lo tanto, MPL). Hay una LGPL modificada que permite la vinculación estática.

• No hay otras diferencias relevantes (desde una perspectiva IANAL ).

• Las versiones de licencia anteriores no satisfacen mis necesidades tan bien como las más nuevas.

Como puede ver, mi requisito principal es que las modificaciones de la biblioteca de software que podrían resultar útiles para el público en general permanezcan de código abierto, sin imponer restricciones sobre el uso de la biblioteca de software en un producto patentado.
No hay una licencia que también requiera que las extensiones de la biblioteca de software que son relevantes para el trabajo original se publiquen como código abierto, ya que el alcance del término relevante puede ser arbitrariamente pequeño / enorme, lo que termina como GPL que no puede ser utilizado en un producto patentado (sin liberar toda la fuente).

Estoy tentado a usar el LPGL modificado , pero, por otro lado, me desanima la impopularidad. En base a los puntos anteriores, prefiero MPL.
Pregunta: ¿Son correctas mis declaraciones anteriores? ¿Qué licencia debo elegir teniendo en cuenta mis requisitos?

Solución: Con la ayuda de la discusión en la respuesta aceptada, elijo apegarme al MPL debido a la popularidad , la libertad de vinculación y porque es una licencia oficial no modificada .

Creo que ha declarado con precisión las diferencias entre la Licencia pública de Mozilla y la Licencia pública general menor de GNU , y puede satisfacer sus necesidades perfectamente, pero se está saltando la diferencia más importante entre las dos licencias:

¿Quién puede hacer nuevas versiones?

Tanto la MPL (sección 10) como la LGPL (sección 14) incluyen en su licencia el derecho de sustituir la versión actual por una última versión, y no existen limitaciones reales en cuanto a qué pueden incluir esas licencias. Si bien es muy poco probable que la Fundación Mozilla o la Fundación para el Software Libre hagan algo tan loco como, por ejemplo, instituir una cláusula que diga "todas las contribuciones a este software se convierten en nuestra propiedad", no está fuera del alcance de la posibilidad de que Las organizaciones lanzarán una nueva versión de licencia que no les gusta.

Lo que trae a colación otro punto sobre el uso de una "LGPL modificada".

¡Una licencia modificada no es la misma licencia!

Si bien tiene una capacidad bastante sorprendente para especificar sus propios términos de licencia y, en esencia, podría decir "puede distribuir esto según la GPL, pero necesita poner mi nombre en sus créditos y pagarme el 1% de los ingresos que genere" , cada vez que lo haga, estará creando una nueva licencia basada en el trabajo de otra persona. Esto significa que NO está utilizando la MPL o la LGPL, está utilizando una nueva "licencia de mucaho".

Lo que eso significa es que probablemente no obtendrá ninguna ayuda del autor de su licencia original si necesita defender su interpretación de la licencia dentro de una sala del tribunal, y es muy posible que puedan presentar una demanda para decir que SU versión debería aplicarse y no es tuyo.

Por supuesto, ambos son puntos menores. Incluso la "popularidad de la licencia" no importa a menos que espere que su código se incorpore directamente en proyectos más grandes.

Personalmente, creo que el MPL es una mejor opción si le gusta la compatibilidad patentada, o si la elección es entre el MPL real y una licencia diferente que tiene que editar manualmente según la LGPL. A menos que tenga una razón para no usar el MPL, vaya con algo respaldado por una base en lugar de uno que pueda dejarlo en la sala del tribunal sin ningún tipo de ayuda.

La respuesta de DougM y AER hace un punto justo. MPLv2 y LGPLv3 con excepción estática son los mismos con respecto a los eventos que desencadenarían el copyleft. Sin embargo, creo que nos falta otra diferencia muy importante entre LGPL y MPL. Cuando se activa el copyleft, el copyleft se aplica a:

• para MPL: a los mismos archivos de su biblioteca original
• para LGPL: al "trabajo basado en la biblioteca" en oposición al "trabajo que usa la biblioteca". Por lo tanto, la LGPL puede extender su copyleft a nuevos archivos.

Edge-case: el uso de MPL permite a los usuarios no compartir sus mejoras

MPL es una licencia de copyleft a nivel de archivo. Significa que si alguien lo incrusta en un proyecto más grande (estática o dinámicamente) y realiza un cambio en su archivo, solo tiene que liberar el cambio realizado en este archivo en particular.

Si le preocupa mantener abierta la integridad de su base de código, hay casos extremos en los que este efecto copyleft de MPL podría no ser suficiente.

Por ejemplo, alguien podría tomar uno de los archivos principales de su proyecto, agregar "import my_private_new_file" y modificar su método principal, por ejemplo, agregando "my_private_new_file.newAwesomeFeature.run ()" .

Y de esta manera podría agregar nuevas características a su proyecto mientras solo libera el archivo principal modificado y mantiene la lógica real de la nueva fuente de fuente cerrada en "my_private_new_file" .

Hacer que el archivo principal vuelva a la comunidad solo le brinda la información que dice "oye, agregó una nueva función", pero no le permite incorporar esta nueva función de forma abierta ... Puede ser molesto si la nueva función está muy cerca relacionado con el problema que su biblioteca está tratando de resolver.

Obviamente, ese es un caso extremo y es bastante improbable que alguien quiera hacer eso, pero es un riesgo que debe tener en cuenta al usar el MPLv2.

La LGPL está escrita para prohibir tales comportamientos. Ver:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• ¿La LGPL me permite hacer esto?

Cito la licencia LGPL original:

Preste mucha atención a la diferencia entre un "trabajo basado en la biblioteca" y un "trabajo que utiliza la biblioteca". El primero contiene código derivado de la biblioteca, mientras que el segundo debe combinarse con la biblioteca para poder ejecutarse.

El copyleft se aplica únicamente al "trabajo basado en la biblioteca". Ahora, ¿qué es un "trabajo basado en la biblioteca" en la práctica? Deja espacio a la interpretación. Lo cual no solo es algo bueno, ya que significa que cumplir con su licencia se vuelve más complicado y, por lo tanto, aterrador. Podría llevar a algunas personas simplemente a no usar su biblioteca.

En este sentido, LGPL es más restrictivo que MPL, pero también protege más la integridad del proyecto.

MPL hace que sea más fácil para los usuarios del mundo propietario arreglar su biblioteca y usarla, sin dejar de compartir la solución

Una ventaja para MPL es que si un usuario encuentra un error en su biblioteca, puede corregirlo directamente en el archivo, sin tener que entregar todo su código, sino solo proporcionar la solución. Hablando en términos prácticos, cuando distribuye su trabajo a un cliente, él solo puede proporcionar un enlace a una bifurcación de su proyecto que contiene la solución, y es bueno.

Al usar LGPL, las cosas son más complicadas. Si alguien bifurca su proyecto, corrige un error y lo incrusta estáticamente en su software propietario, debe distribuir a sus usuarios el "trabajo basado en la biblioteca" bajo la LGPL. Lo cual es una noción bastante oscura, especialmente cuando la biblioteca está estáticamente incrustada ... En este sentido, creo que fue la razón original por la que no existe una excepción "estática" en la LGPL original. Hace que la identificación del "trabajo basado en la biblioteca" sea trivial: es la biblioteca dinámica a la que llama en su software propietario.

Como resultado, MPL hace que sea más fácil para los proveedores propietarios usar Y enviar soluciones a su biblioteca que LGPL.

Al mismo tiempo, la mayoría de las veces los proveedores propietarios no tienen los recursos ni el tiempo para sumergirse en su biblioteca complicada, y lo más probable es que no lo arreglen solos. Prefieren abrir un problema en su repositorio de GitHub, o enviar un correo electrónico en la lista de correo y esperar su solución.

En este sentido, LGPL impone más este tipo de comportamiento. ¿Pero es realmente necesario hacer cumplir?

Conclusión

Elegir entre LGPL y MPL es una pregunta difícil y, como es habitual con la licencia de software, depende de su objetivo. Ambas licencias son muy similares pero al mismo tiempo extremadamente diferentes. Fueron diseñados para objetivos y filosofías muy diferentes.

LGPL fue creado por la Free Software Foundation para permitir el uso generalizado de las bibliotecas de software libre en el mundo propietario, pero siempre teniendo en mente la idea de promover el software libre y luchar contra los softwares propietarios. Todo es parte de una estrategia hacia su ideología. Ver: https://www.gnu.org/licenses/why-not-lgpl.html

MPL es una licencia práctica diseñada por Mozilla para imponer algún tipo de uso compartido de la biblioteca original, al tiempo que alienta a las personas a hacer softwares y complementos patentados (incluido Mozilla), que es una práctica que la FSF autoriza a través de LGPL pero aún se considera dañino.

En esencia, MPLv2 es considerado por muchos como una licencia permisiva, mientras que LGPLv3, incluida la excepción estática, rara vez se llama de esta manera.

EDITAR

Olvidé mencionar algo importante. LGPLv3 (con o sin excepción estática) prohíbe la tivoización . Puede pensar que es un "detalle", pero en realidad no lo es, dependiendo de su objetivo. ¿Te interesan los usuarios Freedom? Entonces no es un detalle. ¿Te importa que tu biblioteca se pueda usar en el dispositivo de Apple? VLC se preocupa más por su uso, por lo que decidieron usar LGPLv2 que no contiene esa restricción. Del mismo modo, esa es una de las razones por las que Linux sigue usando GPLv2 . MPLv2 tampoco tiene ninguna restricción de tiviozation, obviamente ya que es una licencia creada con la filosofía de código abierto más "práctica" en mente, no con la ideología FSF.

Podría haber otras cosas "menores" como esta que me perdí.