O fornecimento de arquivos de objetos atende à cláusula de revinculação LGPL?

A partir desta questão no SO , eu li que:

Código fonte proprietário + código fonte LGPL

estaticamente vinculado:
- Você deve liberar as duas partes como LGPL.
- Ou forneça tudo o que permita ao usuário vincular novamente o aplicativo a uma versão diferente do código-fonte LGPL. Nesse caso, os outros requisitos são os mesmos que se estivessem vinculados dinamicamente.

Portanto, parece que fornecer arquivos de objetos é suficiente para satisfazer a LGPL em termos de vincular estaticamente uma biblioteca LGPL a um aplicativo de código proprietário. Enquanto o executável está vinculado estaticamente, o fornecimento dos arquivos de objeto permite que o usuário final recompile o aplicativo, vinculando-o a uma versão diferente da biblioteca.

Isso está correto e, se não, então por quê?

lgpl static-linking

— IvanB
fonte

Sim, você está completamente correto. Fornecer os arquivos de objeto para seu aplicativo é suficiente para satisfazer a LGPL, pois permite ao usuário substituir a biblioteca LGPL por outra versão, se assim o desejar.

A FSF diz isso explicitamente no seu FAQ :

Para fins de conformidade com a LGPL (qualquer versão existente: v2, v2.1 ou v3):

(1) Se você vincular estaticamente a uma biblioteca LGPL, também deverá fornecer seu aplicativo em um formato de objeto (não necessariamente de origem) , para que um usuário tenha a oportunidade de modificar a biblioteca e vincular novamente o aplicativo.

(2) Se você vincular dinamicamente a uma biblioteca LGPL já presente no computador do usuário, não precisará transmitir a fonte da biblioteca. Por outro lado, se você mesmo transmitir a biblioteca executável da LGPL junto com seu aplicativo, vinculado estaticamente ou dinamicamente, também deverá transmitir as fontes da biblioteca, de uma das maneiras pelas quais a LGPL fornece.

— Ixrec
fonte

Então, por que o Qt "insiders" e os funcionários alegam continuamente o contrário? O LGPL do Qt é modificado ou algo assim?

— 21716 IvanB

Não estou familiarizado com a situação do Qt, mas, ao examinar suas páginas de licenciamento, não vejo nenhum idioma que negue explicitamente essa possibilidade. Eu acho que eles simplesmente o omitem em favor da recomendação de vinculação dinâmica (que provavelmente é a solução mais simples para a maioria dos usuários). A redação mais relevante que vejo é: "No caso de vinculação estática da biblioteca, o aplicativo em si pode não ser mais" um trabalho que usa a biblioteca "e, portanto, ficar sujeito à LGPL. É recomendável vincular dinamicamente ou fornecer o código-fonte do aplicativo para o usuário sob LGPL. ", o que é totalmente razoável.

— Ixrec 14/03/16

Também parece que alguns módulos do Qt estão disponíveis apenas na GPL, e não na LGPL, se eu estiver lendo estas páginas corretamente, então é possível que se eles mencionassem a opção de vinculação estática com objetos, eles também precisariam aderir "a menos que você use X, Y ou Z" e detalhes tangenciais chatos semelhantes.

— Ixrec 14/03/16

Em um mundo perfeito, a vinculação dinâmica pode ser ótima, mas neste mundo e ao lidar com o Qt, a vinculação dinâmica é um inferno. Como mais de 60 megabytes de dlls, muitos dos quais a ferramenta de implantação não traz e o dependente walker não detecta. Em suas próprias perguntas frequentes sobre LGPL, não vejo

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.

nada sobre ser obrigatório.

— IvanB

Lendo as perguntas frequentes, parece que eles têm apenas uma tímida alegação de que a LGPL não permite que aplicativos proprietários se vinculem estaticamente ao Qt, embora sejam muito diligentes em implicar isso.

— IvanB