1.3 ＞许可证的那些事儿

本文链接：https://blog.csdn.net/qq_55902573/article/details/143401669

前情提要

在上一节中，我们了解了 Linux kernel 的生命周期和主流发行版。本节内容主要说明了开源是什么，以及当前常用的开源协议有哪些。

什么是开源

开源主要指的是一种软件开发和发布形式，其核心就是在于源代码必须公开，任何人都可以查看、使用、修改和再发布基于该源码的内容。而如何使用源码进行二创和发布就是各个开源协议（开源许可证 ¹）管的事了，如果一个软件或源代码遵循了某一协议，那么使用它的用户都必须遵守相应的规则。

主流开源协议

MIT License | X11 License

此协议来源于麻省理工学院，MIT 就是其简称。在上个世纪八十年代，MIT 计算机科学实验室和 MIT X Consortium 共同推出了这个协议，意在使开发者和研究人员更好的自由使用和分发代码。现在，MIT 因其简洁、宽松的政策已成为了最受欢迎的协议之一了。其流行的原因和背景：

学术自由和共享精神的支撑： MIT 鼓励知识创作和分享，为了方便与研究人员的合作与创新，MIT 希望他们分发的代码能够被更多人自由的使用，而不用受到诸多限制。
对商业很友好：因为 MIT 的条款非常宽松，允许用户在商业项目中使用源代码，这极大的降低了企业使用开源代码的法律风险。所以，MIT 在企业中非常受欢迎。
没有几个条条框框： MIT 协议的条款是出了名的简单，主要内容就是允许任何人以任何方式使用代码，前提是你必须保留原始版本的版权声明和许可声明，另外再外加一条免责声明（代码作者不对因其造成的任何损失而承担任何责任）就构成了 MIT 协议。

MIT / X11 许可证

现在，世界上有许多知名开源项目都使用了 MIT 许可证，如 VSCode核心源码（代码编辑器）、React（前端框架）、jQuery（前端第三方库）、Vue（前端框架）等等项目，它们都准许了 MIT 许可证。

Apache License 2.0

此许可证是由 Apache 基金会（ASF）来发行与维护的。Apache 基金会成立于 1999 年，它旨在于支持开源项目的开发和推广，促进开放、写作的软件开发。下面是此协议历经的几个版本：

Apache License 1.0 时期：这是 Apache 许可证的首个版本，最初是用来在基金会中管理其软件项目的。它允许用户自由使用、修改和分发软件产品，在版权和责任条款方面还比较松散。
Apache License 1.1 时期：此版本的许可证也是在 1999 年发布的，此版本改进了前一版条款松散的问题，进一步规范了软件的使用和分发，解决了一些早期许可证在法律和实用性方面的问题。从这一版本开始，此许可证开始大量运用于 Apache 项目中。
Apache License 2.0 时期：此版本是现在流行的 Apache License 许可证版本，这一版本对之前的版本做出了重大更新，是对 1.1 版本的全面修订：
- 明确了专利方面的授权：新增专利条款，保护使用者在使用源代码时不会受到来自专利诉讼等方面的威胁。
- 版权和许可证要求：对版权声明和许可证的管理进行了明确化。
- 更好的兼容性：更好的兼容其他许可证，如 GPL 等

Apache 2.0 许可证的条款主要包括：

版权声明：使用者在使用软件时，必须保留原始版权声明和许可证声明。
许可条款：允许使用者在不受限制的情况下使用、修改、分发、再许可和销售软件。
修改和再分发方面：当使用者修改了软件，则必须在修改后的文件中标明所修改的内容，当重新分发时也必须包含版权声明和许可证声明。许可证的任何修改都必须以书面的方式进行。
专利权：贡献者允许使用者对其贡献的专利授权，保证使用者在使用代码时不会受到来自贡献者的专利诉讼。
终止条款：如果使用者未遵循许可证规定的条款，则该许可证将自动终止。
免责声明：使用者在使用费软件时所产生的一切损害，开发者和软件所有者将不对其负有任何责任。

在这里插入图片描述

Apache 许可证 / Apache 基金会

世界上使用 Apache License 2.0 许可证的知名开源项目有 Android（安卓）、Apache Http Server（WEB服务器）、k8s（容器编排引擎）、Elasticsearch（分布式搜索引擎和数据分析引擎）等等。

GPL

上世纪八十年代左右，软件行业逐渐走向闭源，一些商业公司为了利益也开始限制他人使用自己的源代码。在这样的背景下，麻省理工学院的一位自由软件的坚定支持者和倡导者理查德斯托曼就开始发起了 GNU 计划并希望创建 Unix 的完全替代品，并在 1985 年创立了自由软件基金会（FSF）。
在这里插入图片描述

GNU 自由软件计划

1989年，GPL 的首个许可证 GPLv1 发布，首次明确了用户可以自由使用、修改和分发 GPL 软件。同时，在这一版本也首次提出了 Copyleft 的概念，既所有基于了 GPL 软件的衍生版软件都必须保持 GPL 许可证。
1991年，GPLv2 发布，这一版较之前的版本做出了重大改进，增加了“自由或死亡”这一条款，规定了如果法律或则其他情况限制了 GPL 的自由要求，那么该软件将不能使用 GPL 许可证发布。
2007年，GPLv3 发布，这一版本解决了上一版本在硬件和数字版权等方面的缺陷。比如这一版本明确反对数字版权保护，强调个人自由，很好的避免了某些软件被限制在某一特定的硬件设备上。同时这一版本还增加了软件专利保护，防止通过软件专利威胁软件的开源开发者。但是，由于新增的一些条款限制，也导致了一些自由软件宁愿使用 v2 版本，也不愿意使用 v3 版本（如 Linux）。

当然，GPL 还有一些其他衍生版本的许可证，如 LGPL 、AGPL等等。
在这里插入图片描述

GPLv3 许可证（GNU 通用公共许可证）

世界上使用 GPL 许可证的开源项目很多很多，出名的如 Linux kernel（Linux 内核）、gcc（GNU编译器套件）、MySQL（关系型数据库）、Blender（3D建模引擎）等等。

LGPL

此许可证是 GPL 的变种，最初它的名字是 Library GPL（后来又改为 Lesser GPL）。通过名字就可以看出，这一许可证主要是为了给库和其他特定场景设计的，它在其核心理念上同 GPL 保持一致，主要是在链接方面对使用它的软件限制更少更宽松。

与 GPL 不同的是，LGPL 是允许 LGPL 授权的软件库给专有软件使用和发布的，而不会强制专有软件使用 LGPL 发布。这意味着，私有软件可以使用 LGPL 许可的库而继续保持软件本身的闭源。虽然使用者可以保持闭源发布，但是对 LGPL 许可的库的修改任然需要保持 LGPL 许可发布，以保证库本身的自由性不会受到损害。

相对于 GPL 许可，LGPL 许可也有相对应的 v2 和 v3 版本，其改动和 GPL 的版本迭代改动大差不差。

在这里插入图片描述

LGPLv3 许可证（GNU 宽通用公共许可证）

著名开源项目中 glibc（标准 c 库实现）、Qt部分代码（C++跨平台开发框架）、OpenSSL（加密库）等都采用的是 LGPL 许可证发布的。

MPL

此许可证是由 Mozilla 基金会发布的一种开源许可证。其旨在于保护开源代码的同时，还具有一定的灵活性，由于其允许开源代码与闭源代码共存，所以在开源和闭源软件的结合方面有一定的优势。MPL 许可证拥有一下特点：

文件级别的开源要求：和上面的 GPL 不同的是，MPL 只要求经过修改和分发的开源文件必须遵循 MPL 许可证，而不是 GPL 那样的整个项目都要遵循许可证。这种要求比 GPL 还要宽松，因此也是允许了开源代码和专有代码共存在一个项目中。
允许开源代码和私有代码混合：用户使用 MPL 许可证的代码时，是可以将其混入自己的私有项目中来保持闭源的，但是如果修改了 MPL 许可的开源代码，那么修改过后的代码还是必须保持 MPL 许可开源。

MPL 版本也经历了三次迭代：

MPL 1.0 时期：1988 年发布，也是 MPL 的初始版本。这一版本开创了文件级别的开源要求，并得到了广泛运用。
MPL 1.1 时期：1999 年发布，修改了兼容性的问题，使之能更好的与其他类型的开源项目相结合。
MPL 2.0 时期：2012 年发布，对其中的条款进行了现代化改进，继续增强了对 GPL、Apache 等其他许可证的兼容性。

在这里插入图片描述

MPL 许可证（Mozilla公共许可证）/ Mozilla 基金会

在众多开源项目中，Firefox（浏览器）、Rust（编程语言）、Thunderbird（电子邮件）等项目都是使用 MPL 开源的。

BSD Licenses

此许可证最早是由加州大学伯克利分校为其 BSD 系统发布的。这款许可证被认为是迄今为止主流许可证中最为宽松的许可证之一了，它对于用户的使用基本没有什么强制要求，其特点如下：

极其宽松的再分发许可：此许可证允许用户自由使用、修改和再分发软件，无论你是什么目，即使你修改了 BSD 的开源项目然后闭源发布此项目都可以，更不用说将开源项目集成到私有软件中闭源发布了。
版权声明必须保留：虽然 BSD 项目运行你闭源再分发其开源项目，但是在你的项目中，其之前的开源代码部分必须要保留原始的版权声明和免责条款。这保证了原作者可以获得版权任何和避免某些法律责任。
三版本的 BSD 许可证可贡选择：
- 极简版：这一版本的许可证只包含了原始许可证的其中两条条款，仅仅只要求在项目中保留原作者的版权声明和免责声明，其他没有任何要求。
- 中等简单版：这一版在极简版的基础上，增加了必须保留源代码的推广限制条款。
- 原始版：最早的 BSD 许可证版本，包含要求必须保留源代码的版权声明、免责声明、禁止使用作者名字来做推广、禁止在所有软件中声明此软件来源于加州大学伯克利分校（后来被删除）这这个条款。

正是因为 BSD 许可证的高度自由，这也导致了开源项目缺乏了开源保障，由于其运行闭源的特性，限制了开源软件的传播。而且其在某些方面对于开发者的保护较弱。

在这里插入图片描述

BSD 许可证 / 伯克利软件包

在世界上使用 BSD 许可证的开源项目有：FreeBSD（类Unix系统）、OpenBSD（类Unix系统）、SQLite（嵌入式关系型数据库）、Django（Python web框架）等等项目。

其他常用开源协议

AGPL

此许可证和 LGPL 一样，都是基于 GPL 在某一专业领域的变种，AGPL 许可证更加专注于网络应用场景。AGPL 要求通过网络服务提供的情况下也要开放源代码，既确保用户在特殊场景下（SaaS、分布式网络系统、云服务中的开源软件等）也能获取源代码。这一许可证有如下特点：

同 GPL 要求一样，任何修改和再分发都必须遵循相同的许可证，但是 AGPL 增加了一项条款，就是如果软件通过网络向用户提供服务，那么也必须通过修改后的源代码，这一点与 GPL 不同的是，AGPL 只要求在软件被直接分发时才需要开放源代码。
和 GPL 不同的是，GPL 在一些场景下可以不向用户提供源代码（如 SaaS），而 AGPL 增加了网络使用条款，要求用户在远程使用软件时也能获取到源代码。这一条款鼓励了开发者为这些场景提供开源且透明的代码。

在这里插入图片描述

AGPLv3 许可证（GNU Affero通用公共许可协议）

当前使用了 AGPL 许可证的著名开源项目有 MongoDB（非关系型数据库）²、CryptPad（在线加密协作平台）等等。

EPL

此许可证于 2004 年由 Eclipse 基金会发布，其设计目的是在保护自由软件的同时还运行代码在商业项目中使用。它有如下特点：

宽松的版权要求：运行直接修改源代码，但是修改之后的代码必须以 EPL 许可证分发。
适合商业化：如果你只是使用了 EPL 代码，那么此协议允许将其集成到私有软件中闭源发布。EPL 还允许开发者将其源代码打包成二进制进行分发而不必公开源代码。
包含专利授权条款：当作者使用 EPL 许可证发布源代码时，其专利权也将自动授权给用户使用。

使用了 EPL 许可证的著名项目有： Eclipse IDE（代码编辑器）、Xtend（基于Java的编程语言）、Jetty（轻量级 Servlet 容器）等等。

在这里插入图片描述

Eclipse 基金会

CC0

此许可证由非营利性组织 Creative Commons 于 2009 年发布的一个公共领域贡献许可证。该许可证旨在将作品放入公共领域，作品采用了 CC0 发布后其作品将彻底不受版权保护。这也意味着作者采用 CC0 发布作品时将不需要署名、没有许可和其他任何限制，任何人都可以自由的使用、修改和分发这些作品。其特点如下：

彻底放弃版权和其他相关权利：CC0 是一个“无版权”协议，作者使用 CC0 发布产品时将彻底放权相关权利。
适用广泛：这一许可证可以应用于各个领域，如文字、音视频、开发等等。
法律的认可：适用 CC0 许可证发布的作品在绝大多数国家的法律中都是认可的。

CC0 与上面说的其他开源许可证有着根本上的不同，开源许可证一般都是要求保留署名、版权等信息的，但 CC0 是完全放弃。

在这里插入图片描述

知识共享许可协议

Unlicense

此许可证是由开源社区的开发者们于 2010 年左右提出的，并不是通过某个组织发布的。与上面的 CC0 有着很大的相似度，此许可证也是旨在将作品完全放入公共领域，作者完全丧失版权等其他相关权利。但与 CC0 不同的是，CC0 在法律方面适用性更广，而 Unlicense 许可证更简单、更专注于开源代码领域，在软件开源社区中的接受度更高。

Beerware（啤酒许可证）

这是一个幽默的、没有任何效应的许可证，最早由丹麦程序员 Poul-Henning Kamp 提出的，其名称来源于 beer（啤酒）。这个许可证要求也很简单，甚至可以说是幽默，它允许用户自由的使用、修改和分发代码，唯一的要求就是如果用户认为代码有用，就要请作者喝酒。下面是 Beerware 许可证的原文，可以看着玩玩：

“THE BEER-WARE LICENSE” (Revision 42): phk@FreeBSD.ORG wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
翻译：只要你还保留本协议文本，你可以使用这个软件为所欲为。如果有哪一天我们见面了，并且你认为此软件很有价值，你可以请我喝啤酒来作为答谢。

这个许可证基本没有任何约束力，它基本被用于个人开发者自己的一些项目中，以一种幽默的方式来表达自由软件分享的快乐。

关于许可证的一些其他事儿

开源许可证（开源协议）是硬性规则，具有法律效应。软件开发者在为软件选择了开源许可证之后，其他使用者如果未准许此开源协议，则可能会承担法律后果。

关于许可证的更改：

如果你是项目负责人或则主要维护者，那么你可以更改项目的未来开源许可证，但是其他使用者在使用之前的版本是可以选择遵循未来许可证或则之前许可证的。
之前发布的项目版本无法被更改许可证，因为之前发布的版本任然对所有使用者生效的，所以你无法单方面强制修改其许可证，如果你征得使用者们的同意，那么你可以更改之前的许可证。
如果你的项目有很多贡献者参与，尤其是项目的某些源代码可能涉及贡献的的知识产权或版权，变更许可证时通常都要征得他们的同意，否则可能面临法律上的风险。你通常可以采取一下措施：
- 直接征得贡献者的同意：因为在大多数国家和地区，代码版权是归属于贡献者的，如果需要修改许可证，你需要征得大部分贡献者的同意才行。
- 创建分支版本：你可以将项目的未来版本分支出去，分支版本遵循新的许可证，而旧版本依然采用旧的许可证。
- 使用贡献者许可协议（CLA）：为了简化管理，你可以在项目开始时要求贡献者们签署 CLA 协议，以允许项目所有者对项目的控制权，这可以减少你切换许可证时的工作难度。

Linux 与 GNU/Linux 的争议

前面说过，斯托曼为了自由软件的目标而发起了 GNU 计划，想要创建一个新的开源的操作系统来替代 Unix 。但是理想很丰满，现实很骨感，就在 GNU 的其他各个部分都进展顺利的时候，系统内核这个最重要的部分却没有进展，据斯托曼回忆说，他曾多次了改变系统内核（Hurd）的开发计划，这是他做的错误的一件事。而在这期间，GNU 计划除了丰富了第三方组件库之外，几乎什么也没做，系统内核也就成了一个很难堵上的窟窿。

直到 1991 年 Linux 的发布，因为 Linux 采用了 GPL 许可证开源，斯托曼就认为 Linux 很好的填补了 GNU 计划的操作系统内核的这一空白，而且当时的很多 GNU 工具都运行在了 Linux 上，所以斯托曼就主张将 Linux 改名为 GNU/Linux ，以便更好的体现出 GNU 计划的贡献。但是这一主张并没有得到 Linux 社区的认可。反而引起了 GNU/Linux 的命名之争。

Linux 社区认为 Linux 并不是 GNU 计划的一部分，虽然在 Linux 中使用了很多 GNU 的软件，但也不能给他取上这么一个拗口的名字，尽管 Debian 等发行版还是使用了 GNU/Linux 这个名称。Linux内核项目的发起人 Linus 也偏好于使用 Linux，但对于GNU/Linux 这个名字也并不强烈反感。