在上一篇文章中，我讨论了版权的基本原则以及它们与GPL和LGPL等软件许可证的关系。这一次，让我们来看看 "开源 "和 "自由软件 "许可证之间的互动。具体来说，不同许可证之间的潜在不兼容性会如何影响你自己的开发工作？
许可证还是合同？
GNU通用公共许可证（GPL）可能是 "自由软件 "许可证中最著名的一种。有两个版本的GPL至今仍在使用。GPLv2和GPLv3。(还有 "较小的 "GPL或LGPLv2和LGPLv3，它们通常用于图书馆，并对其相应的GPL版本的条款稍作修改）。这些许可证的目标是促进 "copyleft"--即源代码必须免费提供给任何希望使用、修改或重新发布GPL许可证软件的人。
虽然被称为 "许可证"，但美国的一些法院表示，GPL的 "自由复制 "目标使其成为一种 "合同"，规定了超出正常版权许可范围的义务。例如，加利福尼亚的一位联邦法官最近认为，美国版权法并不妨碍GPL的第三方受益人在州法院提出违约索赔。这起名为 "软件自由保护协会诉Vizio公司"的案件，涉及的是对某一设备制造商的指控。涉及的指控是，"智能电视 "的制造商使用了根据GPLv2和LGPLv2许可的软件，但没有按照许可证的要求向第三方发布全部源代码。
该制造商认为该案应被驳回，因为根据美国法律，只有版权持有人--即软件的原始开发者--才能起诉侵权行为。但法官驳回了这一观点，指出GPLv3和LGPLv3明确为第三方创造了 "接收源代码 "的权利，这实际上违背了版权的传统功能，即 "限制谁可以复制 "受保护作品。
在 "混合 "软件许可证之前，你需要知道什么？
把GPL和LGPL看成是合同，也有助于说明许可证不兼容的概念。合同规定了该协议各方的某些义务。如果任何一方后来的行为违反了这些义务，他们可能会被发现违反了合同。
GPL本身是一个相当长的文件--超过5,600字--而且大多数软件开发人员没有受过阅读或理解法律 "代码 "的训练。但其基本思想很简单：如果你收到任何根据GPL许可的代码，并选择以任何方式修改和重新发布它，你也必须发布你的修改的源代码。
GPL的目的是防止在 "专有 "应用程序中使用授权代码，即开发者只向用户提供可执行的二进制文件或 "目标代码"，而不提供附带的源代码的软件。如果你问许多 "自由软件 "倡导者，他们可能会告诉你，他们想创造一个所有软件都以这种方式在GPL条款下独家授权的世界。
当然，这并不是我们所处的世界。许多开发者选择在不对后续用户施加任何重大互惠义务的条款下许可他们的软件。像MIT和Apache这样的 "允许性 "许可证通常只需要在他们的代码中包括一个确认原始开发者版权的通知。否则，接受者可以自由地对授权代码做任何事情--包括在一个专有的应用程序中使用它。
那么，当你混合使用GPL和非GPL代码时会发生什么？根据GPL的条款，你仍然必须遵循适用于其许可证的所有规则。否则，其他许可证可能被视为 "不兼容"。同样，如果其他许可证包括它自己的额外限制，这也可能使它与GPL不兼容。
请记住，自由软件基金会--GPL的作者--可能会声称许可证不兼容，但这并不意味着这些问题已经被法院审理或裁决。尽管如此，作为一个开发者，你可能希望本着诚意行事，不要将GPL许可的代码与另一个被指称不兼容的许可结合起来。你还需要考虑到，如果你采用的许可证与GPL有潜在的冲突，这将阻止其他人使用或纳入你对GPL许可的代码所作的任何修改。
但实际上是什么造成了不兼容？在许多情况下，这可能是看似微不足道的语言。例如，Python的旧版本--我们说的是1.6到2.1--有一个许可证，其中规定其条款受弗吉尼亚州的法律管辖。FSF 认为这与 GPL 不相容，GPL 不包含任何这样的条款。(现代 Python 是在 Python 软件基金会许可证下发布的，FSF 认为它与 GPL 兼容。)
FSF 认为造成 GPL 不兼容的其它理由包括：
- 要求用户在重新发布软件之前单独获得原作者的许可。
- 禁止用户出售软件的拷贝（或限制他们对这种拷贝的价格）。
- 将软件的使用限制在某些类型的组织或目的；以及
- 许可证的条款非常模糊，以至于不能轻易地确定与GPL的兼容性。
你会注意到在这个列表中，有一项是说GPL并不限制你对使用GPL许可的代码开发的软件副本进行收费。事实上，与许多人的想法相反，"自由软件 "许可证并不要求你把你的作品送出去。它也不禁止你在你的作品基础上开发商业应用。在下一篇文章中，我将更详细地解释这个问题，包括为什么有些软件--如PyQt和Qt本身--是在 "双重 "许可计划下发布的。
