¿Existe una licencia LGPL modificada que permita la vinculación estática?

LGPL requiere que si un programa usa la biblioteca LGPL-ed, los usuarios deben poder volver a vincular el programa con una versión diferente de la biblioteca:

...

d) Realice una de las siguientes acciones:

0) Transmitir la Fuente correspondiente mínima bajo los términos de esta Licencia, y el Código de aplicación correspondiente en una forma adecuada y bajo términos que permitan al usuario recombinar o volver a vincular la Aplicación con una versión modificada de la Versión vinculada para producir un Trabajo combinado modificado, de la manera especificada en la sección 6 de la GNU GPL para transmitir la fuente correspondiente.

1) Utilice un mecanismo de biblioteca compartida adecuado para vincular con la Biblioteca. Un mecanismo adecuado es aquel que (a) utiliza en tiempo de ejecución una copia de la Biblioteca ya presente en el sistema informático del usuario, y (b) funcionará correctamente con una versión modificada de la Biblioteca que sea compatible con la interfaz de la Versión Vinculada.

...

Sin embargo, en algunos casos, esto puede plantear dificultades considerables. En particular, los programas de Haskell casi siempre se compilan estáticamente. Además, el compilador realiza optimizaciones entre módulos, por lo que no es posible extraer una parte del código y reemplazarlo por otra. Entonces es muy difícil satisfacer esta condición. (Ver este enlace en Haskell Wiki).

La vinculación dinámica sería una solución, pero en muchos casos, esto no es posible. Por ejemplo:

• Algunas plataformas pueden no tener enlaces dinámicos en absoluto.
• Algunos idiomas no tienen la posibilidad de vinculación dinámica. O bien, no es posible hacer módulos multiplataforma.
• En algunos casos, la vinculación dinámica evitaría importantes optimizaciones. Si bien diría que esto rara vez es un problema grave, en idiomas como Haskell, la pérdida de rendimiento podría ser considerable.

Por lo tanto, estoy buscando una licencia estándar similar a LGPL que no requiera la posibilidad de volver a vincular (y entiendo que eso elimina un poco de libertad otorgada a los usuarios). Algunos proyectos usan su propia modificación de LGPL, por ejemplo wxWidgets . Pero prefiero usar alguna licencia estándar que sea algo más oficial, tal vez verificada por algunos expertos en derecho y compatible con (L) GPL. ¿Hay algo así?

(También me interesaría saber si hay algunas consecuencias imprevistas de tal modificación de LGPL).

Me sorprende que nadie haya mencionado la Licencia Pública de Mozilla. Es similar a la LGPL, excepto que permite la vinculación estática. La versión 2 de MPL es compatible con la GPL / LGPL.

Licencia pública de Mozilla (MPL 2.0) vs Licencia pública general de Lesser GNU (LGPL 3.0)

wxwidgets se licencia bajo esencialmente = LGPL + enlace estático

... esencialmente la L-GPL (Licencia Pública General de la Biblioteca), con una excepción que establece que los trabajos derivados en forma binaria pueden distribuirse en los propios términos del usuario. Esta es una solución que satisface a aquellos que desean producir software GPL usando wxWidgets, y también a aquellos que producen software propietario.

wxWidgets es un software certificado de código abierto. Los participantes en la discusión que llevó a esta decisión incluyen a la gente de Abisource , Robert Roebling, Julian Smart, Markus Fleck, Karsten Ballueder y algunos consejos de Richard Stallman. Richard ha confirmado que la nueva licencia es compatible con las aplicaciones GPL. Sin embargo, no hay restricciones significativas en las aplicaciones propietarias.

La licencia de wxWindows ha sido aprobada por Open Source Initiative , y puede encontrar la licencia en su sitio aquí ...

IANAL, pero se me ha hecho creer que una solución es proporcionar archivos de objetos para piezas que no sean LGPL. De esa forma, el usuario puede volver a vincular el programa y, por lo tanto, es libre de cambiar la parte LGPL, cumpliendo los requisitos de LGPL.

En otras palabras, debe tener un paquete fuente, con fuentes LGPL y archivos de objetos compilados de código que no sea LGPL. Obviamente, debe proporcionar archivos de objetos para cada arquitectura diferente para la que publica los binarios, pero no creo que esto sea un gran problema.

Desde el punto de vista del desarrollo, lo más simple podría ser simplemente que el sistema de compilación también compile el paquete fuente al mismo tiempo, al compilar el binario para su distribución.

Encontré uno con Google: licencia OpenScales

OpenScales se lanzó bajo la versión 3 de la Licencia pública menor de GNU (LGPL, disponible aquí ), con una excepción relacionada con la excepción de enlace estático (ver más abajo) ...

Además del texto de la licencia LGPL, la excepción a las condiciones LGPL se aplica a OpenScales:

Como una excepción especial a la Licencia 3 de GNU Lesser General Public License, puede transmitir a un tercero un archivo ejecutable de un Trabajo combinado que vincule, estática o dinámicamente, partes de esta Biblioteca en el archivo ejecutable, transmitiendo la Fuente mínima correspondiente pero sin la necesidad de transmitir el Código de Aplicación correspondiente en la sección 4d0 de la Licencia Pública General Menor de GNU, siempre y cuando esté utilizando una versión de la Biblioteca distribuida públicamente sin modificar. Esta excepción no invalida ninguna otra razón por la cual el archivo ejecutable podría estar cubierto por la Licencia pública general menor de GNU o la Licencia pública general de GNU.

Sin embargo, no es estándar, y no sé si existe.

¿Cómo continuaría garantizando la libertad del usuario? Creo que la respuesta "correcta" es vincular estáticamente una cuña que carga dinámicamente la biblioteca.