Como a regra de vinculação estática versus dinâmica da GPL se aplica a idiomas interpretados?


19

No meu entendimento, a GPL proíbe vinculação estática de código não GPL para código GPL, mas permite vinculação dinâmica de código não GPL para código GPL. Então, qual é o código em questão que não está vinculado porque o código está escrito em uma linguagem interpretada (por exemplo, Perl)?

Parece ser muito fácil explorar a regra se ela for considerada vinculação dinâmica, mas, por outro lado, também pareceria impossível fazer referência legal do código GPL do código não-GPL se for considerado estático! Linguagens compiladas pelo menos têm uma distinção entre vinculação estática e dinâmica, mas quando toda "vinculação" está apenas executando scripts, é impossível dizer qual é a intenção sem uma licença explícita!

Ou meu entendimento desse problema está incorreto, tornando a questão discutível? Também ouvi falar de uma "exceção de caminho de classe" que envolve vinculação dinâmica; isso não faz parte da GPL, mas algo que pode ser adicionado a ela; portanto, a vinculação dinâmica só é permitida quando a licença inclui essa exceção?



2
! @delnan LGPL = gpl
Johann

Respostas:


16

Quanto a perguntas específicas sobre idiomas interpretados, as perguntas frequentes da GPL são muito claras :

O programa interpretado, para o intérprete, é apenas dados; uma licença de software livre como a GPL, baseada na lei de direitos autorais, não pode limitar em quais dados você usa o intérprete. Você pode executá-lo em qualquer dado (programa interpretado), da maneira que desejar, e não há requisitos para licenciar esses dados para ninguém.

Quanto à pergunta genérica sobre vínculo dinâmico vs estático. Primeiro de tudo, a visão da FSF e Stallman é que não importa se o vínculo é estático ou dinâmico, a GPL infecta de qualquer maneira. Do FAQ da FSF GPL:

Se o programa vincular dinamicamente plug-ins e eles fizerem chamadas de função entre si e compartilharem estruturas de dados, acreditamos que eles formarão um único programa, que deve ser tratado como uma extensão do programa principal e dos plug-ins. Isso significa que a combinação do plug-in coberto pela GPL com o programa principal não livre violaria a GPL.

e

Vincular [nome do seu programa] estaticamente ou dinamicamente a outros módulos está fazendo um trabalho combinado com base no [nome do seu programa]. Assim, os termos e condições da Licença Pública Geral GNU abrangem toda a combinação

No entanto, isso é questionável do ponto de vista jurídico. No único caso que realmente foi a tribunal por vinculação dinâmica - Galoob x Nintendo - o Tribunal de Apelações decidiu que o trabalho derivado "deve incorporar uma parte do trabalho protegido por direitos autorais de alguma forma" . O que não é o caso da vinculação dinâmica.

De qualquer forma, independentemente de a vinculação dinâmica realmente infectar ou não, existe uma solução alternativa. É usado, por exemplo, pela Nvidia para fornecer drivers binários para Linux. Você cria o wrapper (L) GPL, mas como autor, você pode adicionar uma exceção especial ao link com código-fonte específico. Vide FAQ da FSF GPL .


Uma das naturezas de um trabalho derivado é que não é possível separar claramente o trabalho original do detentor dos direitos autorais. Se Bob Foo()está estaticamente vinculado a ligar para Joe Bar(), a qual detentor dos direitos autorais a CALLinstrução entre eles deve ser atribuída? Essa interação seria suficiente para constituir um "trabalho derivado". Se, no entanto, o trabalho de Joe permanecer inteiramente em um arquivo e o de Bob em outro, a simples aparência desses arquivos em diretórios diferentes no mesmo disco constituirá agregação, não derivação.
Supercat 6/12

2
@ thepaul: já existe uma precedência legal que afirma que pelo menos uma parte do trabalho protegido por direitos autorais deve ser incluída em um trabalho para constituir um trabalho derivado. As crenças de Stallman costumam ter muito pouco fundamento no direito real real.
precisa saber é

1
@ thepaul: por um lado, você tem uma prática jurídica usada por uma empresa de 9 bilhões de dólares, por outras queixas de quem gosta de usar chapéu de papel alumínio. Você alega que o último é mais confiável e tem todo o direito de acreditar nisso.
vartec

1
Você citou que a parte errada das perguntas frequentes da GPL é muito clara . A parte que você cita é sobre Se um intérprete de linguagem de programação é lançado sob a GPL, isso significa que os programas escritos para serem interpretados por ele devem estar sob licenças compatíveis com GPL? ! Daí o intérprete [licenciado pela GPL] . A parte relevante são os dois últimos parágrafos: [...] Outro caso semelhante e muito comum é fornecer às bibliotecas o intérprete que elas mesmas são interpretadas. Por exemplo, o Perl vem com muitos módulos [...] do Perl
Chris Wesseling

1
«O programa interpretado, para o intérprete, são apenas dados; uma licença de software livre como a GPL, baseada na lei de direitos autorais, não pode limitar em quais dados você usa o intérprete. Você pode executá-lo com qualquer dado (programa interpretado), da maneira que desejar, e não há requisitos para licenciar esses dados para ninguém. »Trata-se da execução de programas em qualquer licença, mesmo que seja um intérprete da GPL, certo? O que não cobre o tópico do uso de um plug-in não-livre em um programa GPL em uma linguagem interpretada.
tuxayo

4

Nota: esta é uma questão legal. Programmers.SE não é um fórum jurídico, é um fórum de programação. Embora as pessoas aqui saibam um pouco sobre programação, elas não sabem nada sobre a lei. Se você quiser fazer uma pergunta legal, faça isso em um fórum jurídico, onde existem pessoas que realmente sabem algo sobre o assunto.


A GPL não diz nada sobre links estáticos ou dinâmicos. Ele nem sequer disse nada sobre a vinculação em tudo . Todo advogado ou juiz com quem falei diz que a questão da ligação estática e dinâmica é completamente irrelevante.

Direitos autorais são sobre criatividade. A vinculação estática versus dinâmica é um detalhe técnico da implementação. Se algo está vinculado estaticamente ou dinamicamente ou não é um ato criativo, não é possível alterar o status dos direitos autorais de uma obra.

Na sua pergunta, você fala sobre "linguagens interpretadas". Mas esse termo não faz sentido: não existe linguagem interpretada. Uma linguagem é um conjunto abstrato de regras e restrições matemáticas. Um idioma não é interpretado ou compilado. Uma linguagem simplesmente é . O termo "linguagem interpretada" não é apenas errado , é não-sensorial . Se o inglês fosse um idioma digitado, seria um erro de digitação.

Interpretação e compilação são características do intérprete ou compilador (duh!), Não da linguagem. Todo idioma pode ser implementado com um intérprete e todo idioma pode ser implementado com um compilador. A maioria dos idiomas possui ambos. A maioria das implementações de linguagem moderna combinam as duas em um único mecanismo de execução.

A Implementação do Rubinius Ruby, por exemplo, contém um compilador estático antecipado que compila o código Ruby para o código de bytes do Rubinius, um intérprete que interpreta o código de bytes do Rubinius e um compilador dinâmico que compila o código de bytes do Rubinius para o LLVM IR, que a infraestrutura LLVM, por sua vez, compila no código de máquina nativo. A Implementação do MacRuby Ruby não contém um intérprete, ele compila o código Ruby diretamente para o LLVM IR e depois para o código da máquina nativo.

Por outro lado, existem intérpretes para C ou C ++.

Tudo isso são apenas detalhes técnicos. É completamente irrelevante para os direitos autorais.

Simplesmente não faz sentido que alguém viole ou não os direitos autorais de outra pessoa, dependendo de uma terceira pessoa optar por executar o programa com um intérprete ou compilá-lo primeiro.

A questão é se um trabalho é derivado ou não de outro trabalho. Ele pode ser vinculado dinamicamente e ainda ser derivado, e pode ser vinculado estaticamente e nem sequer derivar.


E as linguagens interpretadas de "código intermediário"? Um dos princípios por trás da GPL é que qualquer pessoa deve ser capaz de adaptar o programa a qualquer máquina razoável que possua as mesmas ferramentas de linguagem disponíveis como o original. Se alguém libera o código-fonte para um intérprete de código intermediário, juntamente com um monte de código de forma intermediária que ele pode executar, quais seriam as regras para liberar informações relacionadas a esse blob de código intermediário? Diferentemente dos executáveis ​​compilados, específicos da máquina, o blob de código intermediário seria totalmente portátil.
Supercat 6/12

Desculpe; Eu ia perguntar no stackoverflow.com e sugeriu que eu perguntasse aqui quando usei a tag "gpl"! Esse tipo de discussão também é banido aqui? exec ("advogado killall -9"); : D
ekolis

E sim, concordo que não faz sentido que um detalhe da implementação não tenha efeito sobre o status legal da reutilização; Eu apenas pensei que havia tal distinção e estava pedindo esclarecimentos!
ekolis

2
@ekolis: não é proibido, por si só. É só que não é uma boa ideia fazer perguntas legais de pessoas que não sabem nada sobre questões legais (como programadores, por exemplo), quando há pessoas que não sabem sobre questões legais (aka advogados) você poderia pedir em seu lugar. Não tenho nada contra advogados, muito pelo contrário. Mas eu não pediria um conselho de algoritmo, nem pediria a um programador aconselhamento jurídico.
Jörg W Mittag

IANAL: Pode ser um detalhe técnico, mas ainda faz uma grande diferença, porque altera o que está sendo distribuído de uma maneira legalmente significativa. Com o link estático, você cria um trabalho combinado que, de acordo com as regras da GPL, não pode ser distribuído fora da GPL. Com a vinculação dinâmica, você também pode fazer isso, por exemplo, se você empacotar as bibliotecas com o seu software em um arquivo ZIP. Mas com a vinculação dinâmica, você pode distribuí-lo sem as bibliotecas, e é 100% o seu trabalho, mesmo que não funcione por si só. E você ainda pode, é claro, oferecer as bibliotecas sob a GPL.
flarn2006 8/09

0

Não faço ideia de quanta verdade existe nisso, e IANAL, etc .; mas, na minha interpretação, o importante é saber se a biblioteca à qual você se vincula está de alguma forma incluída no "binário" (onde "binário", no caso de linguagens de programação dinâmicas, é apenas o código-fonte conforme distribuído; o que penso da definição de "binário" da FSF neste contexto).

Portanto, se você referenciar bibliotecas do seu código sem incluí-las em sua distribuição, consideraria isso o equivalente a "vínculo dinâmico", enquanto que você agrupa as bibliotecas com seu produto ou copia e cola partes da biblioteca em seu próprio código, o cenário "vinculação estática" se aplicaria. Isso, pelo menos, está dentro do espírito da GPL: você pode usar livremente (executar, inspecionar, referenciar) o software da GPL sem restrições, mas assim que derivar dele (vinculando ou copiando partes dele no seu próprio produto distribuível), ele se torna viral, e seu software também deve ter a GPL.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.