Posso usar os plugins de licença Apache Software License, Versão 2.0 e GNU LGPL 3 no meu aplicativo da web comercial?

Eu tenho dois plug-ins. Um possui a licença GNU LGPL 3 e o outro a Apache Software License, versão 2.0. Posso usá-los no meu aplicativo comercial? E se sim, que precauções devo tomar?

licensing lgpl apache-license

— umairaslam
fonte

Lembre-se de que NUNCA deve seguir os conselhos legais que obtém na Internet, exceto se vier de um advogado. De preferência um especialista no campo, neste caso: licenças de software. Portanto, tome todas as respostas que você obtiver com um grão de sal, pois, caso contrário, você poderá se expor a ações judiciais (já que seu aplicativo é comercial).

— Radu Murzea

Respostas:

Posso usá-los no meu aplicativo comercial?

Depende do que você pretende fazer com o software que você produz.

Em primeiro lugar, nem o ASL ¹ , a GPL ou a LGPL fazem restrições quanto ao que você pode usar o software na sua organização. As restrições estão todas no código que é distribuído fora da sua organização.

Para a GPL, a restrição é que, se você incorporar o código da GPL em seu próprio software, e depois distribuí-lo para fora da sua organização, ENTÃO deverá disponibilizar o código-fonte nos termos da GPL ou de uma licença de código-fonte aberto compatível.

Portanto, se você usa o código GPL em seu aplicativo e o distribui, seu aplicativo deve ser de código aberto ... ou você está violando a licença.
Para LGPL, a restrição (veja acima) se aplica somente ao código-fonte da própria biblioteca LGPL'ed; ou seja, se você mudar a biblioteca. Se você acabou de usar a biblioteca, não é necessário disponibilizar seu código-fonte.

Há também uma restrição de que o código LGPL no seu aplicativo deve ser substituível pelo usuário do seu código. Isso significa (com efeito) que, se você distribuir seu código apenas como binários, não poderá vincular estaticamente seu código à biblioteca. Você deve usar o vínculo dinâmico.
Para o ASL, a única restrição significativa é que você deve dizer se mudou alguma coisa da versão original do código do ASL que você está usando.

Por fim, apenas para deixar claro, nem GPL, LPGL ou ASL impõem qualquer restrição ao seu objetivo de usar o software. E isso inclui se seu objetivo é ganhar dinheiro. Eles apenas restringem a maneira como você pode ganhar dinheiro ... e, no caso de LGPL e ASL, a restrição é bastante mínima.

E se sim, que precauções devo tomar?

Para LGPL e ASL, não são necessárias precauções.

IANAL - Eu não sou advogado. Se precisar ter certeza, pergunte a um especialista real e qualificado; ou seja, um advogado especializado em leis de propriedade intelectual de software.

^{1 - Para os fins desta resposta, ASL == Apache Software License versão 2.}

— Stephen C
fonte

Isso se aplica a um aplicativo da web? Quero dizer, o cliente receberá apenas o arquivo war que contém os arquivos .class e .JAR. Se tudo está bem LGPL ainda está bem?

— Java Main

Se você não estiver modificando as bibliotecas LGPL, poderá incluí-las com o código do aplicativo no arquivo WAR. Mas você precisa fazer isso de forma que a pessoa para quem você está distribuindo seu código possa substituir o código LBPL por outra versão. Um "uber-JAR" é provavelmente uma violação. Ofuscar as bibliotecas LGPL junto com seu código é definitivamente uma violação. (IANAL)

— Stephen C

Há uma pasta chamada lib onde eu coloco todos os arquivos jar. Para que ele possa substituir qualquer arquivo Jar por sua outra versão. Mas não garanto que funcionará sempre. Ainda está bem?

— Java Main

Pergunte ao seu advogado :-)

— Stephen C

É apenas um aplicativo Web normal em execução no tomcat. Se você puder ajudar será bom. De qualquer forma, obrigado pelo seu esclarecimento realmente ajudando.

— Java Main

A Licença Apache não impõe restrições ao software vinculado a um plug-in ou biblioteca distribuída sob a licença Apache. A LGPL, por outro lado, exige que a biblioteca LGPL se vincule dinamicamente (e possa ser substituída por um usuário) ou que todo o trabalho seja liberado sob uma licença de código-fonte aberto compatível com GPL.

Para o uso em um aplicativo de código-fonte fechado, isso significa efetivamente que você pode usar o plug-in Licenciado pela Apache sem restrição e que o plug-in licenciado pela LGPL deve ser vinculado dinamicamente.

Se você distribuir um dos plug-ins junto com seu aplicativo, também deverá fornecer as fontes para os plug-ins ou informar aos usuários onde eles podem obter essas fontes.

— Bart van Ingen Schenau
fonte

BartvanIngenSchenau, o que você quer dizer com aplicação de "código fechado"? Você quer dizer solução empacotada (não distribuindo código-fonte) ou se refere à sua distribuição dentro de uma organização versus algo como distribuição comercial?

— Rachael

@Rachael: "Código fechado" é geralmente usado para se referir a software para o qual o código fonte não é distribuído. A distribuição dentro de uma organização é um caso um pouco especial quando se trata de licenciamento de direitos autorais, porque fornecer cópias de um produto de software para pessoas dentro de uma organização não é considerada distribuição para a maioria das leis de direitos autorais ( é considerada cópia).

— Bart van Ingen Schenau

-4

Primeiro de tudo, isso não é aconselhamento jurídico.

Não é permitido que o software GPL seja vinculado a (inclusive pela rede), seja compilado ou enviado com software que não seja GPL de qualquer forma. A LGPL diminui um pouco isso para permitir suporte de terceiros que não sejam da GPL, inclusive para produtos comerciais. A parte importante aqui é que deve ser de terceiros (por assim dizer), o que cria uma pequena brecha.

Em resumo, você vincula a uma biblioteca LGPL existente (chame isso de primeira parte), mas o software que faz esse link deve ser transformado em LGPL. Chame este software de segunda parte. Embora o software de segunda parte deva ser lançado como LGPL, como proprietário do software de segunda parte, você pode permitir que outro software a utilize fora da LGPL (desde que o software de segunda parte também esteja disponível na LGPL). Em outras palavras, o software de terceiros deve ser disponibilizado como LGPL, mas não é necessáriolicenciá-lo como LGPL em todos os casos. Todo usuário individual de um software deve ter licença para usar o software por lei. O que estou dizendo é que, desde que cada usuário tenha acesso ao software como LGPL, você também poderá licenciá-lo usando termos não virais. Você também pode criar o software de terceiros, licenciando o software de terceiros para uso próprio pelo software de terceiros sob termos não LGPL. Eu até ouvi falar de pessoas que escrevem para si mesmas um contrato e uma licença para usar seu próprio software. A lei pode ser estranha! O software de terceiros não precisa ser LGPL em nenhum caso.

Portanto, o que você faz é criar uma biblioteca para vincular à lib LGPL como apenas um wrapper e liberar o wrapper como LGPL. Em seguida, você pode vincular a este invólucro ( seu invólucro) em software não LGPL, desde que seu invólucro esteja disponível como LGPL.

Não posso falar pela Licença de Software Apache porque não sou familiar com ela.

— JSON
fonte

Observe que estou usando o termo "link" de maneira muito genérica, porque isso não se aplica apenas a idiomas compilados e também pode incluir "incluindo" o software LGPL (a partir de um local ou de uma rede, como PHP ou Javascript) ou de outra forma "vinculando" a um software em uma rede como Java RMI etc.

— JSON

"O software GPL não pode ser vinculado a (inclusive pela rede), ser compilado ou enviado com software que não seja GPL de qualquer forma". . O "ou" deve ser "e". Você PODE usar software GPL em software não GPL, desde que não o "envie".

— Stephen C

Essa resposta está errada em muitos níveis. A questão não é sobre a GPL, mas a LGPL. O código ASL pode ser integrado ao código sob quase qualquer outra licença, o que significa também LGPL ou mesmo GPL (mesmo que o contrário seja proibido). Você pode até usá-lo em software de código fechado. E, como Stephen C. apontou, você pode fazer o que quiser, desde que não o publique ou disponibilize ao público.

— Alexis Dufrenoy