Existe uma brecha na GPL que permite que o software proprietário seja vinculado às bibliotecas da GPL?

Vamos examinar um cenário hipotético:

A empresa X grava um programa proprietário (A) que se vincula dinamicamente a uma biblioteca proprietária (B). A empresa Y deseja usar uma biblioteca de substituição (C) licenciada sob a GPL e, portanto, grava uma biblioteca de empacotamento (D) que se vincula dinamicamente a A e C e converte as chamadas de API usadas por A nas chamadas de API usadas por C.

Como D se destina a ser usado com C e usa as chamadas de API de C, é um trabalho derivado de C e, portanto, deve ser distribuído sob os termos da GPL *. Como resultado, o trabalho combinado de A e D também deve ser distribuído sob os termos da GPL, o que é impossível, uma vez que a empresa Y não possui o código fonte de A. Dito isto, desde que a empresa Y distribua D por si mesma , não há problema. No entanto, independentemente das ações da Empresa Y, a Empresa X não viola a GPL distribuindo A, mesmo sem B. A mera existência de D não significa que A é subitamente um trabalho derivado de C (a D) que deve ser licenciado sob a GPL também.

Agora, essa é a brecha: não há nada que impeça a Empresa X de escrever sua própria versão de D, distribuí-la separadamente de A e dizer aos usuários finais para usar D em vez de B ao executar A. Parece que uma empresa é capaz de projetar um programa proprietário para usar uma biblioteca GPL sem violar a GPL, desde que um módulo wrapper seja usado para isolar o programa proprietário da biblioteca GPL e esse módulo seja distribuído separadamente.

Estou correto no meu raciocínio? Isso é realmente uma brecha na GPL?

* D também é um trabalho derivado de A, mas, para os propósitos deste cenário, a Empresa X autorizou explicitamente a criação de D e permitiu que ela fosse licenciada sob a GPL.

IANAL, mas aqui está minha opinião sobre o que é permitido dentro dos limites da GPL:

• distribuir o trabalho combinado "A - B" em público: tudo bem, pode ser feito sob qualquer licença proprietária

• crie uma biblioteca wrapper D para C por Y: tudo bem, isso não implica que A precise ser colocado na GPL

• use o produto combinado "A - D - C" internamente por Y: também é bom, a GPL não exige a fonte aberta A desde que a combinação não seja distribuída ao público

• distribuir o trabalho combinado "A - D - C" em público: isso exigirá que A seja de código aberto e seja submetido à GPL (e não importa se X ou Y distribuíram essa combinação; além disso, se Y quiser fazer isso, eles exigiriam uma licença de distribuição para A de X, é claro)

A questão interessante agora é: a D&C pode ser distribuída separadamente como fonte aberta sob a GPL, A&B (ou apenas A sem B) pode ser distribuída sob uma licença proprietária, e o usuário final substitui B pela D&C sozinho?

Aqui, a modificação final para "AB", que torna A dependente das bibliotecas D & C, é feita pelo usuário final - após a distribuição . Portanto, alguém poderia argumentar que a modificação final é feita apenas internamente pelo usuário final. E parece que isso é realmente possível sem violar a GPL - e o que você obtém é uma combinação de "AC&D" em que A está sob licença proprietária e C&D sob a GPL.

Obviamente, um advogado ou juiz pode ter uma opinião diferente sobre isso. Para obter uma resposta final, acho que você deve esperar até que alguém a experimente e uma segunda a processe.

Eu acho que para a maioria dos sistemas, será difícil criar uma constelação sem projetar "A" desde o início, de forma que funcione perfeitamente com B ou C. E, nesse caso, pode-se suspeitar que A foi de alguma forma derivada de C.

EDIT: pensando um pouco sobre isso, uma situação semelhante me veio à mente: escrever e distribuir plug-ins licenciados GPL para aplicativos de código fechado. Vamos usar, por exemplo, o Photoshop. Não acho que alguém tente seriamente impor a Adobe ao Photoshop de código-fonte aberto apenas porque existem alguns plug-ins da GPL de terceiros. Aqui, nem mesmo uma "lib de wrapper" é necessária, pois existe uma interface bem definida. No entanto, isso mudaria a situação se o Photoshop incorporasse algumas de suas funções centrais a partir de um plug-in de terceiros da GPL? Eu acho que, nesse caso, pode ser realmente difícil decidir onde traçar a linha; nesse momento, o produto de código fechado é um trabalho "baseado" na lib da GPL.

EDIT2: Existem bibliotecas de licença dupla disponíveis, com uma licença GPL para uso não comercial e uma licença proprietária para uso comercial como esta, por exemplo. Portanto, sua "brecha" significaria desenvolver um produto com base nessa lib (usando a versão comercial, para que a GPL não se aplique ao seu produto), entregar seu produto como fonte fechada sem a lib ao público e deixar o final O usuário obtém e instala a versão GPLed sozinho. Nesse caso, acho que o fornecedor da lib terá uma boa chance de processá-lo com sucesso por violação de licença (se você não pagar pela lib, é claro). Vale a pena o aborrecimento? Provavelmente não. Especialmente no exemplo ao qual vinculei, você também teria que comprar a lib, pois o preço não depende de quantas vezes você vende seu produto, mas apenas quantos desenvolvedores estão usando a lib durante o desenvolvimento.

Por fim, devido a esses riscos legais, se eu pretender usar bibliotecas de código aberto em um produto de código fechado, evitaria as bibliotecas de GPL, se possível, e não tentaria fazer uso dessa "brecha". LGPL ou GPL com exceção de vinculação é muito mais seguro ou qualquer tipo de licença de sistema operacional não viral.

Um exemplo prático são os drivers gráficos proprietários para Linux que o usuário final precisa instalar por conta própria. Importante para o criador do driver proprietário, se o usuário final distribuir o trabalho combinado, isso cria uma obrigação legal para o usuário final (que ele possivelmente não pode cumprir), mas não para o criador do driver.

Outra resposta afirma que "como o programa depende da biblioteca, ainda é um trabalho derivado" - mas se o programa não funcionar de fato porque a biblioteca não existe, não é derivado.

Mas, no final, se você confiar em "brechas", considere que sua abordagem pode não ser a correta em primeiro lugar.

A vinculação define uma derivada pela GPL. Essa situação específica é para a qual a LGPL foi projetada para lidar: onde você deseja liberar a biblioteca como GPL, mas define o vínculo como o limite explícito da licença aplicada ou, alternativamente, onde você deseja vincular a algum código GPL, mas exige que o seu próprio o trabalho seja liberado sob uma licença que não seja da GPL.

No caso em que o usuário final fará a vinculação (crie seu próprio código a partir de fontes que não sejam da GPL, que podem se vincular a uma biblioteca GPL), o usuário final não criou efetivamente uma versão GPL do produto final, pois ele não tem permissão para alterar a licença da parte não GPL do projeto, porque ele não é o proprietário. Isso geralmente impede a distribuição pelo usuário final de qualquer forma, mas não proíbe o uso.

Dito isto, se um projeto exige que ele seja construído a partir do código-fonte e seja distribuído apenas dessa maneira, é irrelevante a licença da biblioteca vinculada, pois isso está totalmente fora do alcance dos desenvolvedores que não são da GPL. Ou seja, como você pode saber que sua distribuição somente de origem será construída no gcc contra o glibc VS construído em um compilador IBM em relação à sua libc, a menos que você especifique isso sob seus próprios termos de licenciamento? Isso rapidamente leva a um uso justo e a proibições contra condições legais inexequíveis (não que a fantasia não tenha sido escrita em lei em algumas ocasiões recentemente).

Não sou advogado, mas, pelo que sei, não está correto, pois o programa depende da biblioteca - ainda é um trabalho derivado. Da mesma maneira que um seqüencial é um trabalho derivativo. No mínimo, é baseado nas APIs definidas na biblioteca.