MIT x BSD x dupla licença


87

Meu entendimento é que:

  • Projetos licenciados pelo MIT podem ser usados ​​/ redistribuídos em projetos licenciados pelo BSD .
  • Projetos com licença BSD podem ser usados ​​/ redistribuídos em projetos com licença MIT.
  • As licenças das cláusulas MIT e BSD 2 são essencialmente idênticas .
  • Cláusula BSD 3 = Cláusula BSD 2 + a cláusula "sem endosso"
  • A emissão de uma licença dupla permite que os usuários escolham entre essas licenças - não se vinculem a ambas.

Se todas as opções acima estiverem corretas, qual é o sentido de usar uma licença dupla do MIT / BSD? Mesmo se o BSD se referir à versão de 3 cláusulas, um usuário não pode legalmente optar por cumprir apenas a licença do MIT?

Parece que se você realmente deseja que a cláusula "sem endosso" seja aplicada, é necessário licenciá-la como apenas BSD (não dual). Se você não se importa com a cláusula "sem endosso", apenas o MIT é suficiente e o MIT / BSD é redundante.

Da mesma forma, como as licenças MIT e BSD são " compatíveis com GPL " e podem ser redistribuídas em projetos com licença GPL , o MIT / GPL com licenciamento duplo também parece redundante.


1
Você pode fornecer um exemplo de licenças MIT + BSD? Geralmente é redundante a licença dupla sob duas licenças igualmente permissivas, mas vi o licenciamento duplo abusado como uma maneira de declarar explicitamente que o código pode ser redistribuído sob cada uma das licenças.
yannis

@Yannis Sim, eu me perguntei se as pessoas as licenciavam duas vezes apenas para serem mais explícitas para as pessoas que não sabem. Mas acho que isso as torna mais confusas para eles.
Ryanve #



1
Na minha experiência, as pessoas usam principalmente o licenciamento duplo para licenças incompatíveis. por exemplo MPL + (L) GPL ou uma licença paga sem copyleft junto com (A) GPL.
CodesInChaos 28/07

Respostas:


60

Meu entendimento é que:

  1. Projetos licenciados pelo MIT podem ser usados ​​/ redistribuídos em projetos licenciados pelo BSD.
    VERDADEIRO (mas, a menos que haja modificações, os usuários também podem obtê-lo das fontes originais.

  2. Projetos com licença BSD podem ser usados ​​/ redistribuídos em projetos com licença MIT.
    A licença FALSE MIT permite a distribuição sem créditos de contribuição; BSD não.

  3. As licenças das cláusulas MIT e BSD 2 são essencialmente idênticas.
    FALSO Veja acima.

  4. Cláusula BSD 3 = Cláusula BSD 2 + a cláusula "sem endosso"
    TRUE

  5. A emissão de uma licença dupla permite que os usuários escolham entre essas licenças - não se vinculem a ambas.
    VERDADEIRO (acho que sim!)

Da mesma forma, como as licenças MIT e BSD são "compatíveis com GPL" e podem ser redistribuídas em projetos com licença GPL, o MIT / GPL com licenciamento duplo também parece redundante.

NÃO . Aqui está uma grande diferença. A licença MIT e a licença Apache exigem apenas que você dê crédito aos detentores dos direitos autorais originais. Se você escolher, poderá redistribuir a fonte; mas se você escolher, poderá manter seu novo produto derivado sem abrir o código. Portanto, é possível usar o código desenvolvido sob o MIT e o Apache - sob licença comercial.

Se você usar código com licença baseada na GPL e modificá-lo, deverá distribuir o código modificado também na GPL. Em outras palavras, uma vez que qualquer base de código GPL é usada em um projeto e se você deseja publicá-lo como um produto, ele deve ser publicado com o código-fonte e publicado na GPL. Ela nunca pode ser uma licença comercial ou de código fechado, e não pode ser outra licença menos rigorosa que a GPL.

É possível, por exemplo, usar o código de licença MIT, Apache ou BSD, modificado e distribuído sob a GPL. Depois que uma base de código é distribuída como GPL, suas versões derivadas adicionais não podem ser distribuídas sob licença MIT, Apache ou BSD, mas devem ser apenas GPL.

Edit:
Exemplo de caso de licença dupla: Suponha que o Nice Office seja lançado sob licença dupla - MIT e GPL. Tem duas possibilidades. Algumas pessoas podem criar o NicePro Office, que pode ser comercial e vender. Enquanto alguma outra comunidade de código aberto cria um fork do NiceOpen Office. Nesse caso, ele pode aplicar a distribuição GPL (da versão original do Nice Office e da NiceOpen Office); portanto, se você iniciar com o NiceOpen Office, deverá cumprir apenas a licença GPL e não a MIT.

O ponto é que, no caso de licença dupla, a primeira pessoa que obtém uma licença tem uma escolha. Ele pode escolher de qualquer maneira - no entanto, a segunda pessoa precisa aderir à escolha que a primeira pessoa fez. Ele / Ela não pode substituir os direitos originais de qualquer geração e não pode de forma alguma reduzir a obrigação da licença aplicável.

EDIT 2 Adicionando uma leitura interessante - as licenças GPL e MPL apresentam sérios conflitos. Leia isso. http://www.tomhull.com/ocston/docs/mozgpl.html


4
@Dipan Se um projeto for licenciado duas vezes sob o MIT / GPL, ele poderá ser usado em um projeto proprietário porque o usuário pode optar por seguir apenas o MIT. Se um projeto possuir apenas a licença MIT, poderá ser redistribuído sob outras licenças, incluindo a GPL. Isso é o que eu quis dizer com redundante.
Ryanve #

11
@DipanMehta O que você quer dizer com "créditos de contribuição" no # 2? Parece que você está se referindo à licença de 4 cláusulas do BSD, que não é verificada pela FSF como as cláusulas 3 e 2. Estou falando das cláusulas 3 e 2, nesse caso, tenho certeza de que todas as cinco afirmações são verdadeiras .
Ryanve

4
Você pode usar o código licenciado por BSD em conjunto com o código licenciado pelo MIT; basta mencionar nos materiais do projeto que "o BazApp usa libfoobar, que é distribuído sob uma licença BSD" ou algo assim. As licenças BSD e MIT são aplicadas em um nível por arquivo, em vez de por projeto.
Mipadi

10
@Dipan_Mehta Como o ryanve já lhe disse, você está falando sobre a licença BSD original de 4 cláusulas, enquanto o OP está falando sobre as licenças BSD revisadas de 3 e 2 cláusulas. A licença BSD de 2 cláusulas é realmente equivalente à licença do MIT. Até a página OSI afirma isso.

17
O ponto 2 (o código BSD não pode ser incluído no código MIT) é contrário a todas as informações que eu já li sobre o BSD de 3 e 2 cláusulas. O ponto 2 seria verdadeiro sobre o BSD de 4 cláusulas (agora antigo e esquecido), mas o OP deixou claro que essa pergunta não se refere ao BSD de 4 cláusulas. Parece bastante prejudicial ter uma informação tão enganosa em uma resposta muito boa e credível.
Apsillers

4

Seus cinco pontos são todos verdadeiros .

A outra resposta parece estar assumindo que você está incluindo a licença BSD mais antiga e raramente usada de 4 cláusulas .

Se você interpretar "licenças BSD" como se referindo às variantes de 3 ou 2 cláusulas mais usadas da licença BSD, todas as cinco reivindicações da pergunta serão verdadeiras.

Se todas as opções acima estiverem corretas, qual é o sentido de usar uma licença dupla do MIT / BSD?

Tecnicamente, não deve haver necessidade disso. Qualquer um pode ser usado nas mesmas situações.

Mesmo que o BSD se refira à versão de 3 cláusulas, um usuário não pode legalmente optar por cumprir apenas a licença do MIT?

Isso parece correto.

Parece que se você realmente deseja que a cláusula "sem endosso" seja aplicada, é necessário licenciá-la como apenas BSD (não dual). Se você não se importa com a cláusula "sem endosso", apenas o MIT é suficiente e o MIT / BSD é redundante.

Está certo. Se você se importa com essa cláusula específica, não faria sentido também licenciar o mesmo trabalho sob licenças sem essa cláusula.

Da mesma forma, como as licenças MIT e BSD são "compatíveis com GPL" e podem ser redistribuídas em projetos com licença GPL, o MIT / GPL com licenciamento duplo também parece redundante.

Sim.

No entanto, algumas vezes um produto de software afirma ser licenciado como MIT e GPL (ou alguma licença permissiva e GPL), mas na realidade eles estão se referindo a duas versões diferentes do software.

Por exemplo, alguns softwares podem ser compilados e distribuídos com uma licença permissiva como BSD ou MIT, mas se você omitir algumas bibliotecas e, portanto, alguma funcionalidade, ele pode ser distribuído como GPL. As bibliotecas omitidas geralmente são bibliotecas de terceiros que não são compatíveis com GPL, mas ainda assim poderiam ser distribuídas.

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.