¿Proporcionar archivos de objetos satisface la cláusula de vinculación LGPL?

10

De esta pregunta sobre SO , leí que:

Código fuente propietario + código fuente LGPL

  • estáticamente vinculado:
    • O bien, debe liberar ambas partes como LGPL.
    • O proporcione todo lo que permita al usuario volver a vincular la aplicación con una versión diferente del código fuente LGPL. En este caso, los otros requisitos son los mismos que si estuvieran vinculados dinámicamente.

Por lo tanto, parece que proporcionar archivos de objetos es suficiente para satisfacer a LGPL en términos de vinculación estática de una biblioteca LGPL a una aplicación de código patentada. Mientras que el ejecutable está vinculado estáticamente, proporcionar los archivos de objetos permite al usuario final volver a compilar la aplicación, vinculando a diferentes versiones de la biblioteca.

¿Es esto correcto? Y si no, ¿por qué?

lgpl static-linking IvanB
fuente

Respuestas:

7

Sí, tienes toda la razón. Proporcionar los archivos de objetos para su aplicación es suficiente para satisfacer la LGPL porque permite al usuario reemplazar la biblioteca LGPL'd con alguna otra versión si así lo desea.

La FSF incluso lo dice explícitamente en sus preguntas frecuentes :

Con el fin de cumplir con la LGPL (cualquier versión existente: v2, v2.1 o v3):

(1) Si enlaza estáticamente con una biblioteca LGPL'd, también debe proporcionar su aplicación en un formato de objeto (no necesariamente fuente) , de modo que el usuario tenga la oportunidad de modificar la biblioteca y volver a vincular la aplicación.

(2) Si se vincula dinámicamente con una biblioteca LGPL'd ya presente en la computadora del usuario, no necesita transmitir la fuente de la biblioteca. Por otro lado, si usted mismo transmite la biblioteca LGPL'd ejecutable junto con su aplicación, ya sea vinculada de forma estática o dinámica, también debe transmitir las fuentes de la biblioteca, en una de las formas que proporciona la LGPL.

Ixrec
fuente
1
Entonces, ¿por qué los "expertos" y los empleados de Qt afirman continuamente lo contrario? ¿Se modifica la LGPL de Qt o algo así?
IvanB
No estoy familiarizado con la situación de Qt, pero al hojear sus páginas de licencia no veo ningún lenguaje que explícitamente niegue esta posibilidad. Creo que simplemente lo omiten a favor de recomendar enlaces dinámicos (que probablemente sea la solución más simple para la mayoría de los usuarios). La redacción más relevante que veo es: "En caso de vinculación estática de la biblioteca, la aplicación en sí misma ya no puede ser" trabajo que utiliza la biblioteca "y, por lo tanto, quedar sujeta a LGPL. Se recomienda vincular dinámicamente o proporcionar código fuente de la aplicación para el usuario bajo LGPL ", lo cual es completamente razonable.
Ixrec
También parece que algunos módulos de Qt solo están disponibles bajo la GPL en lugar de la LGPL, si estoy leyendo estas páginas correctamente, entonces es posible que si mencionaran la opción de vinculación estática con objetos también tendrían que agregar "a menos que use X, Y o Z" y detalles tangenciales aburridos similares.
Ixrec
1
En un mundo perfecto, la vinculación dinámica puede ser excelente, pero en este mundo y cuando se trata de Qt, la vinculación dinámica es un infierno. Al igual que más de 60 megabytes de dlls, muchos de los cuales la herramienta de implementación no trae y el explorador de dependencias no detecta. En sus propias preguntas frecuentes sobre LGPL, veo un The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.pero nada sobre ser obligatorio.
IvanB
44
Al leer sus preguntas frecuentes, parece que son tímidos de hacer una (falsa) afirmación de que LGPL no permite que las aplicaciones propietarias se vinculen estáticamente a Qt, a la vez que son muy diligentes para implicarlo.
IvanB