LGPL ?

Será que só eu fico receoso de usar código LGPL em softwares para fins comerciais?

Há várias bibliotecas sob LGPL muito interessantes para desenvolver aplicativos úteis, não-triviais e atraentes, como JFreeChart, JasperReports e SwingX.

O problema é aderir estritamente à licença. Eu não sou - nem tenho a ajuda de um - advogado.

Alguns Termos e Condições para Nota

LGPL faz diferenciação entre trabalho derivado de uma biblioteca e trabalho que usa uma biblioteca. Um software que é ligado (linked to) a uma biblioteca gera um executável que contém porções dessa biblioteca - é, portanto, derivado da biblioteca.

Esse trabalho combinado pode ser redistribuído sob qualquer termo, mas deve permitir que o usuário use outras versões da biblioteca. O usuário deve ter acesso ao código-fonte da biblioteca e tem o direito de fazer modificações nesse código. Por exemplo, caso o usuário desenvolva sua própria versão da biblioteca, ele deve poder ligar o software à nova biblioteca.

Essa ligação pode ser feita através do mecanismo de biblioteca compartilhada (shared-library), ou estaticamente (statically-linked library). No último caso, o código-fonte que usa a biblioteca deve ser disponibilizado.

Isso tudo para garantir que o copyleft não seja aplicado aos softwares que usem ou sejam derivados da biblioteca, mas seja aplicado à biblioteca LGPL.

Herança

O uso de herança para classes de bibliotecas LGPL é motivo de preocupação freqüente, questionando a viabilidade do uso dessas bibliotecas para programação orientada a objetos (OO).

Segundo o artigo The LGPL and Java, de David Tuner, essas preocupações são infudadas, pois

a LGPL não contém condições especiais para [o mecanismo de] herança, porque nada é necessário. Herança cria trabalho derivado da mesma forma que a ligação (link) tradicional, e a LGPL permite esse tipo de trabalho derivado da mesma forma que permite chamadas de funções.

Referências:

• Wikipedia
• Wikipedia (inglês)
• Open Source Initiative
• The LGPL and Java