MIT许可证与GPL许可证的区别

Question

MIT许可证与GPL许可证的区别

licensing

122

MIT许可证兼容GPL。那么GPL许可证是否兼容MIT？即我可以在GPL许可的产品中包含MIT许可的代码，但我可以在MIT许可的产品中包含GPL许可的代码吗？

在我看来，MIT许可证和GPL之间的主要区别是，MIT不要求修改后的代码开源，而GPL则要求。这是正确的吗？GPL比MIT许可证更加严格吗？

- fruzer

1

该许可证也与GPL兼容，这意味着... - Michael Petrotta

4个回答

45

我能。GPL和MIT都是自由软件，两个许可证都不会限制你将代码结合在一起，而"include"总是双向的。在版权方面，对于组合作品（即两个或更多个作品共同形成一个作品），一个作品是否比另一个作品“更大”并没有太大的区别。因此，如果您在MIT许可的产品中包含GPL许可的代码，那么同时您也会在GPL许可的代码中包含MIT许可的产品。作为第二个意见，OSI列出了以下标准（更详细）适用于两个许可证（MIT和GPL）：

自由再分发
源代码
派生作品
作者源代码的完整性
不歧视个人或团体
不歧视努力的领域
许可证的分发
许可证不得特定于某个产品
许可证不得限制其他软件
许可证必须是技术中立的

两者都允许创建组合作品，这就是您所询问的内容。如果认为将两个作品合并被视为衍生作品，那么这也不会受到两个许可证的限制。而且，两个许可证都不限制软件的分发。

我认为MIT许可证和GPL之间的主要区别在于，MIT不要求修改后的代码开源，而GPL则要求。

GPL并不要求你只是因为你修改了软件就必须公开发布。这并不准确。

你可能会将此与在GPL下分发软件混淆，这并不是你直接询问的内容。

这正确吗 - GPL比MIT许可证更具限制性？

这是我的理解：

就分发而言，你需要将整个软件包放在GPL下。软件包中的MIT代码仍将在MIT下可用，而如果没有更高的权利限制，则GPL适用于整个软件包。

“限制性”或“更具限制性”/“不太具限制性”取决于很多因素。对于一个软件用户来说，MIT可能会导致比在GPL下可用的软件更受限制，即使现在有些人称GPL更具限制性。该特定用户将称MIT更具限制性。这只是主观的，不同的人会给出不同的答案。

由于谈论不同许可证的限制只是主观的，因此您应该考虑您想要实现什么：

如果您想限制您的修改使用，则MIT在分发方面可能比GPL更具限制性，这可能是您要寻找的。
如果您想确保您的软件的自由度不会被您分发给的用户太多地限制，那么您可能希望使用GPL而不是MIT发布。

只要你是作者，你就可以决定。

因此，最具限制性的人永远是作者，无论任何许可证。

- hakre

13

虽然你在后面的回答中作了澄清，但最初声称“你可以”将GPL许可的代码包含在MIT许可的项目中是非常具有误导性的。一旦包括了仅在GPL下可用的代码，原始的MIT许可项目就不能再作为一个整体以MIT许可证的形式进行分发。 - antinome

3

声称限制性是主观的也是误导性的。询问“我可以合法地使用这些文件执行哪些操作？”是一个合理且非主观的问题。在GPL下，这组操作实际上是MIT下那些操作的一个适当子集。 - antinome

1

@hakra：在MIT许可的项目中包含GPL许可的代码是不可能的，因为即使您不分发它，结果整体也不再是MIT许可。（如果是这样，那么MIT许可的条款将允许您分发它！） - antinome

9

一个使用MIT许可证的应用程序可以包含GPL代码，但生成的应用程序将不是MIT许可证下的。 - antinome

1

@hakre，你在MIT许可证中看到了哪些要求不在GPL中？ - JosephH

显示剩余16条评论

16

您说得没错，GPL比MIT许可证更加严格。

您不能在MIT许可证的产品中包含GPL代码。如果您分发一个组合作品，其中组合了GPL和MIT代码（除非在某些特定情况下，例如“单纯聚集”），则该发行必须符合GPL。

您可以在GPL产品中包含MIT许可证的代码。整个组合作品必须以符合GPL的方式分发。如果您对MIT代码的部分进行了更改，则在分发包含GPL和MIT代码的应用程序时，您需要发布这些更改的源代码。

- JosephH

3

除非该项目采用双重许可证，例如jquery。 - buggedcom

7

@buggedcom - 你可以给原先是MIT协议的部分设置双重许可证，但是你不能对一个结合了MIT/GPL许可证的库进行双重许可证授权——它必须仅在GPL下获得许可（因为将GPL许可证的部分更改为MIT许可证违反了GPL条款）。在jQuery的情况下，代码的版权所有者发布了双重许可证，所以这不成问题；但如果他们从其他地方“借用”了一些GPL代码，则无法再使用MIT许可证授权结合作品。 - Mark H

据我所知，这并不完全正确。根据自由软件基金会的说法，GPL与MIT许可证是兼容的[1]。不幸的是，这并不能改变项目本身不再完全受MIT许可证保护的事实...这正是人们通常期望的。您将无法在商业环境中作为整体使用该项目而不发布代码。为避免混淆，最好不要在MIT许可的项目中包含GPL代码。然而，您不能这样做是错误的。[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses - tcurdt

...但我猜这取决于你如何定义“产品”。 - tcurdt

2

一个使用MIT许可的产品（也许“应用程序”是更好的词）不能包含GPL代码。你可以将GPL代码添加到MIT产品中，但生成的应用程序只能在GPL许可下分发。我从未见过有人将只能在GPL条款下分发的应用程序描述为“MIT许可的产品”。如果许可证不“兼容”，则根本无法生成组合作品-它们兼容的事实意味着您可以生成组合作品，并且可以分发并获得GPL许可。 - JosephH

重点是：如果您包含GPL许可的代码，则它不再是MIT许可的产品。该产品可以包括GPL代码，但是您不能在MIT许可下分发它。这有一个微妙的区别。如果您将答案更改为“您不能包含GPL代码并在MIT许可下分发组合作品”，那么它将是正确的，并且与我给出的答案相匹配 ;) - tcurdt

5

我不是律师，但我认为......

虽然你可以将GPL和MIT代码组合在一起，但GPL是有污染性的。这意味着整个软件包都受到GPL的限制。由于这更具限制性，因此您不能再将其用于商业（或封闭源）软件中。这也意味着，如果您有一个MIT/BSD/ASL项目，您将不想添加对GPL代码的依赖。

添加GPL依赖项不会改变您代码的许可证，但它将限制人们对您项目的工件所能做的事情。这也是ASF不允许其项目依赖于GPL代码的原因。 http://www.apache.org/licenses/GPL-compatibility.html

- tcurdt

1

实际上，微软非常准确地指出了这个问题，GPL是一种病毒式的许可证，因为它将每个项目都变成了开源项目。 - magallanes

10

这并不是一个“问题”。GPL 是按设计具有传染性的。它旨在供希望使其代码对其他人免费使用的人使用，但也要求其他人发布该软件或其派生版本时以同样的方式尊重用户。 GPL 关注的是用户，而不是公司通过强制垄断来实现利润最大化，因此它的递归性实际上是它的美丽和力量，而不是微软可以“完美地准确定位”的“问题”。认识到 GPL 具有传染性不需要特殊的洞察力~维基百科就足够了。 - Carl Smith

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ravi Jayagopal · Accepted Answer

在我看来，MIT许可证和GPL之间的主要区别在于，MIT不要求修改后的代码公开发行，而GPL则要求。

事实上，在使用GPL时，您不必开源自己的更改，只要您不进行分发。但是如果您确实进行了分发，则使用GPL代码的整个项目也会自动成为GPL。这意味着它必须开源，并且接收者拥有与您相同的权利，即他们可以转发、修改、出售等。这将包括您的专有代码，这些代码将不再是专有的 - 它们将变成开源的。

而MIT的区别在于，即使您实际分发使用MIT许可的代码的专有代码，您也不必将代码开源。您可以将其作为加密或二进制文件的封闭应用程序进行分发。包括MIT许可的代码可以被加密，只要它带有MIT许可证通知即可。

“GPL比MIT许可证更加严格吗？” 是的，非常严格。