plug-ins proprietários para programas GPL: E sobre linguagens interpretadas?

votos
7

Estou desenvolvendo um aplicativo licenciado sob GPL, em Python e precisa saber se o GPL permite que o meu programa para usar plug-ins proprietários. Isto é o que o FSF tem a dizer sobre o assunto:

Se um programa lançado sob a GPL usa plug-ins, quais são os requisitos para as licenças de um plug-in?

Depende de como o programa invoca seus plug-ins. Se o programa usa fork e exec para invocar plug-ins, em seguida, os plug-ins são programas separados, então a licença para o programa principal não faz exigências para eles.

Se o programa vincula dinamicamente os plug-ins, e eles fazem chamadas de funções entre outras e compartilhar estruturas de dados, acreditamos que eles formam um único programa, que deve ser tratado como uma extensão de tanto o programa principal e os plug-ins. Isso significa que os plug-ins deve ser liberado sob a licença do software livre compatível com a GPL GPL ou, e que os termos da GPL devem ser seguidas quando esses plug-ins são distribuídos.

Se o programa vincula dinamicamente os plug-ins, mas a comunicação entre eles é limitado a invocar a função 'main' do plug-in com algumas opções e esperando por ele para voltar, que é um caso limite.

A distinção entre fork / exec e ligação dinâmica, além de ser tipo de artificial, não transitar para linguagens interpretadas: o que acontece com um plug-in Python / Perl / Ruby, que é carregado via importou execfile?

(Edit: Eu entendo por que a distinção entre fork / exec e ligação dinâmica, mas parece que alguém que queria cumprir a GPL, mas ir contra o espírito --Eu don't-- poderia usar apenas fork / exec e comunicação entre processos para fazer praticamente qualquer coisa).

A melhor solução seria adicionar uma exceção à minha licença para permitir explicitamente o uso de plugins proprietários, mas eu sou incapaz de fazê-lo desde que eu estou usando Qt / PyQt que é GPL.

Publicado 28/08/2008 em 01:26
fonte usuário
Em outras línguas...                            


3 respostas

votos
4

ele distinção entre fork / exec e ligação dinâmica, além de ser tipo de artificial,

Eu não acho que é artificial em tudo. Basicamente, eles estão apenas fazendo a divisão com base no nível de integração. Se o programa tiver "plugins" que são essencialmente fogo e esquecer sem integração nível API, então o trabalho resultante é improvável de ser considerada uma obra derivada. De um modo geral um plugin que é meramente bifurcada / exec'ed caberia a esses critérios, embora possa haver casos em que isso não acontece. Este caso se aplica especialmente se o código "plug-in" iria trabalhar de forma independente do seu código também.

Se, por outro lado, o código é totalmente dependente da obra GPL'ed, como APIs extensivamente chamada, ou a integração estrutura de dados apertado, então as coisas são mais propensos a ser considerado um trabalho derivado. Ou seja, o "plug-in" não pode existir por si só, sem o produto GPL, e um produto com este plugin instalado é essencialmente uma obra derivada do produto GPL.

Então, para torná-lo um pouco mais claro, os mesmos princípios poderia aplicar-se ao seu código interpretado. Se o código interpretado depende muito de suas APIs (ou vice-versa), então ele seria considerado um trabalho derivado. Se é apenas um script que executa por conta própria com muito pouca integração, então ele não pode.

Isso faz mais sentido?

Respondeu 28/08/2008 em 01:33
fonte usuário

votos
1

Quanta informação você está compartilhando entre os Plugins e o programa principal? Se você está fazendo nada mais do que apenas executá-los e esperar pelos resultados (compartilhando há dados entre o programa eo plug-in no processo), então você poderia provavelmente fugir com eles, sendo proprietário, caso contrário, eles provavelmente teriam de ser GPL' d.

Respondeu 28/08/2008 em 01:33
fonte usuário

votos
1

@ Daniel

A distinção entre fork / exec e ligação dinâmica, além de ser tipo de artificial, não transitar para linguagens interpretadas: o que acontece com um plug-in Python / Perl / Ruby, que é carregado via importação ou execfile?

Eu não tenho certeza que a distinção é artificial. Depois de uma carga dinâmica do código do plugin compartilha um contexto de execução com o código GPL. Depois de um fork / exec isso não acontece.

Em anycase eu acho que importing faz com que o novo código seja executado no mesmo contexto de execução como o bit GPL, e você deve tratá-lo como o caso de ligação dinâmica. Não?

Respondeu 28/08/2008 em 01:32
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more