Eu gostaria de lançar uma biblioteca de software escrita em uma linguagem de programação orientada a objetos (Java) baseada em classe em um serviço de hospedagem de código-fonte baseado na Web , que permite que os garfos do projeto sejam mesclados no projeto principal (GitHub via pull solicitações de). Eu pesquisei na web e pensei muito em como licenciar o software. Estou correto nas seguintes premissas (de uma perspectiva da IANAL )?

• Tanto a LGPL quanto a MPL promovem o compartilhamento de modificações no software licenciado LGPL / MPL sendo usado em outros projetos de software. Em vez de exigir que os usuários da biblioteca modificada hospedem um fork separado da biblioteca, posso promover a contribuição para a biblioteca original (por exemplo, por meio de solicitações pull).

• A principal diferença é como o código licenciado MPL / LGPL deve ser vinculado ao projeto. Os arquivos de código-fonte MPL podem ser copiados diretamente em um (possivelmente) projeto de software proprietário ( vinculação estática ), enquanto o código licenciado LGPL deve ser vinculado dinamicamente (vagamente vinculado ao projeto de software possivelmente proprietário, para que os usuários finais possam mudar o software licenciado biblioteca para outra versão da biblioteca de software licenciada).

• A vinculação dinâmica e, portanto, a LGPL impõem obstáculos extras para empacotar o produto de software proprietário, sem promover mais contribuições para a biblioteca de software de código aberto do que com a vinculação estática (e, portanto, MPL). Existe uma LGPL modificada que permite vinculação estática.

• Não há outras diferenças relevantes (da perspectiva da IANAL ).

• As versões mais antigas das licenças não atendem às minhas necessidades tão boas quanto as mais recentes.

Como você pode ver, meu principal requisito é que as modificações da biblioteca de software que possam ser úteis para o público em geral permaneçam em código aberto, sem impor restrições ao uso da biblioteca de software em um produto proprietário.
Não há licença que também exija que extensões da biblioteca de software relevantes para o trabalho original sejam liberadas como código-fonte aberto, pois o escopo do termo relevante pode ser arbitrariamente pequeno / grande, terminando assim como GPL que não pode ser usado em um produto proprietário (sem liberar toda a fonte).

Fico tentado a usar o LPGL modificado , mas, por outro lado, desencorajado pela impopularidade. Com base nos pontos acima, prefiro MPL.
Pergunta: Minhas declarações acima estão corretas? Qual licença devo escolher considerando meus requisitos?

Solução: Com a ajuda da discussão na resposta aceita, optei por manter a MPL por causa da popularidade , liberdade de vinculação e por ser uma licença oficial e não modificada .

Acredito que você tenha declarado as diferenças entre a Licença Pública Mozilla e a Licença Pública Geral Menor GNU com precisão e pode atender às suas necessidades, mas você está ignorando a diferença mais importante entre as duas licenças:

Quem pode fazer novas versões?

Tanto o MPL (seção 10) quanto a LGPL (seção 14) incluem em suas licenças o direito de substituir a versão atual por uma última, e não há limitações reais sobre o que pode ocorrer nessas licenças. Embora seja altamente improvável que a Mozilla Foundation ou a Free Software Foundation façam algo tão louco quanto, digamos, instituam uma cláusula que diz que "todas as contribuições para este software se tornam nossa propriedade", não está além do possível que um dos as organizações lançarão uma nova versão da licença que você não gosta.

O que traz outro ponto sobre o uso de uma "LGPL modificada".

Uma licença modificada não é a mesma licença!

Embora você tenha uma capacidade incrível de especificar seus próprios termos de licenciamento e, em essência, possa dizer "você pode distribuir isso de acordo com a GPL, mas precisa colocar meu nome em seus créditos e me pagar 1% de qualquer receita gerada" , a qualquer momento, você cria uma nova licença com base no trabalho de outra pessoa. Isso significa que você NÃO está usando a MPL ou a LGPL, mas uma nova "licença mucaho".

O que isso significa é que você provavelmente não receberá nenhuma ajuda do autor da sua licença original se precisar defender sua interpretação da licença dentro de uma sala do tribunal, e é inteiramente possível que eles entrem em ação para dizer que SUA versão deve ser aplicada e não é teu.

Obviamente, esses dois são pontos menores. Até a "popularidade da licença" não importa, a menos que você espere que seu código seja incorporado diretamente em projetos maiores.

Pessoalmente, acho que a MPL é uma escolha melhor se você gosta de compatibilidade proprietária ou se a escolha é entre a MPL real e uma licença diferente que você precisa editar manualmente com base na LGPL. A menos que você tenha um motivo para não usar a MPL, escolha algo apoiado por uma fundação, em vez de uma que possa deixá-lo em um tribunal sem qualquer tipo de ajuda.

A resposta da DougM e da AER faz uma observação justa. MPLv2 e LGPLv3 com exceção estática são os mesmos em relação aos eventos que acionariam o copyleft. No entanto, acho que estamos perdendo outra diferença muito importante entre LGPL e MPL. Quando o copyleft é acionado, o copyleft se aplica a:

• para MPL: exatamente os mesmos arquivos da sua biblioteca original
• para LGPL: ao "trabalho baseado na biblioteca", em oposição ao "trabalho que usa a biblioteca". Portanto, o LGPL pode potencialmente estender seu copyleft para novos arquivos.

Borda: o uso de MPL permite que os usuários não compartilhem suas melhorias

MPL é uma licença copyleft no nível de arquivo. Isso significa que se alguém o incorporar em um projeto maior (estaticamente ou dinamicamente) e fizer uma alteração no seu arquivo, ele precisará liberar a alteração feita nesse arquivo em particular.

Se você estiver preocupado em manter aberta a integridade da sua base de código, há casos extremos nos quais esse efeito copyleft da MPL pode não ser suficiente.

Por exemplo, alguém pode pegar um dos arquivos principais do seu projeto, adicionar "import my_private_new_file" e modificar seu método principal, por exemplo, adicionando "my_private_new_file.newAwesomeFeature.run ()" .

E dessa maneira ele poderia adicionar novos recursos ao seu projeto enquanto apenas liberava o arquivo principal modificado e mantinha a lógica real do novo recurso fechada em "my_private_new_file" .

Ter o arquivo principal de volta à comunidade apenas fornece as informações de que "ei, você adicionou um novo recurso", mas não permite que você incorpore esse novo recurso em campo aberto ... Pode ser irritante se o novo recurso estiver próximo relacionado ao problema que sua biblioteca está tentando resolver.

Obviamente, esse é um caso extremo e é pouco provável que alguém queira fazer isso, mas é um risco que você deve estar ciente ao usar o MPLv2.

A LGPL foi criada para proibir tais comportamentos. Vejo:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• A LGPL me permite fazer isso?

Cito a licença LGPL original:

Preste muita atenção à diferença entre um "trabalho baseado na biblioteca" e um "trabalho que usa a biblioteca". O primeiro contém código derivado da biblioteca, enquanto o último deve ser combinado com a biblioteca para ser executado.

O copyleft se aplica apenas ao "trabalho baseado na biblioteca". Agora, o que é um "trabalho baseado na biblioteca" na prática? Deixa espaço para a interpretação. O que não é apenas uma coisa agradável, pois significa que o cumprimento da sua licença se torna mais complicado e, portanto, assustador. Isso pode levar algumas pessoas a simplesmente não usar sua biblioteca.

Nesse sentido, a LGPL é mais restritiva que a MPL, mas também mais protetora da integridade do projeto.

A MPL facilita para os usuários do mundo proprietário corrigir sua biblioteca e usá-la, enquanto ainda precisa compartilhar a correção

Uma vantagem para o MPL é que, se um usuário encontrar um bug na sua biblioteca, ele poderá corrigi-lo diretamente no arquivo, sem precisar fornecer todo o código, mas apenas fornecendo a correção. Na prática, ao distribuir seu trabalho para um cliente, ele pode apenas fornecer um link para um fork do seu projeto contendo a correção, e ele é bom.

Ao usar LGPL, as coisas ficam mais complicadas. Se alguém bifurcar o seu projeto, corrigir um bug e incorporá-lo estaticamente ao seu software proprietário, ele deverá distribuir aos seus usuários o "trabalho baseado na biblioteca" sob a LGPL. Qual é uma noção bastante obscura, especialmente quando a biblioteca está estaticamente incorporada ... Nesse aspecto, acho que foi a razão original pela qual não existe uma exceção "estática" na LGPL original. Torna a identificação do "trabalho baseado na biblioteca" trivial: é a biblioteca dinâmica que você chama no seu software proprietário.

Como resultado, o MPL torna muito mais fácil para os fornecedores proprietários usar E enviar correções para sua biblioteca do que o LGPL.

Ao mesmo tempo, na maioria das vezes os fornecedores proprietários não têm recursos nem tempo para mergulhar em sua complicada biblioteca e provavelmente não o consertariam sozinhos. Eles preferem abrir um problema no seu repositório do GitHub ou enviar um email na lista de emails e aguardar sua correção.

Nesse sentido, a LGPL reforça mais esse tipo de comportamento. Mas a imposição é realmente necessária?

Conclusão

Escolher entre LGPL e MPL é uma pergunta complicada e, como de costume na licença de software, depende do seu objetivo. Ambas as licenças são muito semelhantes, mas ao mesmo tempo extremamente diferentes. Eles foram projetados para objetivos e filosofia muito diferentes.

A LGPL foi criada pela Free Software Foundation para permitir o amplo uso de bibliotecas de software livre no mundo proprietário, mas sempre com a ideia de promover o software livre e combater softwares proprietários. Tudo faz parte de uma estratégia em direção à sua ideologia. Veja: https://www.gnu.org/licenses/why-not-lgpl.html

MPL é uma licença prática projetada pela Mozilla para impor algum tipo de compartilhamento à biblioteca original, enquanto ainda encoraja as pessoas a criar softwares e complementos proprietários no topo (incluindo o próprio Mozilla), que é uma prática que a FSF autoriza via LGPL, mas ainda considera prejudicial.

Por essência, o MPLv2 é considerado por muitos como uma licença permissiva, enquanto o LGPLv3, incluindo exceção estática, raramente é chamado dessa maneira.

EDITAR

Eu esqueci de mencionar algo importante. LGPLv3 (com ou sem exceção estática) proíbe a tivoização . Você pode pensar que é um "detalhe", mas na verdade não é, dependendo do seu objetivo. Você se preocupa com os usuários Freedom? Então não é um detalhe. Você se importa que sua biblioteca possa ser usada no dispositivo da Apple? O VLC se preocupa mais com o uso, então eles decidiram usar o LGPLv2, que não contém essa restrição. Da mesma forma, essa é uma das razões pelas quais o Linux continua usando a GPLv2 . O MPLv2 também não tem nenhuma restrição de ativação, obviamente, pois é uma licença criada com a filosofia de código aberto mais "prática" em mente, não a ideologia da FSF.

Pode haver outras coisas "menores" como essa que eu perdi.