MIT contro BSD contro doppia licenza

My understanding is that:

1. I progetti con licenza MIT possono essere usati / ridistribuiti in progetti con licenza BSD.
   TRUE (ma a meno che non ci siano modifiche, anche gli utenti possono ottenerlo dalle fonti originali.

2. I progetti con licenza BSD possono essere utilizzati / ridistribuiti in progetti con licenza MIT.
   FALSE la licenza MIT consente la distribuzione senza crediti di contribuzione; BSD no.

3. Le licenze del MIT e della clausola BSD 2 sono essenzialmente identiche.
   FALSE Vedi sopra.

4. BSD 3-clause = BSD 2-clause + la clausola "no endorsement"
   TRUE

5. L'emissione di una doppia licenza consente agli utenti di scegliere tra quelle licenze, non vincolanti per entrambe.
   TRUE (penso di sì!)

Similarly, since the MIT and BSD licenses are both "GPL-compatible" and can be redistributed in GPL-licensed projects, then dual licensing MIT/GPL also seems redundant.

No . Qui c'è una grande differenza. La licenza MIT e la licenza Apache richiedono solo che tu dia credito ai detentori del copyright originali. Se scegli, puoi ridistribuire la fonte; ma se lo scegli puoi mantenere il tuo nuovo codice derivato senza . Quindi, è possibile utilizzare il codice sviluppato sotto MIT e Apache - sotto licenza commerciale.

Se usi mai il codice con licenza basata su GPL e ti capita di modificarlo, devi distribuire il tuo codice modificato anche sotto GPL. In altre parole, una volta che una qualsiasi base di codice GPL viene utilizzata in un progetto e se si desidera pubblicarla come prodotto, deve essere pubblicata con il codice sorgente e deve essere pubblicata in GPL. Non può mai essere una licenza commerciale o una fonte chiusa e non può essere un'altra licenza meno rigida di GPL.

È possibile ad esempio prendere il codice di licenza MIT, Apache o BSD, modificato e distribuito sotto GPL. Una volta che il codice base è distribuito come GPL, le sue ulteriori versioni derivate non possono essere distribuite sotto licenza MIT, Apache o BSD ma devono essere solo GPL.

Modifica
Esempio di caso di doppia licenza: Supponiamo che Nice Office sia rilasciato con doppia licenza - MIT e GPL. Ha due possibilità. Alcune persone possono creare NicePro Office, che può essere commerciale e vendere. Mentre un'altra comunità open source crea una fork NiceOpen Office. In questo caso, può applicare la distribuzione GPL (del Nice Office originale e della versione NiceOpen Office), quindi se si avvia con NiceOpen Office, è necessario rispettare solo GPL e non la licenza MIT.

Il punto è che in caso di doppia licenza la prima persona che ottiene una licenza ha una scelta. Può scegliere in entrambi i modi - tuttavia, la seconda persona deve rispettare la scelta fatta dalla prima persona. Non può ignorare i diritti originali di entrambe le generazioni e non può in alcun modo ridurre l'obbligo della licenza applicabile.

EDIT 2 Aggiunta di una lettura interessante - Licenze GPL e MPL ha un grave conflitto. Leggi questo. link

I tuoi cinque punti sono tutti true .

L'altra risposta sembra presumere che tu stia includendo la più vecchia, raramente usata 4 licenza BSD .

Se interpreti "licenze BSD" come riferimento alle varianti a 3-clause o 2-clausole più comunemente utilizzate della licenza BSD, tutte e cinque le affermazioni nella domanda sono vere.

If all of the above is correct, then what is the point of using a dual MIT/BSD license?

Tecnicamente non dovrebbe esserci bisogno. Entrambi possono essere utilizzati nelle stesse situazioni.

Even if the BSD refers to the 3-clause version, then can't a user legally choose to only abide by the MIT license?

Sembra corretto.

It seems that if you really want the "no endorsement" clause to apply then you have to license it as just BSD (not dual). If you don't care about the "no endorsement" clause, then MIT alone is sufficient and MIT/BSD is redundant.

È vero. Se ti interessa questa particolare clausola, non avrebbe senso anche concedere in licenza lo stesso lavoro sotto licenze senza quella clausola.

Similarly, since the MIT and BSD licenses are both "GPL-compatible" and can be redistributed in GPL-licensed projects, then dual licensing MIT/GPL also seems redundant.

Sì.

Sebbene, a volte, un prodotto software rivendichi una doppia licenza come MIT e GPL (o qualche licenza permissiva e GPL), ma in realtà si riferiscono a due diverse versioni del software.

Ad esempio, alcuni software possono essere compilati e distribuiti con una licenza permissiva come BSD o MIT, ma se si omettono alcune librerie e quindi alcune funzionalità, è possibile distribuirle come GPL. Le librerie omesse di solito sono librerie di terze parti che non sono compatibili con GPL, ma potrebbero comunque essere distribuite in altro modo.