Fornire file oggetto soddisfa la clausola di ricollegamento LGPL?

Codice sorgente proprietario + codice sorgente LGPL

staticamente collegato:
- O è necessario rilasciare entrambe le parti come LGPL.
- O fornire tutto ciò che consente all'utente di ricollegare l'applicazione con una versione diversa del codice sorgente LGPL. In questo caso, gli altri requisiti sono gli stessi di quelli collegati dinamicamente.

Quindi sembra che fornire file oggetto sia sufficiente per soddisfare LGPL in termini di collegamento statico di una libreria LGPL a un'applicazione di codice proprietaria. Mentre l'eseguibile è staticamente collegato, fornire i file oggetto consente all'utente finale di ricompilare l'applicazione, collegandosi a versioni diverse della libreria.

È corretto, e se no, allora perché?

lgpl static-linking

— IvanB
fonte

Sì, hai completamente ragione. Fornire i file oggetto per l'applicazione è sufficiente per soddisfare la LGPL perché consente all'utente di sostituire la libreria LGPL con un'altra versione se lo desidera.

La FSF lo dice anche esplicitamente nelle loro FAQ :

Ai fini della conformità con la LGPL (qualsiasi versione esistente: v2, v2.1 o v3):

(1) Se si collega staticamente a una libreria LGPL, è necessario fornire anche l'applicazione in un formato oggetto (non necessariamente sorgente) , in modo che un utente abbia la possibilità di modificare la libreria e ricollegare l'applicazione.

(2) Se si collega dinamicamente a una libreria LGPL già presente sul computer dell'utente, non è necessario comunicare l'origine della libreria. D'altra parte, se tu stesso trasmetti la libreria eseguibile LGPL'd insieme alla tua applicazione, sia essa collegata staticamente o dinamicamente, devi anche trasmettere le fonti della libreria, in uno dei modi previsti dalla LGPL.

— Ixrec
fonte

Allora perché gli "addetti ai lavori" di Qt e i dipendenti sostengono continuamente il contrario? La LGPL di Qt è stata modificata o qualcosa del genere?

— IvanB,

Non ho familiarità con la situazione di Qt, ma sfogliando le loro pagine di licenza non vedo alcun linguaggio che neghi esplicitamente questa possibilità. Penso che si limitino a ometterlo per raccomandare il collegamento dinamico (che probabilmente è la soluzione più semplice per la maggior parte degli utenti). La formulazione più rilevante che vedo è: "In caso di collegamento statico della libreria, l'applicazione stessa potrebbe non essere più" lavoro che utilizza la libreria "e quindi diventare soggetta a LGPL. Si consiglia di collegarsi dinamicamente o fornire il codice sorgente dell'applicazione all'utente sotto LGPL. ", che è del tutto ragionevole.

— Ixrec,

Sembra anche che alcuni moduli di Qt siano disponibili solo sotto GPL piuttosto che LGPL, se sto leggendo queste pagine nel modo giusto, quindi è possibile che se menzionassero il collegamento statico con l'opzione degli oggetti dovrebbero anche puntare su "a meno che tu non usi X, Y o Z" e simili dettagli tangenziali noiosi.

— Ixrec,

In un mondo perfetto, il collegamento dinamico potrebbe essere fantastico, ma in questo mondo e quando si ha a che fare con Qt, il collegamento dinamico è un inferno. Come 60+ megabyte di DLL, molti dei quali lo strumento di distribuzione non introduce e il walker di dipendenze non rileva. Nelle loro FAQ LGPL vedo 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.

ma nulla di obbligatorio.

— IvanB,

Leggendo le loro FAQ, sembra che siano solo timidi di fare una (falsa) affermazione che LGPL non consente alle applicazioni proprietarie di collegarsi staticamente a Qt, mentre è molto diligente nel implicarlo.

— IvanB