Existe uma lacuna na GPL que permite que software proprietário seja vinculado a bibliotecas GPL?

15

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 quer usar uma biblioteca de substituição (C) licenciada sob a GPL e, portanto, grava uma biblioteca de wrapper (D) que vincula dinamicamente a A e C e traduz as chamadas de API usadas por A para as chamadas de API usadas por C. / p>

Como D é para ser usado com C e usa as chamadas API de C, é um trabalho derivado de C e deve, portanto, 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, dado que a Empresa Y não possui o código fonte para 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 (através de D) que deve ser licenciado sob a GPL também.

Agora, esta é a lacuna: não há nada que impeça a Empresa X de escrever sua própria versão de D, distribuindo-a separadamente de A e dizendo aos usuários finais que usem D ao invés 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? Essa é uma brecha real 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 ele fosse licenciado sob a GPL.

    
por Michael Kourlas 26.05.2013 / 07:21
fonte

4 respostas

9

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

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

  • crie um wrapper lib D para C por Y: bom, isso não implica que A tenha que ser colocado sob GPL

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

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

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

Aqui, a modificação final para "A-B", que torna A dependente de libs D & C é feito pelo usuário final - após a distribuição . Assim, pode-se 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 trabalho de "A-C & D" onde A está sob licença proprietária e C & D sob GPL.

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

Eu acho que para a maioria dos sistemas, será difícil criar uma constelação como esta sem projetar "A" desde o começo de forma que funcione perfeitamente com B ou C. E, nesse caso, pode-se chegar ao suspeita de que A foi de alguma forma derivado de C.

EDIT: pensando um pouco sobre isso, uma situação semelhante veio em minha mente: escrever e distribuir plugins GPL licenciados para aplicativos de código fechado. Vamos pegar, por exemplo, o Photoshop. Eu não acho que alguém seriamente tentar impor a Adobe ao Photoshop de código aberto apenas porque existem alguns plugins GPL de fornecedores de terceiros. Aqui, nem mesmo um "wrapper lib" é necessário, pois existe uma interface bem definida. No entanto, mudaria a situação se o Photoshop incorporasse algumas de suas funções centrais de um plug-in de terceiros GPL? Eu acho que para tal caso, pode tornar-se realmente difícil decidir onde traçar a linha, no ponto em que o produto de código fechado é um trabalho "baseado na" biblioteca GPL.

EDIT2: Há licenças 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 baseado em tal lib (usando a versão comercial, portanto a GPL não se aplica ao seu produto), entregar seu produto como fonte fechada sem o lib ao público e deixar que o fim usuário obter e instalar a versão GPL por si mesmo. Para tal caso, eu acho que o fornecedor do lib terá uma boa chance de processá-lo com sucesso por violação de licença (se você não pagar por sua lib, é claro). Vale a pena o incômodo? Provavelmente não. Especialmente no exemplo ao qual eu fiz o link, você teria que comprar o lib, pois o preço não depende da freqüência com que você vende seu produto, mas apenas de quantos desenvolvedores estão usando o lib durante o desenvolvimento.

Finalmente, por causa desses riscos legais, se eu pretendo usar bibliotecas open-source dentro de um produto de código fechado, eu evitaria bibliotecas GPL se possível, e não tentaria usar essa "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.

    
por 26.05.2013 / 16:05
fonte
4

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 distribui o trabalho combinado, isso cria uma obrigação legal para o usuário final (que eles possivelmente não podem cumprir), mas não o criador do driver.

Outra resposta alega "desde que o programa depende da biblioteca ainda é um trabalho derivado" - mas se o programa não funciona realmente porque a biblioteca não está lá, então não é derivativo.

Mas, no final, se você confiar em "lacunas", então você deve considerar que sua abordagem pode não ser a correta em primeiro lugar.

    
por 09.06.2017 / 21:16
fonte
1

Vinculação define uma derivada pela GPL. Essa situação específica é o que a LGPL foi projetada para manipular: onde você deseja liberar a biblioteca como GPL, mas definir vinculação como o limite explícito da licença aplicada ou alternadamente, onde deseja vincular-se a algum código GPL, mas exige que você trabalho seja liberado sob uma licença não-GPL.

No caso em que o usuário final fará a ligação (construa seu próprio código a partir de fontes não-GPL que podem se ligar a uma biblioteca GPL) o usuário final não foi efetivamente criado uma versão GPL de qualquer produto final, já que ele não tem permissão para alterar a licença da parte não-GPL do projeto porque ele não é o dono dela. Isso geralmente impede a distribuição pelo usuário final em qualquer forma, mas não proibiria o uso.

Dito isso, se um projeto exigir que ele seja construído a partir da fonte e seja distribuído apenas dessa maneira, é irrelevante qual licença a biblioteca vinculada está, já que isso está totalmente fora das mãos do desenvolvedor não-GPL. Isto é, como você pode saber que sua distribuição somente de fonte será construída no gcc contra o glibc VS construído em um compilador da IBM contra sua libc, a menos que você especifique isso sob seus próprios termos de licenciamento? Isso rapidamente se transforma em uso justo e 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).

    
por 25.03.2014 / 23:02
fonte
0

Eu não sou um advogado, mas até onde posso dizer, você não está correto, já que o programa depende da biblioteca - ainda é um trabalho derivado. Da mesma forma que um sequal é um trabalho derivado. No mínimo, é baseado nas APIs definidas na biblioteca.

    
por 26.05.2013 / 07:35
fonte

Tags