MIT contre BSD contre double licence
Ma compréhension est que:
- MIT - les projets sous licence peuvent être utilisés/redistribués dans BSD - les projets sous licence.
- Les projets sous licence BSD peuvent être utilisés/redistribués dans les projets sous licence MIT.
- Les licences MIT et BSD à 2 clauses sont essentiellement identiques .
- BSD 3-clause = BSD 2-clause + le "pas d'approbation "clause
- L'émission d'une double licence permet aux utilisateurs de choisir parmi ces licences — ne pas être liés aux deux.
Si tout ce qui précède est correct, quel est l'intérêt d'utiliser une licence double MIT/BSD? Même si le BSD fait référence à la version à 3 clauses, un utilisateur ne peut-il pas légalement choisir de ne respecter que la licence MIT?
Il semble que si vous voulez vraiment que la clause "sans approbation" s'applique, vous devez la concéder sous licence uniquement BSD (pas double). Si vous ne vous souciez pas de la clause "sans approbation", alors MIT seul est suffisant et MIT/BSD est redondant.
De même, puisque les licences MIT et BSD sont toutes deux " compatibles GPL " et peuvent être redistribuées dans GPL - projets sous licence, puis la double licence MIT/GPL semble également redondante.
Ma compréhension est que:
Les projets sous licence MIT peuvent être utilisés/redistribués dans des projets sous licence BSD.
[~ # ~] true [~ # ~] (mais à moins de modifications, les utilisateurs peuvent l'obtenir à partir des sources originales aussi.Les projets sous licence BSD peuvent être utilisés/redistribués dans les projets sous licence MIT.
[~ # ~] false [~ # ~] MIT permet la distribution sans contribution crédits, pas BSD.Les licences MIT et BSD à 2 clauses sont essentiellement identiques.
[~ # ~] false [~ # ~] Voir ci-dessus.BSD 3-clause = BSD 2-clause + la clause "no endossement"
[~ # ~] vrai [~ # ~]L'émission d'une double licence permet aux utilisateurs de choisir parmi ces licences, sans être liés aux deux.
[~ # ~] vrai [~ # ~] (Je pense que oui!)
De même, étant donné que les licences MIT et BSD sont toutes deux "compatibles GPL" et peuvent être redistribuées dans des projets sous licence GPL, la double licence MIT/GPL semble également redondante.
[~ # ~] non [~ # ~] . Voici une différence majeure. MIT et la licence Apache nécessitent uniquement que vous accordiez du crédit aux titulaires des droits d'auteur d'origine. Si vous le souhaitez, vous pouvez redistribuer la source; mais si vous choisissez, vous pouvez conserver votre nouveau produit dérivé sans code d'ouverture. Par conséquent, il est possible d'utiliser du code développé sous MIT et Apache - sous licence commerciale.
Si jamais vous utilisez du code avec une licence GPL et que vous le modifiez, vous devez distribuer votre code modifié également sous GPL. En d'autres termes, une fois qu'une base de code GPL est utilisée dans un projet, et si vous souhaitez la publier en tant que produit, elle doit être publiée avec le code source et elle doit être publiée sous GPL. Il ne peut jamais s'agir d'une licence commerciale ou d'une source fermée, ni d'une autre licence moins stricte que la GPL.
Il est possible par exemple de prendre le code de licence MIT, Apache ou BSD, modifié et distribué sous GPL. Une fois qu'une base de code est distribuée sous GPL, ses autres versions dérivées ne peuvent pas être distribuées sous licence MIT, Apache ou BSD mais doivent être GPL uniquement.
Modifier:
Exemple de double licence: Supposons que Nice Office soit distribué sous double licence - MIT et GPL. Il a deux possibilités. Certaines personnes peuvent créer NicePro Office, qui peut être commercial et vendre. Alors qu'une autre communauté open source crée un fork NiceOpen Office. Dans ce cas, il peut être appliqué lors de la distribution GPL (de la version originale de Nice Office ainsi que de la version NiceOpen Office), donc si vous commencez avec NiceOpen Office, vous devez vous conformer à GPL seulement et non MIT license.
Le fait est qu'en cas de double licence, la première personne qui obtient une licence a le choix. Il peut choisir l'une ou l'autre façon - cependant, la deuxième personne doit adhérer au choix fait par la première personne. Il/Elle ne peut outrepasser les droits d'origine de l'une ou l'autre génération et ne peut en aucun cas réduire l'obligation de licence applicable.
EDIT 2 L'ajout d'une lecture intéressante - les licences GPL et MPL a de graves conflits. Lis ça. http://www.tomhull.com/ocston/docs/mozgpl.html
Vos cinq points sont tous vrai.
L'autre réponse semble supposer que vous incluez l'ancienne licence BSD à 4 clauses .
Si vous interprétez les "licences BSD" comme faisant référence aux variantes à 3 ou 2 clauses les plus couramment utilisées de la licence BSD, les cinq affirmations de la question sont vraies.
Si tout ce qui précède est correct, quel est l'intérêt d'utiliser une double licence MIT/BSD?
Techniquement, cela ne devrait pas être nécessaire. L'un ou l'autre peut être utilisé dans les mêmes situations.
Même si le BSD fait référence à la version à 3 clauses, un utilisateur ne peut-il pas légalement choisir de ne respecter que la licence MIT?
Cela semble correct.
Il semble que si vous voulez vraiment que la clause "sans approbation" s'applique, vous devez la concéder sous licence uniquement BSD (pas double). Si vous ne vous souciez pas de la clause "sans approbation", alors MIT seul est suffisant et MIT/BSD est redondant.
C'est vrai. Si vous vous souciez de cette clause particulière, il ne serait pas logique de concéder également le même travail sous des licences sans cette clause.
De même, étant donné que les licences MIT et BSD sont toutes deux "compatibles GPL" et peuvent être redistribuées dans des projets sous licence GPL, la double licence MIT/GPL semble également redondante.
Oui.
Bien que, parfois, un produit logiciel prétendra avoir une double licence en tant que MIT et GPL (ou une licence permissive et GPL), mais en réalité, il fait référence à deux versions différentes du logiciel.
Par exemple, certains logiciels peuvent être compilés et distribués avec une licence permissive comme BSD ou MIT, mais si vous omettez certaines bibliothèques et donc certaines fonctionnalités, il peut être distribué sous GPL. Les bibliothèques omises seront généralement des bibliothèques tierces qui ne sont pas compatibles avec la GPL mais qui pourraient autrement être distribuées.