一文读懂常用开源许可证

社区时常为流行产品中有争议的开源许可证而感到震惊，这引起各方关注，纷纷争论何为真正的开源许可证。去年，Apache 基金会（Apache Foundation）禁止使用 Facebook React 那些具有争议的专利组件，这引发了轩然大波，并让大量人员纷纷跑去加入 Reddit boards。在过去的几个月中， Redis Labs 和 MongoDB 修改了他们备受欢迎的开源数据库的许可证，这让许多人难以自拔，凸显了用大家都能看懂的人话来具体介绍常见开源许可证的紧迫性和必要性。

最简单的解释是，开源许可证（open source licenses）是软件组件（software component）的作者与用户之间的具有法律约束力的合同（legal and binding contracts），声明该软件可以在指定条件下（under specified conditions）用于商业应用（be used in commercial applications）。许可证使得代码变为开源组件。没有开源许可证，便无法将该软件组件给他人使用，即便该组件公开发布于 GitHub。

每个开源许可证都会声明用户被允许使用该软件组件用于何用途、义务、以及条款规定的不可用于哪些用途。这听起来似乎很简单，但开源许可证存在至少 200 个——祝你好运，希望你能搞懂它们。由于复杂性和不同要求，组织需要选择哪些许可证以便与它们的政策最兼容，确保合规。

Copyleft 与 Permissive

两种类型的开源许可证

开源许可证的两个主要类别需要深入说明，开源许可证分类两大类：copyleft 和 permissive，该划分基于许可证对于用户的要求与限制（requirements and restrictions）。

版权（Copyright）是一种法律，它赋予了版权所有者限制他人使用、修改与共享创意作品的权利，使用者要使用、修改或共享创意作品，便需要版权所有者的许可。诸如音乐、电影等，都是它们的创作者的知识产权。当作者以 copyleft 许可证发布程序时，他们主张对该作品的版权（make a claim on the copyright of the work），并声明只要保持权利对等（reciprocity of the obligation），其他人便有权使用、修改和共享该作品。简而言之，如果他们使用具有这种类型开源许可证的组件，那么他们也必须开放其代码以供他人使用。

宽松开源许可证（Permissive open source licenses）是一种非版权保留（non-copyleft）的开源许可证，可以保证使用、修改、重新分发的自由，同时还允许用于具有专利的派生作品之中。宽松开源许可证被亲切地称为「Anything Goes」（为所欲为），对他人如何使用开源代码组件设置了最小的限制（place minimal restrictions）。这意味着这种许可证允许自由地使用、修改和重新分发开源代码，允许用于专利作品中，并对此不求回报。

备忘

了解顶级开源许可证

首先要强调的是，没有什么「好的许可证」，也没有什么「不好的许可证」，而且也不存在「一个许可证比另一个许可证更好」的情况。任何人都可以创建适合他们自己喜好的开源许可证，这就是为何有这么多许可证存在的原因了。这可能会是如何选择开源许可证变得复杂，特别是对于那些对法律不太熟悉、也从未得到过对开源许可证的详尽解释的人。为缩小决策范围并充分理解它们，OSI 汇总了一份已批准的许可证清单，其中包括 80 多个最常用的开源许可证。

在 OSI 清单内的几十个开源许可证之中，其中有一些占据着上风，且被一些最受欢迎的开源项目所使用。我们汇总了这份简要清单，罗列了一些常用的开源许可证。

GNU 通用公共许可证（GPL）

GNU 通用公共许可证（The GNU's General Public License）是最受欢迎的开源许可证。理查德·斯托曼（Richard Stallman）创建了 GPL，以保护 GNU 软件免于被申请专利，这是他对「copyleft」概念的理解和实现。

GPL 是 copyleft 许可证，这意味着任何基于 GPL 组件编写的任何软件都必须开源发布。其结果是任何使用 GPL 开源组件（无论其在整个代码中占比多少）的任何软件都必须释出（release）其完整的源代码，以及修改和分发整个代码的所有权利。

关于什么构成「某作品基于另一作品」一直存在这混淆，因为这会触发 GPL 的对等义务。自由软件基金会（FSF）试图通过 GPLv3 使「何时会触发对等义务」变得更清晰。基金会甚至为此编写了新的 GPL 许可证—— Affero 许可证——以解决被称作「ASP loophole」的特定混乱。

此外，自由软件基金会还试图增加 GPLv3 许可证与其他许可证的兼容性。只要两个程序都允许，就可以把这两块代码组合成一个更大的作品。如果两个程序的许可证都授予了此类权利，则它们是兼容的。通过使 GPLv3 变得更兼容，自由软件基金会扩展了开发选项。

第三个区别是 GPLv3 的目的是提高全球的使用率。与 GPLv2 所使用的语言是以美国为中心的不同，GPLv3 改进了用于描述许可的语言，以确保国际法律能理解自由软件基金会的目的。此外，GPLv3 还允许开发人员添加本地免责声明（local disclaimers），这有助于增加其在美国以外的国家和地区使用。

Apache 许可证

Apache 许可证是由 Apache 软件基金会（ASF）发布的开源软件许可证。这是一个背靠强大社区的、流行的、广泛部署的开源许可证。Apache 许可证允许你自由使用、修改和分发任何使用了 Apache 许可证的产品，但当你这么做时必须遵守 Apache 许可证的条款。

Apache Group（后改名为 Apache 软件基金会）在 1995 年发布了其许可证的第一个版本，但很少能遇到仍然使用该许可证的软件组件。

在 2000 年，当伯克利（Berkeley）接受自由软件基金会（Free Software Foundation）提出的观点，并从 BSD 许可证中移除广告条款形成修改的 BSD 许可证（或称 The 3-Clause BSD License）时，Apache 也这么做了，并创建了 Apache 许可证 1.1 版本。

移除广告条款，意味着当你使用了基于 Apache 许可证开源的软件组件时，你的作品的推广信息中不需要包含 Apache 许可证署名——只需要将他们包含在文档中即可。

2004 年 ASF 决定彻底摆脱 BSD 模式，通过授予专利权（patents rights）及对「solid definitions」概念的定义，使其变得更清晰有条理，由此产生了 Apache License 2.0。

Microsoft 公共许可证（Ms-PL）

Microsoft 公共许可证（The Microsoft Public License）是微软为释出开源项目而编写和发布的免费开源软件许可证。

你可以自由地复制（再制造，reproduce）和分发（distribute）签署了 Ms-PL 许可证的原始软件或衍生产品。但在使用时不能使用任何贡献者的名字（contributors' name）、Logo 或商标。Ms-PL 许可证通过「不为你所使用的代码提供任何明确的保证（warranties）或承诺（guarantees，一般与质量有关）」来保护作者，因此如果代码在某些情况下无法正常工作，作者也不必承担任何责任。

当你使用 Ms-PL 许可证分发软件（整体或部分）时，无需分发其源代码。你也可以分发对应的源码，但这不属于一种义务。但是，你必须保留该软件最初的所有版权、专利、商标和所有权声明。

此外，如果你以源码的形式分发软件的任一部分，则只能在 Ms-PL 下通过在分发时包含此许可证的完整副本来执行此操作。如果以编译或目标代码（object code）的形式分发软件的任一部分，则只能在符合 Ms-PL 的任何其他许可证下才能执行此操作。

需要注意的是，Ms-PL 条款和条件文档都非常简短清晰，且使用非常连贯的语言编写。微软希望与开源社区保持清晰和直接的关系，这有助于提高许可证的采用率（正如我们从 BSD 许可证中了解到的那样）。

BSD 开源协议（伯克利软件套件）

BSD 许可证或原始 BSD 许可证（the original BSD License）及其两个变体——修改的 BSD 许可证（又称 The 3-clause BSD License）和简化的 BSD 许可证/FreeBSD 许可证（又称 BSD 2-Clause "Simplified" License）是许可的自由软件许可证系列。

原始 BSD 许可证（或称 The 4-Clause BSD License）还包含广告条款（Advertising Clause）和非认可条款（Non-Endorsement Clause）（在以下问题中提供了关于这些条款的详细说明）。修改的 BSD 许可证（或称 The 3-Clause BSD License）是通过从原始 BSD 许可证中移除了广告条款而形成的。此外，通过从修改的 BSD许可证中移除非认可条款后，形成了简化 BSD许可证/FreeBSD 许可证（或称 The 2-Clause BSD License）。

通用开源和发行许可证（CDDL）

通用开源和发行许可证（CDDL）是由太阳微系统公司（Sun Microsystems）发行的开源许可证，旨在用于替换 Sun 公共许可证（SPL，Sun Public License）。CDDL 许可证被 Sun 公司（现在已被甲骨文公司收购）视作 SPL 的第二版本，此外 CDDL 许可证受到了 Mozilla 公共许可证（MPL，Mozilla Public License）的启发。Sun 公司一直以来都使用 SPL 许可证发行它的自由软件（free software）/开源项目，直到 2004 年才切换到使用 CDDL 许可证。CDDL 许可证通常被称作 MPL 的清洁版本（cleaned up version），旨在促进可重用性（reusability）。

你可以自由地复制（再制造）和分发 CDDL 下软件的任何原始或衍生作品，但你不得删除或修改软件中所包含的任何版权、专利或商标声明。你还必须保留所有许可证声明和属于所有贡献者与初始开发者的描述性信息。

当你以可执行形式（除源码外的其他任何形式）分发软件时，你需要将源代码也置于 CDDL 之下。可执行形式可以以 CDDL 或任何与 CDDL 兼容的许可证发布。

源码中必须包括你的贡献（对原始软件的既有文件和新添文件的内容的增加、修改和删除）。这意味着，如果添加的内容在不包含原始代码的独立文件之中，那么就不必将之置于 CDDL 下进行发布。如果你愿意，你可以放入 CDDL 下，但这不属于你的义务。

此外，不管你分发什么源代码都必须包含 CDDL 的副本。对于你所做的每一个修改（modification），你都必须在所修改的文件内写明自己是修改者，以告知他人。

Eclipse 公共许可证（EPL）

Eclipse 公共许可证（EPL，Eclipse Public License）是由 Eclipse 基金会（Eclipse Foundation）开发的开源许可证，它源自通用公共许可证（CPL，Common Public License）。现在使用 EPL 许可证的 Eclipse codebase 以前都是用 CPL 许可证。

EPL 许可证是 copyleft 许可证。如果你修改了基于 EPL 的组件并将其作为程序的一部分、并以源码的形式分发，则需要在 EPL 许可证下公开修改后的代码。如果你以目标代码（object code）的形式发布，则必须声明可根据需要将源码提供给接收者，同时你也必须共享请求源码的方法。

Eclipse 基金会（Eclipse Foundation）明确指出，在他们看来，与 Eclipse 插件「仅交互或互操作」是不会导致你的代码变为该插件的衍生作品（derivative work）的。

如果你重新分发（redistribute）带有 EPL 组件的程序，就必须包含完整的许可证文本和版权信息。

如果有企业在其商业产品中使用了 TA 的组件，那么 EPL 许可证可以保护作者免受潜在的诉讼和损失。此外，EPL 许可还提供了专利授权。

MIT 许可证