Compatibilidade com licenças MPL 1.1 e APL 2.0


11

Estou trabalhando em um projeto licenciado sob o MPL 1.1 e gostaria de incorporar algum código licenciado sob o APL 2.0.

Eu sei que em 2010 a Mozilla anunciou que estava atualizando o MPL para torná-lo mais "compatível com Apache", entre outras coisas.

Eu não sou advogado. Exatamente quais partes do MPL 1.1 não combinam com o APL 2.0 e vice-versa? O projeto tem muito poucos de seus colaboradores originais ainda envolvidos ativamente, então duvido que possa entrar em contato com todos eles para obter permissão para alterar a licença.


2
Também não somos advogados. É melhor pedir a um advogado de verdade aconselhamento jurídico.
Federico klez Culloca 14/09

Respostas:


7

A menos que seu projeto esteja usando "apenas o Mozilla 1.1", ele está implicitamente usando o "Mozilla 1.1 ou superior". Portanto, o projeto pode ser atualizado para o Mozilla 2.0 (ou até bifurcado, sem o consentimento dos colaboradores).

Se você quiser ficar com o Mozilla 1.1, tudo que você precisa fazer é não misturar o código licenciado Apache e Mozilla no mesmo arquivo de origem. Seu projeto será um trabalho de licença mista. Navegue pelos arquivos "copyright" em http://packages.debian.org para ver como essa situação é comum.

=========== Histórico completo

A licença do Apache (2.0; 1.0 não tem relação!) É "permissiva", o que significa que os derivativos podem ser comerciais e fechados. Antes do Apache, todas as licenças permissivas populares (BSD, Athena (MIT / X11), zLib, ~ Public Domain) eram bastante simples. Portanto, eles são compatíveis com quase todas as outras licenças (bem, exceto se houver uma cláusula de anúncio, que agora é rara).

A licença do Apache tenta atender às necessidades mais modernas. Possui procedimentos para rastrear o histórico de uma obra. Possui uma cláusula de patente no estilo MAD (Mutually Assured Destruction). Nada disso é realmente contestado pela GPL ou pela Mozilla, apenas não está entre as "restrições" que eles permitem.

A licença da Mozilla requer menos créditos, mas exige que as derivativas sejam disponibilizadas ao "desenvolvedor inicial" do projeto sem restrição e disponibilizadas ao público sob a licença da Mozilla. A intenção era permitir que o código fosse de código aberto, sem que o proprietário perdesse sua vantagem sobre os concorrentes.

A licença Mozilla infecta até o limite do arquivo de código-fonte, mas geralmente não é além disso. (A GPL infecta muito mais, até o limite do vinculador / chamada ao kernel.) Os arquivos de patch são uma exceção, pois tendem a ser trabalhos derivados do destino do patch.

Você pode agregar livremente arquivos sob Mozilla, LGPL e qualquer licença permissiva, como o Apache. Essa é a norma em grandes aplicativos de código aberto. Especialmente para Java, onde a GPL é considerada muito infecciosa e o Apache.org é o maior provedor de infraestrutura.

Um único arquivo de código-fonte não pode estar em conformidade com a licença Mozilla 1.1 AND Apache, porque o Mozilla (como GPL) não tolera nenhuma carga adicional. Uma única fonte pode estar em conformidade com o Mozilla OR Apache ou com quase qualquer outra licença. Por exemplo, o Firefox é lançado sob licença Mozilla OR GNU OU LGNU.

Devido à crescente influência do Apache, o GPLv3 e o Mozilla v2 garantiram que eles fossem compatíveis. Desativar a "cláusula de atualização de versão" é a única carga que a GPL e a Mozilla permitem que um usuário adicione. A única licença principal da qual os usuários realmente “optaram por não participar” foi a GPLv3, por ser mais infecciosa que a GPLv2. O kernel do Linux, por exemplo, é apenas GPLv2 .



Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.