MIT，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双重许可似乎也很多余。

— 瑞安夫
source

您可以提供MIT + BSD许可证示例吗？对于在两个类似的宽松许可下的双重许可，通常是多余的，但我已经看到双重许可被滥用为明确声明可以在每个许可下重新分发代码的一种方式。

— yannis

@Yannis Yea我想知道人们是否双重许可他们，以便对不认识的人更加明确。但是我认为这只会使他们感到困惑。

— ryanve

有趣的阅读：tomhull.com/ocston/docs/mozgpl.html

— Mehta

相关：如何比较开放源代码许可证？

— t 2014年

根据我的经验，人们主要将双重许可用于不兼容的许可。例如MPL +（L）GPL或无版权的有偿许可，以及（A）GPL。

— CodesInChaos

Answers:

我的理解是：

MIT许可的项目可以在BSD许可的项目中使用/分发。
正确（但除非进行修改，否则用户也可以从原始来源获得它。
BSD许可的项目可以在MIT许可的项目中使用/分发。
FALSE MIT许可证允许分发而无需贡献学分；BSD没有。
MIT和BSD 2子句许可证基本相同。
否参见上文。
BSD 3子句= BSD 2子句+“无认可”子句
TRUE
颁发双重许可证允许用户从这些许可证中进行选择，而不必两者都绑定。
正确（我认为是！）

同样，由于MIT和BSD许可证都是“ GPL兼容”的，并且可以在GPL许可的项目中重新分发，因此MIT / GPL双重许可似乎也很多余。

NO。这是一个主要区别。MIT许可证和Apache许可证仅要求您将信用归原始版权持有者所有。如果选择，则可以重新分发源。但是如果您选择，则可以保留新的衍生产品而无需打开代码。因此，可以使用在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 Mehta）
source

@Dipan如果一个项目是根据MIT / GPL双重许可的，则可以在专有项目b / c中使用它，用户可以选择仅遵循MIT。如果项目仅持有MIT许可证，则可以在其他许可证（包括GPL）下进行重新分配。这就是我所说的多余。

— ryanve

@DipanMehta＃2中的“贡献积分”是什么意思？听起来您是在指BSD 4子句许可证，而FSF并未像3子句和2子句那样对它进行验证。我说的是3子句和2子句，在这种情况下，我很确定所有5条陈述都是正确的。

— ryanve

您可以将BSD许可的代码与MIT许可的代码结合使用。您只需要在项目的材料中提及“ BazApp使用libfoobar，它根据BSD许可证进行分发”或类似的东西。BSD和MIT许可证适用于每个文件级别，而不是每个项目级别。

— mipadi

@Dipan_Mehta正如ryanve告诉您的那样，您在谈论原始的4子句BSD许可证，而OP在谈论修订的3子句和2子句BSD许可证。2条款BSD许可证实际上等同于MIT许可证。甚至OSI页面也是如此。

第二点（BSD代码不能包含在MIT代码中）与我所读过的有关3子句和2子句BSD的每条信息相反。关于（现在已经被遗忘的）4子句BSD，第2点是正确的，但是OP明确表示这个问题不是关于4子句的BSD。在一个非常好的和可信的答案中拥有如此巨大的误导性信息似乎是非常有害的。

— apsillers'Apr

你的五点都是对的。

另一个答案似乎是在假设您包括较旧的，很少使用的4条款BSD许可证。

如果您将“ BSD许可证”解释为是指BSD许可证的更常用的3子句或2子句变体，那么问题中的所有五项声明都是正确的。

如果以上所有方法均正确，那么使用MIT / BSD双重许可证有什么意义？

从技术上讲，不需要它。两种都可以在相同的情况下使用。

即使BSD引用了3子句版本，用户也不能合法选择仅遵守MIT许可证吗？

听起来很正确。

看来，如果您确实希望应用“不认可”子句，则必须仅将其许可为BSD（不是双重许可）。如果您不关心“不认可”子句，那么仅MIT就足够了，而MIT / BSD就是多余的。

那就对了。如果您关心该特定条款，那么在没有该条款的情况下在许可下也许可相同的作品是没有意义的。

同样，由于MIT和BSD许可证都是“ GPL兼容”的，并且可以在GPL许可的项目中重新分发，因此MIT / GPL双重许可似乎也很多余。

是。

尽管有时某个软件产品会声称自己已获得MIT和GPL的双重许可（或某些许可许可和GPL），但实际上，它们是指两种不同版本的软件。

例如，某些软件可以使用BSD或MIT这样的许可许可证进行编译和分发，但是如果您省略了某些库，因此省略了某些功能，则可以将其作为GPL分发。省略的库通常是与GPL不兼容的第三方库，但仍可以通过其他方式分发。

— 胸腺
source