Posso vincular a uma biblioteca GPL a partir de um aplicativo de código fechado?

Ok, antes que todo mundo grite sobre perguntas duplicadas, sim, eu já vi várias perguntas como essa aqui. Mas ninguém responde à pergunta.

Se eu vincular uma biblioteca GPL-ed sem modificar essa biblioteca, preciso liberar meu código-fonte?

De acordo com esta pergunta , a resposta é sim!

Mas esta resposta não é satisfatória para mim. A resposta basicamente diz que não posso usar o código GPL de forma alguma sem tornar meu código de código aberto.

Mas se o anterior for verdadeiro, isso indicaria que nenhuma pessoa ou organização jamais poderia lançar qualquer software proprietário no Linux. O que deve estar errado. Simplesmente porque, para que qualquer aplicativo faça algo útil, abra arquivos, grave no console, crie conexões TCP, o aplicativo deve estar vinculado ao libcqual é editado pela GPL.

Portanto, minha pergunta é a seguinte: se a GPL declara, como todas as respostas anteriores do site dizem que um programa vinculado a outro programa da GPL deve ser a própria GPL, como é possível criar / liberar / vender qualquer aplicativo proprietário em tudo o que é executado no Linux? Como eu descrevi acima, esse aplicativo deve ser apreciado no código GPL apenas para ser executado no Linux.

Um exemplo mais prático diz que eu vinculo a uma biblioteca compartilhada que é GPL-ed em um aplicativo não-GPL, isso forçaria o aplicativo não-GPL a se tornar GPL-ed? Mais especificamente, se eu usar uma biblioteca GPL sem modificá-la e depois distribuí-la como um .soou .dll, isso exigiria que meu aplicativo fosse de código aberto?

gpl linking

— john-charles
fonte

Você continua fazendo a mesma pergunta na esperança de uma resposta diferente. Você não pode usar a GPL em software não compatível com a GPL. Simplesmente morto.

— Andrew T Finnell

Ele realmente? Caramba. A resposta é simples; por que você não entra em contato com os autores do programa GPL e pergunta se eles se importam? Se eles dizem que está tudo bem, isso é ótimo! Se eles se opuserem, tentar reforçá-los com detalhes legais o tornará muito impopular, não importa o quão "certo" você se sinta.

— James

@ James: Se eles escolheram GPL, é bastante forte declaração que fazer mente. As pessoas que não se importam escolhem o MIT, o BSD ou o LGPL. É muito raro ver uma biblioteca com a GPL completa. Quando você o faz, pode ter quase certeza de que foi intencional.

— Jan Hudec

@ Jan Talvez, depende do aplicativo e do uso pretendido por john-charles. Mas acho estranho como a JC está abordando isso. O jc está apenas tentando obter a resposta que deseja? Há muitas perguntas neste site que podem ser resolvidas com um "apenas fale com eles, pelo amor de Deus". :-)

— James

@JanHudec: Eu concordo. Argumentei para liberar parte do IP de nossa empresa na forma de uma biblioteca GPL, pois isso seria essencialmente inútil para nossos concorrentes e ainda muito útil para nossa comunidade.

— MSalters

Respostas:

Se você vincular a uma biblioteca GPL, criou um trabalho derivado e seu código deverá ser GPL - isso é diferente do código L GPL, que permite especificamente a vinculação dinâmica de códigos licenciados de maneira diferente. As bibliotecas do sistema, incluindo libc, são todas LGPL.

Há também uma isenção especial para os cabeçalhos do kernel Linux e libgcc (a biblioteca chamada implicitamente pelo compilador).

— Martin Beckett
fonte

Nenhuma libc é LGPL - você tem permissão para vincular a programas LGPL. Há também uma isenção geral para as chamadas kernel / sistema por isso não há argumento abotu o que é um sistema vs chamada de biblioteca

— Martin Beckett

LGPL não é uma licença nova, foi lançada pela primeira vez em 1991. libc sempre foi LGPL.

— FigBug

@ john-charles - é por isso que a LGPL foi inventada em 1991 com gplv2. O AsLinux (e outros kernels do FOSS) tornou-se popular - e é por isso que foi originalmente chamado de Library-GPL - havia um medo de que houvesse uma profusão de libc por todos os fornecedores de compiladores se os aplicativos comerciais não pudessem usar o gcc.

— Martin Beckett

@MartinBeckett Esta é a opinião da FSF (você não pode vincular ao código GPLd se não licenciar o seu sob a GPL), mas não é incontestável. Não houve nenhum processo importante (que eu saiba, se estiver errado, por favor, corrija-me) para confirmar a opinião da FSF sobre a vinculação.

— K.Steff

@ john-charles - sim, toda lei comum é testada nos tribunais, mas há muita jurisprudência sobre direitos autorais. Se eu afirmar que minha cópia não modificada de um DVD do Batman não é um trabalho derivado e, portanto, posso vender quantas eu quiser - é improvável que a MPAA concorde! O GNU usos copyleft de direitos autorais para fazer cumprir um contrato de licença de uma forma bastante inteligente - uma das razões que nunca foi testado no tribunal é que toda a gente tem sempre resolvido

— Martin Beckett

No caso geral, você está certo ao não conseguir vincular a uma biblioteca GPL, distribuir seu código e depois não liberá-lo como GPL.

No entanto, existe a Exceção de Biblioteca do Sistema, que é como as pessoas se vinculam às bibliotecas do Linux e ainda lançam seu produto sob licenças não GPL.

Outra exceção é quando as duas licenças são compatíveis entre si. Confira a página de licença compatível com a FSF para ler mais.

Finalmente, os autores da biblioteca GPL'd podem criar exceções específicas, como para uso não comercial ou hobby.

Infelizmente, existem muitas potencialidades para se ter uma regra rígida e rápida. Sem mais detalhes em sua pergunta, sua resposta é "provavelmente não pode, mas talvez você possa".

O SLE também responde a uma pergunta de um programa de ser uma obra derivada do compilador uma vez que contém um analisador gerado pelo compilador

— Martin Beckett

Não, o SLE permite o desenvolvimento de código GPL usando ferramentas não livres e tempo de execução padrão, por exemplo, Visual Studio. Ele nunca permite vincular aplicativos não livres à biblioteca GPL.

— Jan Hudec

A saída de um programa GPL não é coberta pela GPL. Veja gnu.org/licenses/gpl-faq.html#GPLOutput

— Maximus Minimus

-1

A resposta curta é que ninguém realmente sabe. (Esta discussão é sobre GPL, não LGPL.)

A GPL possui uma linguagem vaga sobre "Obras Derivadas", que diferentes pessoas interpretam de maneiras diferentes. Parece haver consenso de que a vinculação estática viola, mas a chamada via interrupção do sistema (por exemplo, para o Linux Kernel) não. O último baseia-se principalmente no fato de empresas como a Oracle enviarem Linux e não terem sido processadas - isso não está claro na licença.

A vinculação dinâmica não é clara, provavelmente 70/30 diz que viola. Chamar um programa usando pipes ou chamadas de procedimento remoto, provavelmente 30/70 não viola, mesmo que isso seja essencialmente a mesma coisa. Chamar via COM, ou usando um Java Jar, não é totalmente claro.

Basicamente, se houver alguma dúvida e você não gostar de advogados, fique longe da GPL.

— Tuntable
fonte

A GPL não é realmente tão vaga, e há uma jurisprudência bem discutida em torno da questão do que é e não é um trabalho derivado. A diferença entre a interface syscall do Linux e a libc é que a primeira é necessária para criar um software de trabalho (que foi afirmado como uma exceção aos direitos autorais) enquanto a segunda não é (você pode implementar sua própria). Não tem nada a ver com a forma como as operações são invocadas, o que não tem relevância legal. ANAL, isso não é aconselhamento jurídico.

— Jules

"70/30 diz que viola" e "30/70 não viola" - é intencional que a proporção de violar / não viole seja a mesma? "mesmo que isso seja essencialmente a mesma coisa" sugere que ele deveria ser diferente.

— Mateusz Konieczny 29/09