Estou planejando desenvolver um software comercial usando um software LGPL.
No software LGPL que estou usando algumas funções em uma classe não são totalmente implementadas. Desejo modificar o código LGPL para que a classe e as funções não implementadas sejam visíveis fora da dll adicionando dllexport na frente da classe e adicionando a palavra-chave virtual na frente da função.
Então, planejo implementar essas funções no meu software proprietário. Estou pronto para distribuir o código LGPL modificado, mas não o software proprietário que implementa as funções da maneira que desejo.
Isso viola os termos e condições da LGPL?
Respostas:
Essa é uma pergunta complexa, mas acredito que o que você propõe não é permitido.
Você está sugerindo adicionar ganchos à biblioteca para facilitar a subclasse da biblioteca e, portanto, pelo menos. contornar o espírito da LGPL.
O problema é que, se você subclassificar uma classe que está sujeita à licença LGPL em seu próprio código, seu trabalho se tornará um trabalho baseado na biblioteca , em vez de um trabalho que use a biblioteca, o que significa que seu código é um derivado trabalho coberto pela seção 2 ( LGPL v2.1 ) em vez de um trabalho coberto pela seção 6 ( LGPL v2.1 ). Ou seja, torna - se sujeito à LGPL !
Eu acho que Stephen Colebourne fornece um bom resumo sobre o javalobby.
Eu não sou um grande fã de conversa fiada com as sugestões de seus advogados , mas , neste caso , acho que valeria a pena fazê-lo se você planeja continuar com isso, caso contrário, você pode estar recebendo uma carta desagradável do Software Livre Equipe jurídica da Fundação .
Como alternativa, você pode solicitar diretamente à FSF . Na página de contato deles :
Aliás, na pergunta relacionada Reflection e LGPL , gbjbaanb responde com a perspectiva LGPL 3.0 .
fonte
Padrão Não sou um aviso de isenção de advogado.
A LGPL exige que as modificações no código-fonte da biblioteca sejam distribuídas a qualquer pessoa que usou seu código. Ele não exige que o seu código, que usa a biblioteca, ser open-source e liberado sob a mesma licença.
Wikipedia para uma descrição mais detalhada, mas não para advogados, da LGPL, incluindo uma seção sobre herança de classe .
fonte
"Quero modificar o código LGPL ..." diz o suficiente para você liberar qualquer código modificado. Em seguida, estender se o código modificado é ou não um trabalho derivado está em disputa e, nesse caso, fica sujeito à LGPL.
O que parece que você está tentando fazer é contornar a LGPL, que nesse caso com essas técnicas você não pode.
Mas se o que você está tentando fazer é contornar a LGPL, entrarei em contato com a FSF, conforme recomendado por Mark Booth .
fonte
work based onporque eles estão fazendo alterações na LGPL para expor o código privado anteriormente.Meu palpite: (mas IANAL) você deve liberar como código aberto biblioteca modificada como código LGPL e , em seguida, solte-o em um programa comercial. Isso funcionaria. Efetivamente, você acabaria tendo uma bifurcação de código aberto da biblioteca e, então, estará vendendo um front end para ela.
Mas, como muitos outros disseram com razão, pergunte à FSF : é um cenário patológico intrigante que você tem lá; eles podem estar se perguntando tanto quanto você, se é aplicável ou não. (ou pelo menos se preocupe com isso o suficiente para publicar uma entrada de perguntas frequentes sobre o tópico)
fonte
https://www.gnu.org/licenses/lgpl-java.html
Em resumo, não há problema com a herança, desde que você não altere o código da biblioteca em si, mas mesmo se você o alterar, será necessário liberar apenas o código modificado da biblioteca, não o código do aplicativo.
fonte