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

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?

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 .

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.

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.