开源许可证的比较

本文翻译自 THE KIUWAN TEAM 的文章 Open Source Licenses: A Comparison Of The Most Popular Types

开源许可证主要有两种类型：Copyleft 和 Permissive。在本文中，我们将比较这两种类型的许可证，并查看每类许可证的示例。

Copyleft 和 Permissive 许可证：有什么区别？

Copyleft 和 Permissive 许可证都允许开发人员自由地复制、修改和重新分发代码。但是，两者之间最重要的区别在于它们各自如何获得版权特权。

Permissive 许可证允许开发人员包括其自己的版权声明，但 Copyleft 许可证不提供此类特权。相反，Copyleft 许可规则要求所有衍生作品必须服从原始许可。这意味着开发人员无法对原始软件提出专利或版权主张。

根据 White Source 的研究，最受欢迎的 Permissive 许可证是 MIT 和 Apache 2.0，而 BSD 排在第三位。GNU GPLv3 则是目前最流行的 Copyleft 许可证，但比起 Permissive 许可已逐渐失去市场份额。

MIT

MIT 开源许可证在本质上是 Permissive 许可证，也是众多许可证中最简单的一个。它基本上允许开发人员根据自己的喜好修改或重新校准源代码。

MIT 许可证始终包含版权声明和免责声明，这说明该软件按“原样”提供，并且版权所有者不承担任何索赔或责任。MIT 许可证的持有者可以不受限制地从原始软件中产生任何衍生作品，甚至可以从二手产品的销售中获得商业利益。

MIT 许可证与 GPL 兼容，但与传统的限制性 GPL 不同，它不是“病毒式”的。这意味着开发人员可以修改原始代码，而不会用原始许可证“感染”生成的派生代码。

Apache 2.0

这个许可证于 2004 年发布，取代了原来的 Apache 1.1 版本。与修改后的 BSD 和 MIT 许可证一样，Apache 2.0 在本质上是 Permissive。

Apache 2.0 版本明确定义了什么是法律实体、衍生作品和贡献。它还明确规定了围绕专利权授予的条款，这在 BSD、Apache 1.1 和 MIT 许可证中都是没有的。值得注意的是，如果对任何实体提起专利侵权诉讼，那么在 Apache 2.0 下授予开发者的所有专利许可将在诉讼提起之日终止。

Apache 2.0 许可证对再分配权也有严格的规定。它特别要求任何衍生作品的接受者必须提供一份 Apache 2.0 许可证的副本。最值得注意的是，开发者必须提供明确的声明，以验证文件已经被修改。任何衍生作品的源码形式也必须保留原始软件源码形式的所有版权、专利和归属声明。

最后，如果原始作品包括归属声明（在 NOTICE 文本文件中），开发者必须确保衍生作品也包括 NOTICE 文件。开发者也要在上述文件中包含自己的归属声明和版权声明。如前所述，新修改的 BSD 许可证并不涉及专利权问题，因此，Apache 2.0 关于专利权和再分发权的明确定义的规则显然是独一无二的。

BSD/3-Clause BSD

这些 Permissive 的开源许可证类似于 MIT 许可证，但有一个小而重要的区别：虽然它们包括相同的版权和免责声明，但它们还提供了一个额外的非归属条款，以保护软件的原始创作者。这个条款被非正式地称为”非认可条款”。它要求开发者在使用原创作者的名字来推广衍生产品之前，必须获得明确的许可。

3-Clause BSD 还要求以二进制形式重新分发的软件必须包含原始版权声明、免责声明和所需条件列表。

本质上，3-Clause BSD 许可证是对原来的 4-Clause BSD 许可证的新修改。在 3-Clause BSD中，”广告条款”被省略了，它要求所有提到使用该软件的广告都要承认 UCLA Berkeley 及其贡献者的作者身份。

这个 “广告条款”使归属合规过程变得繁琐，最终导致 4-Clause BSD 许可证与 GNU GPL 不兼容。1999 年 7 月 22 日，该条款被取消。到目前为止，2-Clause 和 3-Clause BSD 许可证均省略了”广告条款”，使其与GPL兼容。

值得注意的是，Net BSD Project(涉及伯克利设计的类 Unix 的操作系统)采用了 2-clause BSD 许可证。

GPLv3

GPL（通用公共许可证）是最流行的版权许可证。FSF（自由软件基金会）致力于确保 GPL 保护所有用户以他们认为合适的方式修改和发布代码的自由。

GPL 基于四项自由：为任何目的使用源代码的自由、进行修改的自由、与任何人分享源代码的自由，以及分享修改的自由。

与公众的看法相反，GPL 并不禁止用户出售基于原始源码的衍生作品，它只是要求源码必须免费提供给任何想要它的人。这就是”对等义务”。

到目前为止，GPLv3 取代了 GPLv2。最值得注意的是，GPLv3 现在与其他许可证兼容，如 Apache 2.0。根据 FSF 的说法，GPLv3 还通过三种方式保护用户，使其区别于其他开源许可证。

• 首先，它禁止对源代码进行操作，防止终端用户进行修改。
• 其次，GPLv3 符合国际法律的宗旨，如《数字千年版权法》和《欧盟版权指令》。这使得外国开发者更容易在美国之外使用该许可证。
• 第三，新的 GPLv3 可以防止微软等公司侵犯专利权。而且避免了因使用自由软件而收取版税。

到目前为止，FSF 还发布了方便在服务器上运行的程序的 Affero GPL 和 LGPL（Lesser General Public License），LGPL 是 GPLv3 的一种更为宽松的形式。

管理项目中的开源许可证

似乎每个开源库都有自己不同类型的许可证。当你开发一个拥有数百个库的应用程序时，跟踪所需的许可证可能会成为一个令人头痛的问题。但准确的许可证管理对于避免潜在的法律问题至关重要。因此源代码分析工具（SCA）是必不可少的。

源代码分析工具可以帮助你快速、轻松地管理项目中的开源库。只需点击几下，你就可以在构建过程中或在应用程序中生成一个准确的组件清单。您将获得关于您的开源组件的详细信息，包括：

• 需要哪些许可证；
• 是否有任何部件过时或未使用；
• 在使用中是否存在安全风险。

降低了使用开源组件带来的风险。