可以在BSD许可的项目中使用/分发MIT许可的项目。
在BSD的许可项目中可以使用/分发的BSD许可项目。 MIT许可的项目。
MIT和BSD 2子条款的许可证基本相同。
BSD 3子条款= BSD 2子条款+“无背书”条款
颁发双重许可证允许用户从那些许可证中进行选择，而不必两者都绑定。
如果上述所有方法都正确，那么使用MIT / BSD双重许可证有什么意义呢？即使BSD引用了3子句版本，用户也不能合法选择仅遵守MIT许可证吗？
看来，如果您真的想应用“无背书”子句，则必须将其许可为BSD（不是双重许可）。如果您不关心“不认可”子句，那么仅MIT就足够了，而MIT / BSD就是多余的。
同样，由于MIT和BSD许可证都是“ GPL兼容”的，并且可以在GPL许可的项目中重新分配，因此MIT / GPL双重许可似乎也很多余。
#1 楼
我的理解是：
MIT许可的项目可以在BSD许可的项目中使用/重新分发。TRUE（但除非进行修改，否则用户也可以从原始来源获得它。
BSD许可的项目可以在MIT许可的项目中使用/重新分发。FALSEMIT许可允许在没有贡献额度的情况下进行分发； BSD不允许。 BSD 2子句许可证基本相同。FALSE请参见上文。
BSD 3子句= BSD 2子句+“无背书”条款TRUE
颁发双重许可证允许用户从这些许可证中进行选择-不能同时绑定到两者。TRUE（我认为是这样！）
同样，由于MIT和BSD许可证都是“兼容GPL”的，可以在GPL中重新分发许可项目，然后进行双重许可
MIT / GPL似乎也很多余。
不，这是主要区别。MIT许可和Apache许可只要求您对原始版权持有人s。如果选择，则可以重新分发源。但是如果您选择，则可以保留新的衍生产品而无需打开代码。因此，可以使用在MIT和Apache下开发的代码-获得商业许可。
如果您曾经在基于GPL的许可证中使用代码并且碰巧对其进行了修改，则您还必须在GPL下分发修改后的代码。换句话说，一旦在项目下使用了任何GPL代码库，并且想要将其作为产品发布，则必须与源代码一起发布，并且必须在GPL下发布。它永远不能是商业许可证或封闭源代码，也不能是比GPL更严格的任何其他许可证。
例如，可以获取根据GPL修改和分发的MIT，Apache或BSD许可证代码。一旦将代码库作为GPL分发，则其进一步的派生版本不能在MIT，Apache或BSD许可下分发，而只能是GPL。
编辑：
双重许可的示例案例：假设Nice Office是在MIT和GPL双重许可下发布的。它有两种可能性。某些人可以创建NicePro Office，该软件可以商业销售。而其他一些开源社区创建了一个分叉NiceOpen Office。在这种情况下，它可以强制执行GPL发行版（原始Nice Office以及NiceOpen Office版本），因此，如果您从NiceOpen Office开始，则必须仅遵守GPL，而不是MIT许可。
关键是在双重许可的情况下，获得许可的第一个人可以选择。他可以选择任何一种方式-但是，第二个人需要坚持第一个人的选择。他/她不能超越任何一代人的原始权利，也不能以任何方式减少适用许可证的义务。
编辑2
添加有趣的内容-GPL和MPL许可证存在严重冲突。读这个。 http://www.tomhull.com/ocston/docs/mozgpl.html
评论
@Dipan如果一个项目是根据MIT / GPL双重许可的，则可以在专有项目b / c中使用它，用户可以选择仅遵循MIT。如果项目仅持有MIT许可证，则可以在其他许可证（包括GPL）下重新分发。这就是我所说的多余。
–ryanve
2011年11月28日在8:13
@DipanMehta＃2中的“贡献积分”是什么意思？听起来您所指的是BSD 4子句许可证，它没有像3子句和2子句一样经过FSF的验证。我说的是3子句和2子句，在这种情况下，我很确定所有五个陈述都是正确的。
–ryanve
2011年11月28日在8:20
您可以将BSD许可的代码与MIT许可的代码结合使用；您只需要在项目的材料中提及“ BazApp使用libfoobar，它是在BSD许可下分发的”或类似的东西。 BSD和MIT许可证适用于每个文件级别，而不是每个项目级别。
– mipadi
2011年11月28日15:51
@Dipan_Mehta正如ryanve告诉您的那样，您在谈论原始的4子句BSD许可证，而OP在谈论修订的3子句和2子句BSD许可证。 2条款BSD许可证实际上等效于MIT许可证。甚至OSI页面也是如此。
–user54062
2012年5月15日上午10:15
第二点（BSD代码不能包含在MIT代码中）与我所读过的有关3子句和2子句BSD的每条信息相反。关于（现在已经被遗忘的）4子句BSD，第2点是正确的，但是OP明确表示这个问题不是关于4子句的BSD。在一个非常好的和可信的答案中拥有如此巨大的误导性信息似乎是非常有害的。
–仿制药
2015年4月2日在22:13
#2 楼
您的5点都对。另一个答案似乎是在假设您包括较旧的，很少使用的4条款BSD许可证。
如果您解释“ BSD许可证”提到BSD许可证中比较常用的3子句或2子句变体，问题中的所有5个声明都是正确的。
如果以上所有内容都是正确的，则使用双重MIT / BSD许可证有什么意义？
从技术上讲，不需要它。两种都可以在相同的情况下使用。
即使BSD引用了3子句版本，那么用户不能合法选择仅遵守MIT许可证吗？ br />
听起来是正确的。
看来，如果您真的希望应用“不认可”子句，则必须将其许可为BSD（非双重）。如果您不关心“不认可”子句，那么仅MIT就足够了，而MIT / BSD就是多余的。
是的。如果您关心该特定条款，那么在没有该条款的情况下也要根据许可来许可相同的作品是没有意义的。
同样，由于MIT和BSD许可证都是“ GPL-兼容”，并且可以在GPL许可的项目中重新分发，因此MIT / GPL双重许可似乎也很多余。
是的。
虽然有时是软件产品将声称自己拥有MIT和GPL的双重许可（或某些许可和GPL），但实际上它们是指该软件的两个不同版本。例如，某些软件可以编译并使用BSD或MIT之类的许可许可证进行分发，但是如果您省略了某些库以及某些功能，则可以将其作为GPL分发。省略的库通常是与GPL不兼容的第三方库，但仍可以通过其他方式分发。
评论
您可以提供MIT + BSD许可证示例吗？在两个类似的宽松许可下，双重许可通常是多余的，但我已经看到双重许可被滥用为明确声明可以在每个许可下重新分配代码的一种方式。@Yannis Yea我想知道人们是否双重许可他们，以便对不认识的人更加明确。但我认为这只会让他们感到困惑。
有趣的阅读：tomhull.com/ocston/docs/mozgpl.html
相关：如何比较和对比开放源代码许可证？
根据我的经验，人们主要将双重许可用于不兼容的许可。例如MPL +（L）GPL或无版权的有偿许可与（A）GPL一起。