Esta é uma tradução da página original em Inglês.

A LGPL e o Java

por David Turner

Este artigo foi escrito em novembro de 2004, quando a LGPLv2.1 era a versão mais atual da licença. Desde então, a LGPLv3 foi publicada. Os principais pontos deste artigo permanecem verdadeiros sobre a LGPLv3, mas alguns dos detalhes, como números de seção, mudaram.

Sempre foi a posição da FSF que vincular dinamicamente aplicativos a bibliotecas cria um único trabalho derivado do código da biblioteca e do código do aplicativo. A GPL exige que todas as obras derivadas sejam licenciadas como um todo sob os termos da GPL, um efeito que pode ser descrito como “hereditário”. Portanto, se um aplicativo vincula-se a uma biblioteca licenciada sob a GPL, o aplicativo também deve ser licenciado sob a GPL. Por outro lado, as bibliotecas licenciadas sob a Licença Pública Geral Menor GNU (LGPL) podem estar vinculadas a aplicativos privativos.

Em julho de 2003, o Slashdot publicou uma reportagem alegando que eu havia alegado que a LGPL não funcionava como pretendido no caso de Java. Esta história foi baseada em um mal-entendido de uma resposta a uma pergunta enviada para licensing@gnu.org, e muitas tentativas de esclarecer a questão na história do Slashdot não foram transmitidas. Eu recebi inúmeras perguntas sobre a história desde, através de licensing@gnu.org e e-mail pessoal.

A posição da FSF permaneceu constante durante todo o tempo: a LGPL funciona como pretendido com todas as linguagens de programação conhecidas, incluindo Java. Aplicativos que possuem vínculos com bibliotecas LGPL não precisam ser lançados sob a LGPL. Os aplicativos precisam seguir apenas os requisitos da seção 6 da LGPL: permitir que novas versões da biblioteca sejam vinculadas ao aplicativo; e permitir engenharia reversa para depurar isso.

O arranjo típico para Java é que cada biblioteca utilizada por um aplicativo é distribuída como um arquivo JAR (Java Archive) separado. Aplicativos usam a funcionalidade “import” do Java para acessar classes dessas bibliotecas. Quando o aplicativo é compilado, as assinaturas de função são verificadas na biblioteca, criando um vínculo. O aplicativo é então geralmente um trabalho derivado da biblioteca. Portanto, o detentor dos direitos autorais da biblioteca deve autorizar a distribuição do trabalho. A LGPL permite essa distribuição.

Se você distribuir um aplicativo Java que importe bibliotecas LGPL, será fácil cumprir a LGPL. A licença do seu aplicativo precisa permitir que os usuários modifiquem a biblioteca e faça engenharia reversa do 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. Naturalmente, algumas alterações que os usuários podem fazer na biblioteca podem quebrar a interface, tornando a biblioteca incapaz de trabalhar 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.

Quando você distribui a biblioteca com seu aplicativo (ou por conta própria), é necessário incluir o código-fonte para a biblioteca. Mas, se seu aplicativo exigir que os usuários obtenham a biblioteca por conta própria, você não precisará fornecer o código-fonte para a biblioteca.

A única diferença entre Java e C da perspectiva da LGPL é que Java é uma linguagem orientada a objetos, com suporte a herança. A LGPL não contém provisões especiais para herança, porque nenhuma é necessária. A herança cria trabalhos derivados da mesma forma que a vinculação tradicional, e a LGPL permite esse tipo de trabalho derivado da mesma forma que permite chamadas de função comuns.