原文：Open source licenses: What, which, and why
作者：JIM SALTER，编译：御坂弟弟

大多数人现在至少听说过开源软件，甚至与其关系密切。同时，开源软件的知名人士对它的名称争论不休，从免费软件到自由软件，再到开源软件，以及上述各种可能的组合。但有一点是每个专家都同意的，那就是如果它没有明确的许可证，它就不是开源软件（或其他什么）。

你不能在没有许可证的情况下公开一堆源代码，然后说 "无论如何，它已经放在那了，任何人都可以得到它"。在世界上大多数国家的版权法的运作方式中，没有明确声明许可证的免费提供的代码，其版权是作者的，作者保留所有权利。这意味着使用未经授权的代码是不安全的，无论是否出版。如果你开始使用它，没有什么可以阻止作者来找你并起诉版权费。

唯一能让你的代码真正成为开源和自由使用的方法就是给它附加一个许可证。最好的办法是在每个文件的头部加上一个注释，写上一个著名的许可证的名称和版本，并在项目的根目录下附上一份完整的许可证副本，命名为 LICENSE 或 LICENSE.TXT。当然，这就引出了一个问题，即使用哪种许可证？为什么？

有几种通用的许可证类型，本文将在各自的章节中介绍它们，并举出这种许可证类型的一个或多个突出的例子。

默认许可 —— 专有，保留所有权利

在大多数司法管辖区，除非另有说明，否则任何代码或内容都自动由作者拥有版权，并保留所有权利。虽然在代码或文档的标题中声明作者和版权日期是一个好习惯，但没有这样做并不意味着作者的权利是无效的。

如果作者在自己的网站、Github 仓库等地方提供内容或代码，无论是没有声明许可还是有明确的版权声明，都会保留该代码的使用权和分发权，即使它很容易被查看或下载。如果你在自己的电脑上执行该代码，你就侵犯了作者的使用权，他们可能会以侵犯其版权为由对你提起民事诉讼，因为他们从未授予你该权利。

同样，如果你复制了该代码，并把它送给朋友，在其他网站上发布、出售或以其他方式在作者最初发布代码的地方以外的任何地方提供，你已经侵犯了作者的发行权，他们有资格对你提起民事诉讼。

请注意，对代码库拥有所有权的作者可以单独授予个人或组织使用该代码的许可。从技术上讲，你永远不会 "购买 "软件，即使它被装在实体中。你实际上购买的是使用软件的许可证 —— 可能包括也可能不包括包含代码副本的物理媒体。

自制的许可证

对于自制许可证的建议，一言以蔽之：不要这样做。

世界上已经有足够多的、被 OSI 认可的开源许可证，几乎所有的人或项目都能找到合适的许可证。编写自己的许可证意味着你的项目、内容或代码的潜在用户将不得不从头开始阅读和理解一个新的许可证。新的许可证将没有经过法庭测试，而许多（虽然不是所有）OSI 批准的开源许可证都经过了测试。更重要的是，你的新许可证将不会被广泛理解。

当一个人或公司想使用一个以 GPL v3、Apache 2.0 或 CC0 为授权的项目时，要弄清楚有关许可证是否以正确的方式授予了足够的权利是相对容易的。向有能力的知识产权律师寻求建议既便宜又方便，因为有能力的知识产权律师应该已经熟悉这些许可证、涉及这些许可证的案例法等等。

相比之下，如果你的项目被授权为 "Joe's Open Source License v1.01"，没有人知道这意味着什么。为使用该许可证的项目提供法律咨询的费用会高得多，而且也很危险，因为知识产权律师需要将许可证的文本评估为一个全新的作品，未经证实和测试。新的许可证可能有不明确的文本、条款之间的无意冲突或者由于作者不理解的法律问题而无法执行。

如果没有选择 OSI 认可的许可证，也会使项目失去某些权利或授权。例如，Google 和 IBM 都向开源项目使用其专利组合的部分内容时提供免版税，而你的项目，无论你认为它有多 "自由"，都可能不符合授权的条件。(IBM 特别将 OSI 许可证的批准列为授予条件。)

OSI 批准的许可证

OSI（Open Source Initiative）维护着一份经批准的开源许可证清单，这些许可证符合 OSI 对 "开放源码 "的定义。用 OSI 自己的话说，这些许可证 "允许自由使用、修改和共享软件"。这些许可证之间有很多重叠，其中许多可能根本就不应该存在。但在某种意义上，它们中的每一个都获得了足够的推动来通过 OSI 许可证的审批程序。

下文将把这个许可证列表分为三类，并列出每一类中一些比较著名的例子。大多数作者不需要阅读和理解 OSI 的整个列表，通常一个通用许可证类型的常见和不常见的变体之间没有太大差异，因此不值得放弃最常用和最容易理解的版本。

强版权许可

Copyleft 许可证是一种允许自由使用、修改和重新发布所涵盖的知识产权的许可证，但前提是原始许可证保持不变，包括原始项目和任何人可能对原始项目进行的任何修改。这种类型的许可证有时被不屑一顾地或害怕地称为 "病毒式" 许可证：就是附加在 Linux 内核、GNU C 编译器和 WordPress 内容管理系统等著名项目上的许可证。

Copyleft 许可证可以是 "强 "或 "弱 "的：强的 Copyleft 许可证涵盖了项目本身和链接到项目中的任何代码。而弱拷贝许可只覆盖原始项目本身，并允许非拷贝许可的代码甚至是专有代码链接到弱拷贝许可项目中的功能而不违反其许可。

一些比较流行的强版权许可证包括：

GPLv2 —— GNU 通用公共许可证允许自由使用、修改和发布所覆盖的代码，但原始许可证必须保持完整，并涵盖原始项目和任何修改。在 GPLv2 中，不需要归属或专利授权，但第七部分指出，如果专利或任何其他原因会使重新分发的代码对接受者无法使用，禁止重新分发 GPLv2 授权的代码。GPL 还要求任何分发项目编译版本的人也要提供原始的源代码，或者是在分发对象代码的同时提供源代码，或者是按要求提供源代码。

GPLv3 —— GNU 通用公共许可证的第三版在大部分意图和目的上与 GPLv2 类似。然而，它对专利的处理方式有所不同。如果在 GPLv2 下重新发布作品可能需要支付专利费，则 GPLv2 禁止这样做。GPLv3 更进一步，明确授予项目贡献者在当时或将来拥有的任何专利的免费使用权。GPLv3 还明确授予接受者破解任何DRM（数字版权管理）代码的权利，防止他们被指控违反《数字千年版权法（Digital Millennium Copyright Act）》或类似的 "防篡改 "法律。

AGPL —— Affero GNU 通用公共许可证实际上是 GPLv3，但增加了一个重要的附加条款：除了为那些收到 AGPL 授权软件副本的人提供 GPL 自由之外，它还为那些在网络上与 AGPL 授权软件交互的用户提供同样的自由。这就防止了个人或公司对一个打算在网络上广泛使用的项目进行重大的有价值的修改，并拒绝将这些修改免费提供。

因为要向一个对 copyleft 还不是很熟悉的人解释 AGPL 的影响有点困难，下面将多用些笔墨。为了更好地理解它的影响，本文将例举一个真实的 AGPL 授权项目和一个涉及到可能希望采用它的大公司的虚构场景。

 基于网络的文件共享套件 Nextcloud 是一个 AGPL 授权的项目。由于它采用 GPL 变体授权，任何个人或公司都可以自由地下载、安装和使用它，无论是为自己还是为他人提供服务（包括付费服务）。假如有一个公司，PB LLC，决定建立一个大型商业网站 Plopbox，以提供对托管 Nextcloud 实例的付费访问。

在使 Plopbox 扩展到数百万用户的过程中，PB LLC 对代码进行了大量修改。修改后的代码消耗的服务器资源要少得多，而且还增加了一些功能，Plopbox 的用户认为这些功能很有价值，足以让 Plopbox 与 Nextcloud 的普通安装有实质性的区别。如果 PB LLC 为了创建 Plopbox 服务而使用的开源项目 Nextcloud 已经获得 GPL 授权，这些修改可以保持专有性，PB LLC 也不会被要求向任何人提供这些修改。

这是因为标准 GPL 的限制只有在重新发布时才会生效，而 PB LLC 并没有重新发布 Nextcloud 的修改版本。由于 PB LLC 只在自己的服务器上安装了 Nextcloud，所以它没有义务自动或按要求向任何人提供 Nextcloud 的副本，无论是原始版本还是修改版本。

然而，Nextcloud 并不是在 GPL 的任何一个标准版本下获得许可的，它是在 Affero GPL 下获得许可的，而 Affero GPL 将 GPL 的所有相关权利授予项目覆盖的网络用户，而不仅仅是代码的接收者。因此，PB LLC 实际上需要以源代码的形式（和对象代码的形式，如果适用的话）向任何使用过该项目（例如，通过开一个 Plopbox 账户）并要求拷贝的人提供他们的可扩展性和新功能的修改。

弱版权许可

弱版权许可证与强版权许可证本质上是相似的，但它并不将其 "病毒式" 保护延伸到链接边界上。对弱版权许可库（或其他项目）本身的修改必须保留原始许可，但该项目之外的任何代码，甚至是完全专有的代码，可以直接链接到弱版权许可项目中的函数。

弱版权许可证的数量相对较少。最常遇到的是：

LGPL —— Lesser GNU 通用公共许可证。有时仍然用它的原名 GNU "Library" 通用公共许可证来称呼，因为它最常用于共享库中。与 GPL 许可的项目兼容使用。

MPL 2.0 —— Mozilla Public License。MPL 2.0 与 GPL 许可的项目兼容，之前的版本不兼容。

CDDL v1.0 —— Common Development and Distribution License，最初由 Sun Microsystems 撰写。CDDL 被认为与 GPL 不兼容，尽管这种不兼容性还没有在法庭上得到检验。

LGPL 和 MPL 之间的主要区别是归属。为了从一个不符合 GPL 的项目链接到一个 LGPL 项目，你必须 "给出明显的通知，。。。该库在其中使用（并）受本许可证的保护"。MPL 没有任何归属要求：你可以重新发布 MPL 项目，并链接到 MPL 项目中的函数，而不需要宣布你正在这样做。

Mozilla 公共许可证还以提供 "前向迁移 "而著称。Mozilla 基金会作为许可证的管理者，可能会在未来创建 MPL 的更新版本，并提供唯一的版本号。如果它这样做，任何获得 MPL 2.0 许可的项目用户都可以选择在原来的 MPL 2.0 或任何更新版本的许可下使用它。

CDDL 同样允许向前迁移，但将许可证管理人定义为 Sun Microsystems 而不是 Mozilla 基金会。与 LGPL 和 MPL 2.0 不同，CDDL 通常被认为与 GPL 不兼容。可能是故意的。一些组织还是选择动态链接 CDDL 和 GPL 授权代码，最明显的是 Ubuntu Linux 发行版的制造商 Canonical，他们在 2016 年初通过发行 ZFS 文件系统的 Linux 移植版宣布了他们这样做的决定。

对 Canonical 的立场有一个重要的异议来自 SFC（Software Freedom Conservancy，软件自由保护协会），该协会指出，将 CDDL 和 GPL 代码联系起来必然是违反 GPL 的行为。虽然 SFC 毫不含糊地指出了这一点，但它对 Canonical 的目标表示了 "同情"，其结论的重点是要求 Oracle（CDDL 的许可证管理人，作为Sun Microsystems 的现任所有者）解决这个问题。

如果甲骨文公司在 GPLv2 兼容的许可证下提供原始的 ZFS 代码库，包括任何兼容的允许性许可证，那么这种可用性将反过来使后来的 OpenZFS 项目成为 ”祖父”，而不需要费力地咨询每个贡献者。

我们不建议现代使用 CDDL 许可证，由于它与 GPL 不兼容，它既不能作为一个允许性许可证使用，也不可能作为一个 "GPL 毒药 "使用，因为 Canonical 和其他公司采取了强硬的立场，认为对 CDDL 和 GPLv2 代码的链接的法律挑战会在法庭上失败。

允许性许可证

允许性许可证对所涵盖的项目的使用、分发或修改作出极少的限制。因此，一个允许性许可证往往与另一个允许性许可证非常相似。允许性许可证中最常见的限制是归属。换句话说，这些许可证通常要求在任何衍生的项目中注明原项目的名字。

著名的允许性许可证包括：

BSD 四条款许可证 —— 1990 年最初的 Berkeley 软件发行许可证允许自由使用、修改、再发行，甚至对所覆盖的软件进行再许可。四个条款唯一的限制是：任何再分发必须包括原始项目的版权声明（条款一和条款二），该项目或任何衍生项目的任何广告材料必须承认使用源项目（条款三），以及不授予使用原始项目的作者或所有者的名称来认可任何衍生项目的权利（条款四）。

BSD 三条款许可证 —— 1999 年首次发布的 BSD 三条款许可证省略了原来 BSD 四条款许可证中的广告条款。在其他方面是相同的。

BSD 双条款许可证 —— 也被称为 "简化 BSD 许可证" 或 "FreeBSD 许可证"，BSD 双条款许可证省略了原始 BSD 许可证中的背书条款和广告条款。

Apache 许可证 2.0 —— Apache 许可证是一个与 BSD 双条款许可证类似的允许性许可证，只是它额外授予了类似 GPLv3 的专利权。Apache 2.0 许可证还要求重新发布源项目中存在的 NOTICE 文件的原始内容。如果需要的话，NOTICE 文件可以添加新内容，但不能遗漏原始内容，也不能改变，或者看起来是改变许可证条款。

MIT 许可证 —— 它很模糊，可能指的是几种许可证变体中的任何一种。当有人说 "MIT 许可证" 时，他们通常指的是被称为 "Expat 许可证" 的变体。它与 BSD 双条款许可证类似，授予使用、修改、再分配和再许可的权利，只要求保留并包含原始版权声明。为了消除 "MIT 许可证" 这个术语的用法，OSI 发布了 Expat 许可证的逐字拷贝。

GNU All-permissive 许可证 —— 这是另一个极其简单的允许性许可证，允许使用、重新分发和修改被覆盖的项目，只需要包含原始版权和 GNU All-permissive  许可证本身的单段内容。虽然可以在 GNU APL 下对整个项目进行授权，但这并不常见，也不鼓励这样做。它的真正目的是用于 README、INSTALL 和类似的简单单文件。

虽然 Github 和 Black Duck Software 进行的软件调查都将 MIT 许可证列为最常遇到的开源许可证，但由于其中涉及到的模糊性，因此强烈建议不要使用它。MIT 许可证在授予（或限制）使用方面与 BSD 双条款许可证并无显著不同。

由于 BSD 双条款许可证在其本身的文本和 "BSD双条款许可证" 在正常使用中的含义都相当明确，因此强烈建议使用它。那些希望明确授予专利权的人建议使用 Apache 2.0 许可证，但要注意的是，这使得 Apache 2.0 与 GPLv3 兼容，但与使用更广泛的 GPLv2 不兼容。

公共领域等效许可证

许多人在发布作品时根本没有任何许可通知，只是不想费心阅读或理解任何许可或其含义，并错误地认为提供作品而不提供许可就可以使其 "自由"。人们不需要考虑许可证的愿望可以理解，但恳请这些人使用公共领域的等效许可证来代替。OSI 批准的公有领域等效许可证只有一个，这里有它自己的单项列表：

BSD 0 条款许可证 —— 这是原始 BSD 许可证中的免责声明，没有任何限制性的条款，并且有前面的声明 "允许使用、复制、修改和分发本软件用于任何目的，无论是否收费"。BSD 0 条款许可证并没有特别授予任何接受或使用 BSD 0 条款许可项目的人免版税使用软件专利。这是唯一经 OSI 批准的公有领域等效许可证。

非 OSI 批准的许可证

在大多数情况下，如果一个许可证不是 OSI 批准的，你就不应该考虑使用它。至少应该谨慎使用它。无论你是在寻找强复制许可、弱复制许可还是允许性许可，OSI 批准的列表中都有很多例子，因此，没有理由另寻他法。

另一方面，OSI 批准的公有领域等效许可证只有一个，而那种觉得允许性许可证不够宽容的人往往是非常顽固的，甚至可能会因此而退缩。考虑到这一点，下面将介绍几种最著名的非 OSI 批准的公有领域等效许可证。

Unlicense —— Unlicense 规定，被覆盖的作品将被发布到公共领域，并继续说明这到底是什么意思。这不是 OSI 批准的许可证，部分原因是它使用了 "公有领域" 这个术语，这可能会使任何涉及放在 Unlicense 下的作品的法律情况复杂化。

CC0 —— 创意共享零授权是创意共享系列授权中最宽松的形式，它更常用于涵盖文本和媒体创作，而不是代码。创意共享基金会向 OSI 提交了 CC0，要求批准它成为一个开发源码许可证；虽然 OSI 从来沒有正式拒绝它，但他也无法得出结论来批准它。主要原因是它明确地放弃了专利权的转移，OSI 称这是开源许可证中 "极为罕见" 和 "潜在危险" 的。

WTFPL —— WTF Public License 的缩写，WTFPL 是一个非常简短和非常非正式的申明，你可以用 WTFPL 下的任何代码做任何你想做的事情。自由软件基金会承认 WTFPL 是一个与 GPL 兼容的自由软件许可证，但并不推荐使用它；OSI 完全拒绝了 WTFPL，理由是它 "与公有领域的奉献没有区别"，尽管它没有使用 "公有领域" 这个术语，而且在不同的司法管辖区与公有领域相关的权利也不同。

再次指出，不建议使用任何未经 OSI 批准的许可证。使用任何这些未经批准的公有领域等效许可证无论表面上多么自由，都是一个危险的行为。使用未经 OSI 批准的许可证比不使用任何许可证要好，但这样做有可能使你自己或你的用户失去获得专利甚至金钱资助的资格。