A LGPL me permite fazer isso?

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?

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 :

Para perguntas sobre licenciamento de software livre e direitos autorais

Consulte nossas Perguntas frequentes sobre licenciamento , a lista de licenças , informações gerais sobre copyleft e páginas relacionadas . Se houver dúvidas, envie um e-mail para <licensing@gnu.org>.

Aliás, na pergunta relacionada Reflection e LGPL , gbjbaanb responde com a perspectiva LGPL 3.0 .

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 .

"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.

Se for um trabalho derivado, os termos do programa deverão permitir "modificações para uso do próprio cliente e engenharia reversa para depuração de tais modificações". Se um trabalho que usa um programa LGPL é um trabalho derivado ou não é uma questão legal.

Mas se o que você está tentando fazer é contornar a LGPL, entrarei em contato com a FSF, conforme recomendado por Mark Booth .

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)

https://www.gnu.org/licenses/lgpl-java.html

Se você distribuir um aplicativo Java que importe as bibliotecas LGPL, é fácil estar em conformidade com a LGPL. A licença do seu aplicativo precisa permitir que os usuários modifiquem a biblioteca e faça engenharia reversa do seu código para depurar essas modificações. Isso não significa que você precise fornecer o código-fonte ou quaisquer detalhes sobre os componentes internos do seu aplicativo. Obviamente, algumas alterações que os usuários podem fazer na biblioteca podem interromper a interface, tornando a biblioteca incapaz de funcionar com seu aplicativo. Você não precisa se preocupar com isso - as pessoas que modificam a biblioteca são responsáveis ​​por fazê-la funcionar.

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.