花两天总结了市面上主流开源许可证的区别，希望能给点建议

[HikariLan]

因为感觉市面上类似的文章讲的都有点浅和乱，尤其是很多文章没能点出 Copyleft 许可证和宽松许可证之间本质的区别，因此特别写了这篇文章，希望大家能够给点建议。

如果可以的话，请在 GitHub 给我一个 Star：https://github.com/shaokeyibb/open-source-licenses-in-depth

（主题内容太长了只能截断一部分 TvT ，完整版的话可以进入 GitHub 看）

深入理解开源许可证（ Apache,MIT,GPL,BSD,CC ）

前言

如果说有什么东西正在为开源世界保驾护航，那就一定不能不提到开源许可证（ Open Source License ），正是因为这些各不相同的开源许可证的共同支持下，才有了现在这么繁荣的开源软件社区。

但是问题是，这些开源协议太多了（至少有上百种！），即使是主流的几个开源协议，由于其法律文本的晦涩难懂，经常令很多开发者摸不着头脑，不知道他们的软件应当使用什么样的许可协议，或者如何使用这些协议。因此，本文试图通过简单通俗的语言，带领读者了解和区分不同许可证之间的区别。

最后，因为作者知识有限，因此对于本文可能存在的谬误，烦请读者尽数指正，不尽感激！

什么是开源许可证？“开源”和“自由”的区别是什么

开源许可证

狭义的来讲，根据 OSI （ Open Source Initiative ，开放源代码倡议组织） 的解释，开源许可证（ Open source licenses ）是指那些符合 OSD （开源定义，Open Source Definition ） 的许可证 —— 简单来说，这些许可证允许软件被自由的使用，修改和分发。

广义来讲，开源许可证是指一种被用于计算机软件或其他产品的，允许在指定的条款内使用，修改和 /或分发其源代码，蓝图或设计的许可证[^1]。一般来讲，我们说的开源许可证是指广义的开源许可证释义。

通俗来讲的话，开源许可证就是一种允许我们在一定条件内按照我们的需要自由使用和修改软件及其源代码的法律条款，籍此条款，这个软件的作者（可能是一个人，也可能是很多人）可以将这些权利许可给我们，并告知我们一些使用限制。这些条款有时由个人起草，有时由商业公司起草，但最广泛使用的是由非营利组织（例如 自由软件基金会，FSF）起草的各种开源许可证，通常情况下，作为开发者的我们可以通过按照这些许可证的要求放置许可证条款（有的许可证可能有别的要求，也有可能没有要求）来声明我们基于这些许可证开源。

需要注意的是，使用开源许可证并不意味着单纯的限制使用者，对于一些许可证（例如下文将会提到的 GPL 协议），他们也会限制您（开发者）的行为。因此，选择一个合适的许可证是十分重要的。

小提示：开源不等于放弃版权

拥有版权（ Copyright ）意味着你对你开发的软件及其源代码拥有著作权，所有权和其他法定权利，使用一个开源协议并不意味着放弃版权，它仅意味着您将您在许可证许可的这部分软件（及其源代码）副本的一部分权利（例如，专利权）让渡给软件使用者和其他开发者，并在可能的情况下放弃一些权利（例如，针对软件破解和修改的起诉权），这仅对您使用指定许可证开源的软件（及其源代码）副本有效，也就是说，对于您手上那部分未使用任何开源许可证开源的软件（及其源代码）来说，您仍然拥有包括版权在内的一切权利（无论您手上的那部分和您发布出去的副本是否相同）。

从另一个角度来讲，开源许可证作为法律条款之所以能工作，正是因为您本身拥有一个软件的版权和著作权：如果您不是这些软件的作者，那么开源也就无从谈起（当然，这不意味着您必须对您的程序主张版权）。

自由软件许可证

根据 FSF 的解释，“自由软件”是指尊重用户自由和社区的软件。粗略地说，这意味着用户可以自由运行，复制，分发，研究，更改和改进软件。[^2] 而自由软件许可证通过法律协议，保障使用者的四大基本自由[^3]。

通常情况下，自由软件许可证都是（狭义的）开源许可证。

Copyleft 许可证

对于 copyleft 一词的中文翻译有很多种，例如“版权相左”，“版权所无”，“著佐权”，但是无论如何，我们能发现其与 "copyright （版权）"一词恰好相反，这意味着 copyleft 许可证与版权的巨大对立。Copyleft 许可证是自由软件许可证中的一种，它旨在通过一些限制，给予用户更多自由。

虽然我们还没有开始讲述详细的许可证文本，但是你将会发现，由于通常的开源许可证偏向于给予使用者几乎所有权力，这也包含了闭源的权利。如何理解？假设有软件 A ，基于某种简单全权许可证开源，这时，一个商业公司看中了这个软件，并基于此软件进行修改得到了软件 B ，这时这个商业公司完全可以不向公众发布这个软件 B 的源代码 —— 他有权利这么做，但是，这也就意味着其他开发者失去了对于这个软件 A 的“改进版本”（也就是软件 B ）的自由。Copyleft 许可证通过条款限制，要求程序的所有修改和扩展版本也是自由的，为用户争取到了这一自由。

专有软件开发商使用版权来剥夺用户的自由；我们使用版权来保证他们的自由。这就是为什么我们颠倒了名称，将“版权”改为“copyleft”。

当然，仍要提到的是，使用 Copyleft 许可证依然不意味着放弃版权（当然，在本地法律允许的条件下，你可以这么做）。

Copyleft 是一种在程序上使用版权的方式。这并不意味着放弃版权；事实上，这样做会使 copyleft 变得不可能。“copyleft”中的“left”不是对动词“离开”的引用，而只是指向“right”镜像的方向。

小提示：copyleft 许可证不排斥商业化使用

Copyleft 许可证的诞生虽然是为了抵制商业公司通过闭源的方式妨碍用户修改和访问软件源代码的自由，但是这并不意味着 copyleft 许可证是排斥商业化使用的，事实上，copyleft 许可证所许可的软件应该允许任何人使用他们，也包括商业公司。但是，这些商业公司在使用这些 copyleft 软件时，也应当受到这些 copyleft 许可证条款的制约。

了解了开源许可证的概念，接下来，我们将详细介绍一些主流的开源许可证及其与其他许可证之间的区别。

主流开源许可证及其区别

一般来讲，我们可以将主流许可协议分为两个部分，copyleft license （ copyleft 许可证）和 permissive license （宽松许可证）。相比 copyleft 许可证，宽松许可证对软件的再分发限制更加宽容，即不要求公开源代码。

当我们谈到如何使用这些开源许可证时，事实上，几乎所有主流许可证都会要求你提供这些许可证自身的完整内容到你的项目中 —— 通常情况，我们会创建一个 "LICENSE" 文件，并填入完整的许可证条款。当然，对于不同的许可证，会有额外的要求，这些要求将会在下方被详细提及。

下文中，我们将会着重介绍 copyleft 许可证，并提及这些许可证与其他许可证的兼容性，简单来说，如果两个许可证可以被称作是兼容的，这就意味着这两个许可证所分别许可的作品可以组合成一个更大的作品（此时，这个更大的作品可能采用一个共同的新许可证，也可能依然以不同区块分别许可）。

Copyleft 许可证

比较常用且著名的 copyleft 许可证即为由 FSF 组织发布的，以 GPL 为首的一系列自由软件许可证，接下来，我们将着重介绍这些许可证。

在 GPL 系列许可证中，存在一个 "X 或以后版本" 的概念，例如 "GPLv2 或以后版本"。这意味着，当我们声明一个项目基于 "GPLv2" 许可时，我们必须严格按照 GPLv2 协议中对代码使用的要求进行许可；但是，当我们声明其基于 "GPLv2 或以后版本" 许可，当其他人在试图合并他的代码和您的代码时，它们将可以按照更新的 "GPLv3" 协议对代码使用的要求进行许可，即使两个 GPL 协议之间本身并不互相兼容。

小提示：理解“合并 /组合代码”

根据 GNU 组织关于"主程序与其插件何时被视为单个组合程序"的解释：

这取决于主程序如何调用其插件。如果主程序使用 fork 和 exec 来调用插件，并且它们通过共享复杂的数据结构或相互传递复杂的数据结构来建立亲密的通信，则可以使它们成为一个单一的组合程序。使用简单 fork 和 exec 调用插件且未在它们之间建立密切通信的主程序会导致插件成为单独的程序。

如果主程序动态链接插件，并且它们相互调用函数并共享数据结构，我们认为它们形成一个单一的组合程序，必须将其视为主程序和插件的扩展。如果主程序动态链接插件，但它们之间的通信仅限于使用某些选项调用插件的“main”函数并等待它返回，则属于临界情况。

使用共享内存与复杂的数据结构进行通信几乎等同于动态链接。

小提示：理解“明确声明”

有的简单全权许可证因为其许可条款十分短小简单，可能会造成很多模糊 —— 有时候，某些权利并未显式授予您，但实际上您拥有这些权利，例如专利权；反之，有些权利并未显式告知限制，但实际上您不拥有这些权利，例如商标权。如果你的项目十分重要，那么选择一个更加复杂正式的协议可能更好一些（反之，有的小型程序代码可能比协议文本还短，这个时候建议使用一些简单的许可证）。

GNU General Public License v3.0

协议原文 | 非官方翻译

GNU 通用公共许可证第三版（简称 GNU GPLv3 ，或 GPLv3 ）是截至目前最新版的 GPL 协议，它发布于 29 June 2007，他相比上一个版本（ GPLv2 ，接下来会提到）提供了些许宽松，并且规范了一些法律术语，同时为软件提供了一些更加有力的保护。GPLv3 是目前使用最广泛的主流 copyleft 许可证之一。

条款简述

在 GPLv3 协议许可下，您可以：

• 商业化使用（这意味着，您可以出于商业目的使用这些源代码）
• 再分发（这意味着，您可以将源代码副本传输给其他任何人）
• 修改（这意味着，您可以修改源代码）
• 专利使用（这意味着，版权人明确声明授予您专利使用权）
• 私人使用（这意味着，您可以出于一切目的私下使用和修改源代码）

唯须遵守以下条款：

• 披露源码（这意味着，分发软件时，您必须提供源代码）
• 协议和版权通知（这意味着，软件中必须包含许可证和版权声明的副本）
• 相同许可证共享（这意味着，如果您修改并再分发软件，您必须使用相同许可证分发；在一定条件下，还可以使用类似或相关的许可证）
• 状态更改说明（如果您更改软件，您应当提供适当的说明）

除此之外，该软件：

• 提供责任限制（版权人声明不对使用者造成的任何损失负责）
• 不提供任何担保（版权人声明不为该软件的品质提供任何担保）

详细介绍

Tips: 详细介绍是出于对许可证原文的简化或可读性描写，它们不是任何法律条款，也不是协议的一部分，只是作者对该协议的一些解释。

GPLv3 许可证许可任何人使用，修改和分发程序及其源代码，这包括：

• 转发完整副本。同时为每一个副本标明版权声明；保留一切免责声明；提供 GPLv3 协议的完整副本且完整保留所有附加条款（下文会提到）
• 转发修改过的源码版本。但你必须提供醒目的修改声明并为其标注日期；必须使用本协议为整个程序授权，而不是某一个部分；如果该程序包含有交互式用户界面，则必须显示适当的法律声明（例外的情况是，如果这个程序原版有交互式用户界面，但未提供法律声明，则你也无须提供）
• 以非源码形式转发。但你应当通过适当方式，在适当地点，为任何可以获得该程序非源码形式的用户提供其源代码

GPLv3 允许你在 GPLv3 协议之外添加一些附加许可，这些附加许可以在转发程序时被选择性删除，这些可能的附加许可包括：

• 表示不提供品质担保或有超出协议要求的责任。
• 要求在此材料中或在适当的法律声明中保留特定的合理法律声明或创作印记。
• 禁止误传材料的起源，或要求合理标示修改以别于原版。
• 限制以宣传为目的使用该材料的作者或授权人的名号。
• 降低约束以便赋予在商标法下使用商品名、商品标识及服务标识。
• 要求任何转发该材料（或其修改版）并对接收者提供契约性责任许诺的人，保证这种许诺不会给作者或授权人带来连带责任。

除此之外的许可并不被允许和 GPLv3 协议共存，如果你看到软件声明了那些额外的许可，你可以去掉他们。

GPLv3 明确授予使用者专利权。

GPLv3 保护用户的合法权益免受反破解法限制，这意味着当你转发一个受保护作品时，你将会失去任何限制他人破解该作品的权利。

GPLv3 不允许您将您的程序与私有程序合并。

兼容性

• GPLv3 与 LGPLv2.1 ，LGPLv3 兼容，这个情况下，整个作品基于 GPLv3 许可；例外的，当该 LGPLv2.1 或 LGPLv3 内容被以类库引用方式与 GPLv3 许可作品合并时，该类库仍可基于 LGPLv2.1 或 LGPLv3 许可；
• GPLv3 与 AGPLv3 兼容，这个情况下，整个作品基于 GPLv3 许可，但应当适用 AGPLv3 中关于网络交互的特别要求（下文会提到）；
• GPLv3 与 MIT License ，Apache License 2.0 ，Unlicense ，WTFPL 兼容，这个情况下，整个作品基于 GPLv3 许可；
• GPLv3 与 BSD 3-Clause "New" or "Revised" License （ Modified BSD ），BSD 2-Clause "Simplified" License （ FreeBSD ），BSD Zero Clause License 兼容，这个情况下，整个作品基于 GPLv3 许可；
• GPLv3 与 BSD 3-Clause Clear License （ Clear BSD ） 兼容，但是由于后者明确不授予专利权，因此可能引发某些专利问题，因此不建议与之合并[^4]；
• GPLv3 与 MPL 2.0 兼容，这个情况下，先前由 MPL 2.0 许可的作品部分使用 MPL 2.0 和 GPLv3 双重许可，整个作品基于 GPLv3 许可[^5]；
• GPLv3 与 CC-BY 4.0 兼容，这个情况下，整个作品基于 GPLv3 许可；
• GPLv3 与 CC-BY-SA 4.0 单向兼容[^6]，这个情况下，整个作品基于 GPLv3 许可；
• GPLv3 与 CC0 兼容，这个情况下，整个作品基于 GPLv3 许可；
• GPLv3 与 GPLv2 不兼容（但是，GPLv3 与被声明为适用于 "GPLv2 或以后版本" 的 GPLv2 协议兼容，并使整个作品基于 GPLv3 许可）；
• GPLv3 与 BSD 4-Clause "Original" or "Old" License （ Original BSD ） 不兼容；
• GPLv3 与 CC-BY-NC ，CC-BY-ND 不兼容。

如何使用

通常情况下的做法是，在你的源代码根目录中创建一个文本文件（ GNU 建议命名为 COPYING，通常情况下，也可以使用 LICENSE），将 GPLv3 的完整许可证文本复制到该文件中。

可选的，你可以在每个文件的顶部添加模板版权声明，这些版权声明也可以在许可证原文底部找到：

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.

如果你的程序拥有交互界面（这里指的是 CLI ），你应该通过一种方式输出一个简短的版权声明：

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

如果你的程序使用 GUI 交互界面，则可以将其放在“关于”栏目中。

如果你之上存在雇主或校方，你还应当让他们在必要时为此程序签署放弃版权声明。

小提示：如何理解 GPLv3 中对源代码再分发的要求

有时候很多人会对 GPLv3 中源代码再分发的要求产生误解，认为 GPLv3 就是必须将软件和源代码免费公布给所有人，其实这个观点这是错误的：首先 GPL 不排斥商业化，因此你完全可以付费出售你的软件，但是前提是这些软件中必须附带（或许可在未来一段时间内通过网络提供）这些软件的源代码 —— 此时，你不能限制这些购买了你软件的人修改这些源代码或是将这些源代码免费 /付费发布给其他人；同时需要注意的是，使用 GPLv3 协议也不意味着你必须将你的软件和源代码公布给所有人，你可以只向你的付费用户公布它们，或是另一家购买你软件的公司（同样，你依然不能阻止这些人根据协议再分发你的软件及其源代码）。

一个例外是，这个软件如果只在你个人，团队，甚至是公司内部使用，那么这些软件源代码应当适用于私人使用许可，这也就意味着，你无需按照 GPL 的要求将它们公开。

GNU General Public License v2.0

协议原文 | 非官方翻译

GNU 通用公共许可证第二版（简称 GNU GPLv2 ，或 GPLv2 ）是上一版的 GPL 协议，事实上在大部分情况下，你不应该使用这个协议，而应当使用 GPLv3 ，但是鉴于一些老的软件仍在使用 GPLv2 授权，在此一并提及，但不作详细介绍。

GPLv2 未向使用者提供明确的专利授权，且未声明保护用户破解软件的权利。同时，GPLv2 不允许提供任何 GPLv2 协议之外的附加许可。

GPLv2 不允许您将您的程序与私有程序合并。

兼容性

• GPLv2 与 LGPLv2.1 兼容，这个情况下，整个作品基于 GPLv2 许可；例外的，当该 LGPLv2.1 内容被以类库引用方式与 GPLv2 许可作品合并时，该类库仍可基于 LGPLv2.1 许可；
• GPLv2 与 MIT License ，Unlicense ，WTFPL 兼容，这个情况下，整个作品基于 GPLv2 许可；
• GPLv2 与 BSD 3-Clause "New" or "Revised" License （ Modified BSD ），BSD 2-Clause "Simplified" License （ FreeBSD ），BSD Zero Clause License 兼容，这个情况下，整个作品基于 GPLv2 许可；
• GPLv2 与 BSD 3-Clause Clear License （ Clear BSD ） 兼容，但是由于后者明确不授予专利权，因此可能引发某些专利问题，因此不建议与之合并[^4]；
• GPLv2 与 MPL 2.0 兼容，这个情况下，先前由 MPL 2.0 许可的作品部分使用 MPL 2.0 和 GPLv2 双重许可，整个作品基于 GPLv2 许可[^5]；
• GPLv2 与 CC-BY 4.0 兼容，这个情况下，整个作品基于 GPLv2 许可；
• GPLv2 与 CC0 兼容，这个情况下，整个作品基于 GPLv2 许可；
• GPLv2 与 GPLv3 不兼容（但是，被声明为适用于 "GPLv2 或以后版本" 的 GPLv2 协议 与 GPLv3 兼容，并使整个作品基于 GPLv3 许可）；
• GPLv2 与 LGPLv3 不兼容（但是，被声明为适用于 "GPLv2 或以后版本" 的 GPLv2 协议 与 LGPLv3 兼容，并使整个作品基于 GPLv3 许可）；
• GPLv2 与 AGPLv3 不兼容；
• GPLv2 与 Apache License 2.0 不兼容；
• GPLv2 与 BSD 4-Clause "Original" or "Old" License （ Original BSD ） 不兼容；
• GPLv2 与 CC BY-SA 4.0 ，CC-BY-NC ，CC-BY-ND 不兼容。

GNU Lesser General Public License v3.0

协议原文 | 非官方翻译（不推荐）

与 GPLv3 这样的"强 copyleft 许可证（ strong copyleft license ）"相对的，GNU 宽通用公共许可证第三版（简称 GNU LGPLv3 ，或 LGPLv3 ）是一种弱 copyleft 许可证（ weak copyleft license ），常用于各种类库（依赖库），其本质上是在 GPLv3 上增加的额外条款，作为一种例外，LGPLv3 豁免您的软件使用者在以类库引用（ link ）的方式使用 LGPL 许可的作品时可以不必开源。

当然，由于其弱 copyleft 的性质，GNU 组织认为 LGPL 实际上是一种妥协，并建议您不要在您的下一个库中使用 LGPL。

条款简述

在 LGPLv3 协议许可下，您可以：

• 商业化使用
• 再分发
• 修改
• 专利使用
• 私人使用

唯须遵守以下条款：

• 披露源码
• 协议和版权通知
• 有条件的相同许可证共享（见下）
• 状态更改说明

除此之外，该软件：

• 提供责任限制
• 不提供任何担保

详细介绍

当使用 LGPLv3 许可证时，您实际上同样应当遵循 GPLv3 协议的条款，并辅以以下例外和附加条件：

• 对于以库头文件部分作为目标代码合并时，你可以选择下述两个条款之一对这部分代码进行分发：

  • 在目标代码的每个副本中明确声明库在其中使用，并且该库及其使用受 LGPLv3 许可证的约束；
  • 在目标代码中附上 GNU GPL 和 LGPLv3 许可证文档的副本。

• 对于组合作品，您需要：

  • 在组合作品的每份副本上明确声明，其中使用了该库，并且该库及其使用受 LGPLv3 许可证的约束；
  • 在组合作品中附上 GNU GPL 和 LGPLv3 许可证文档的副本；
  • 对于在执行期间显示版权声明的组合作品，请在这些声明中包括库的版权声明，以及将用户引导至 GNU GPL 副本和 LGPLv3 许可证文档的引用；
  • 执行下列操作之一：
    • 根据 LGPLv3 的条款，通过适当的形式允许用户将应用程序与链接库的修改版本重新组合或重新链接以产生修改后的组合作品，以代表您遵照 GPL 条款中 “以非源码形式转发” 作品。
    • 使用合适的共享库机制与库链接。合适的机制是指在运行时使用用户计算机系统上已经存在的库的副本，并且库的修改版可以正常工作并且与链接版本兼容。
  • 您不得限制您组合作品中该库这部分的修改和逆向调试。

• 通过以上两种情况下发布的合并软件，不受 GPL 对保护用户的合法权益免受反破解法限制的条款保护；

• 如果您试图分发修改版的本软件，且有某个应用程序引用了本软件提供的功能（而不是通过传递命令行参数的方式），那么您必须选择下列操作之一：

  • 根据 LGPLv3 许可证要求，前提是您做出真诚的努力，以确保在应用程序不提供功能或数据的情况下，该软件仍在运行，且执行其目的的任何部分仍然有意义；
  • 使用 GPL 协议授权本软件。

• 如果您试图将本库与另一个不受 LGPLv3 协议许可的库合并，那么您必须选择下列操作之一：

  • 在组合库中附带一份不与任何其他库组合的，基于该库的相同作品的副本，并根据 LGPLv3 许可证的条款分发；
  • 在组合库中给出醒目的通知，说明它的一部分是基于该库的作品，并解释在哪里可以找到相同作品的未组合形式。

兼容性

• LGPLv3 与 GPLv3 兼容，这个情况下，整个作品基于 GPLv3 许可；
• LGPLv3 与 LGPLv2.1 兼容，这个情况下，基于 LGPLv2.1 许可代码须以 GPLv3 许可分发（但是，LGPLv3 与被声明为 "LGPLv2.1 或以后版本" 的 LGPLv2.1 协议，或当该 LGPLv2.1 作品被以类库引用方式与 LGPLv3 许可作品合并时兼容）;
• LGPLv3 与 AGPLv3 兼容，这个情况下，整个作品基于 GPLv3 许可，但应当适用 AGPLv3 中关于网络交互的特别要求（下文会提到）；
• LGPLv3 与 MIT License ，Apache License 2.0 ，Unlicense ，WTFPL 兼容，这个情况下，整个作品基于 LGPLv3 许可；例外的，当该 LGPLv3 内容被以类库引用方式与这些许可证许可作品合并时，仅该类库基于 LGPLv3 许可；
• LGPLv3 与 BSD 3-Clause "New" or "Revised" License （ Modified BSD ），BSD 2-Clause "Simplified" License （ FreeBSD ），BSD Zero Clause License 兼容，这个情况下，整个作品基于 LGPLv3 许可；例外的，当该 LGPLv3 内容被以类库引用方式与这些许可证许可作品合并时，仅该类库基于 LGPLv3 许可；
• LGPLv3 与 BSD 3-Clause Clear License （ Clear BSD ） 兼容，但是由于后者明确不授予专利权，因此可能引发某些专利问题，因此不建议与之合并[^4]；
• LGPLv3 与 MPL 2.0 兼容，这个情况下，先前由 MPL 2.0 许可的作品部分使用 MPL 2.0 和 LGPLv3 双重许可，整个作品基于 LGPLv3 许可[^5]；例外的，当该 LGPLv3 内容被以类库引用方式与这些许可证许可作品合并时，仅该类库基于 LGPLv3 许可；
• LGPLv3 与 CC-BY 4.0 兼容，这个情况下，整个作品基于 LGPLv3 许可；例外的，当该 LGPLv3 内容被以类库引用方式与这些许可证许可作品合并时，仅该类库基于 LGPLv3 许可；
• LGPLv3 与 CC-BY-SA 4.0 单向兼容[^6]，这个情况下，整个作品基于 LGPLv3 许可；例外的，当该 LGPLv3 内容被以类库引用方式与这些许可证许可作品合并时，仅该类库基于 LGPLv3 许可；
• LGPLv3 与 CC0 兼容，这个情况下，整个作品基于 GPLv3 许可；例外的，当该 LGPLv3 内容被以类库引用方式与这些许可证许可作品合并时，仅该类库基于 LGPLv3 许可；
• LGPLv3 与 GPLv2 不兼容（但是，LGPLv3 与被声明为适用于 "GPLv2 或以后版本" 的 GPLv2 协议兼容，并使整个作品基于 GPLv3 许可）；
• GPLv3 与 BSD 4-Clause "Original" or "Old" License （ Original BSD ） 不兼容；
• GPLv3 与 CC-BY-NC ，CC-BY-ND 不兼容。

如何使用

按照 GPLv3 协议的使用方法应用 GPLv3 协议，然后创建 COPYING.LESSER 文件，将 LGPLv3 的完整许可证文本复制到该文件中。（但是有时，我们也通过直接将 LGPL+GPL 放入同一个 LICENSE 或 COPYING 文件中来使用）。然后，您可仿照上文 GPLv3 协议的本部分内容，添加一些可选的附加许可，此处不再赘述。

GNU Affero General Public License v3.0

协议原文 | 非官方翻译

GNU Affero 通用公共许可证第三版（简称 GNU AGPLv3 ，或 AGPLv3 ）发布于 19 November 2007，作为一种比 GPL 协议更加严格的 copyleft 协议，它催生于一个新的互联网环境 —— 客户端软件逐渐被 Web 浏览器前端+后端软件取代，由于 GPL 协议生效的一个主要要求是 “发布”，但是通过后端向用户提供服务，这部分后端代码并未直接向用户提供，因此按照 GPL 协议无须公开其修改版本。AGPL 就是为了修补这一个漏洞 —— 它要求网络服务器的运营商向该服务器的用户提供运行在那里的修改版本的源代码。因此，只要有人在一个可公开访问的服务器上公开使用一个修改过的版本，公众将能够获得修改过的版本的源代码。

AGPLv3 协议主体基于 GPLv3 协议修改，并加入了远程网络交互和与 GPLv3 兼容的相关内容。在此，我们仅介绍这一部分，对其他主体部分一概省略。

条款简述

在 AGPLv3 协议许可下，您可以：

• 商业化使用
• 再分发
• 修改
• 专利使用
• 私人使用

唯须遵守以下条款：

• 披露源码
• 协议和版权通知
• 网络使用视为分发（这意味着，通过网络与软件交互的用户有权获得其源代码的副本）
• 相同许可证共享
• 状态更改说明

除此之外，该软件：

• 提供责任限制
• 限制商标使用（这意味着版权人明确声明其不授予您商标权）
• 不提供任何担保

详细介绍

除去 GPLv3 协议中对您的类似要求外，您仍需注意以下 AGPLv3 协议中关于网络交互的特别要求：

• 如果您修改本程序，您的修改版本必须在显著位置向所有通过计算机网络远程与本程序交互的用户（如果您的版本支持这种交互）提供机会，从网络服务器上免费提供相应的源码。相应源码应包括根据下段规定纳入 GPLv3 许可证的的任何作品相应源码；
• 您有权将任何受 AGPLv3 协议许可的作品与受 GPLv3 协议许可的作品合并为一个单一作品并分发，本许可证仍保护原作品部分，但合并后的完整作品将受 GPLv3 协议管辖。

兼容性

• AGPLv3 与 LGPLv2.1 ，LGPLv3 兼容，这个情况下，整个作品基于 AGPLv3 许可；例外的，当该 LGPLv2.1 或 LGPLv3 内容被以类库引用方式与 AGPLv3 许可作品合并时，该类库仍可基于 LGPLv2.1 或 LGPLv3 许可；
• AGPLv3 与 GPLv3 兼容，这个情况下，整个作品基于 GPLv3 许可，但应当适用 AGPLv3 中关于网络交互的特别要求（见上）；
• AGPLv3 与 MIT License ，Apache License 2.0 ，Unlicense ，WTFPL 兼容，这个情况下，整个作品基于 AGPLv3 许可
• AGPLv3 与 BSD 3-Clause "New" or "Revised" License （ Modified BSD ），BSD 2-Clause "Simplified" License （ FreeBSD ），BSD Zero Clause License 兼容，这个情况下，整个作品基于 AGPLv3 许可；
• AGPLv3 与 BSD 3-Clause Clear License （ Clear BSD ） 兼容，但是由于后者明确不授予专利权，因此可能引发某些专利问题，因此不建议与之合并[^4]；
• AGPLv3 与 MPL 2.0 兼容，这个情况下，先前由 MPL 2.0 许可的作品部分使用 MPL 2.0 和 AGPLv3 双重许可，整个作品基于 AGPLv3 许可[^5]；
• AGPLv3 与 CC-BY 4.0 兼容，这个情况下，整个作品基于 AGPLv3 许可；
• AGPLv3 与 CC-BY-SA 4.0 单向兼容[^6]，这个情况下，整个作品基于 AGPLv3 许可；
• AGPLv3 与 CC0 兼容，这个情况下，整个作品基于 AGPLv3 许可；
• AGPLv3 与 GPLv2 不兼容；
• AGPLv3 与 BSD 4-Clause "Original" or "Old" License （ Original BSD ） 不兼容；
• AGPLv3 与 CC-BY-NC ，CC-BY-ND 不兼容。

如何使用

通常情况下的做法是，在你的源代码根目录中创建一个文本文件（通常情况下，也可以使用 LICENSE 或 LICENSE.txt），将 AGPLv3 的完整许可证文本复制到该文件中。然后，您可仿照上文 GPLv3 协议的本部分内容，添加一些可选的附加许可，此处不再赘述。

Mozilla Public License 2.0

协议原文

Mozilla 公共许可证第二版（简称 MPL2.0 ）是一个弱 copyleft 许可证，但是其条款的特殊性质又使其更像一个宽松许可证（甚至，有人专门创造了词语 copycenter 来描述这一类许可证），该许可证虽然要求软件源代码需要使用相同许可证进行分发，但是对于可执行软件和包含本软件的大型作品的协议做出了宽松的要求。

MPL2.0 被设计为兼容 GPL 的：其定义了“次要许可证”的概念：这些许可证包含 GPLv2 ，LGPLv2.1 ，AGPLv3 及其所有后续版本。对于在合并作品中使用与这些许可证不兼容的许可证时，MPL2.0 额外允许您根据这些次要许可证分发此类作品，且无须公开源代码。

条款简述

在 MPL2.0 协议许可下，您可以：

• 商业化使用
• 再分发
• 修改
• 专利使用
• 私人使用

唯须遵守以下条款：

• 披露源码
• 协议和版权通知
• 有条件的相同许可证共享（见下）

除此之外，该软件：

• 提供责任限制
• 限制商标使用
• 不提供任何担保

详细介绍

MPL2.0 许可证许可任何人使用，修改和分发程序及其源代码，额外的：

• 任何贡献者均不会因您选择根据 MPL2.0 的后续版本或根据次要许可证的条款（如果允许）分发本软件而授予额外的授权；
• 所有以源代码形式分发的软件均应遵守 MPL2.0 许可证的条款。您必须告知接收者，软件的源代码形式受 MPL2.0 许可证条款的约束，以及他们如何获取 MPL2.0 许可证的副本。您不得尝试在源代码中更改或限制收件人的权利；
• 以可执行文件形式分发的软件仍应同上述条款提供其源代码形式，且您即可以根据 MPL2.0 许可证，也可以根据其他不同的许可证对该软件的可执行文件形式进行再许可，前提是可执行软件的许可证不试图限制或更改接收者在 MPL2.0 许可证下在软件源代码部分中的权利；
• 如果您打算分发一个合并作品，且该合并作品是该软件和受一个或多个次要许可证管辖的作品的组合，并且该软件与次要许可证不见容，则 MPL2.0 允许您根据此类次要许可证的条款额外分发本软件以便大型作品的开发者可以，根据他们的选择，使用 MPL2.0 或此类次要许可证的条款进一步分发该软件。

兼容性

MPL 2.0 协议理论上兼容所有协议，但当您要合并的许可证与 MPL 2.0 协议中定义的“次要许可证”（见上）不兼容时，您应当再分发源代码时提供一个额外的声明，以证明您使用了不兼容的许可证，这些额外声明也可以在许可证原文底部找到：

This Source Code Form is “Incompatible With Secondary Licenses”, as defined by the Mozilla Public License, v. 2.0.

如何使用

通常情况下的做法是，在你的源代码根目录中创建一个文本文件（通常情况下，也可以使用 LICENSE 或 LICENSE.txt），将 MPL2.0 的完整许可证文本复制到该文件中。额外的，Mozilla 基金会建议在每个文件的顶部添加模板版权声明，这些版权声明也可以在许可证原文底部找到：

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.

宽松许可证

宽松许可证中的宽松并不意味着 LGPL 中的 "宽松"，相反，宽松许可证试图通过给予直接用户更多自由和更少的限制，但这么做却放弃了间接用户的自由。但是不可否认的是，宽松许可证的开源方式因为成功拉拢到了商业公司的支持，成功且有效的推进了开源进程，壮大了开源生态，并使其成为了开源世界的主流许可证类型。

......

[hanbing135]

牛🐮！！！

[akira]

这简直就是 个 灾难。。。 许可证 灾难。。

[duke807]

如果一个开源软件选择一款比较宽松的开源许可协议
但是补充说明该协议排除某某公司
会怎么样？

[duke807]

@duke807 意思是排除的公司想使用源码需要付费

[andyJado]

感觉信噪比有点低了好哥哥, 而且有网站做这个事情了的.

在 sourcehut 的入门文档里面有链接.

[PMR]

说了很多 好像社么都没说
TL; DR

[lostvincent]

文章适合拿来研究、讨论，实际使用还是表格更清晰明了些

比如这种形式
https://choosealicense.com/appendix/

[Pastsong]

@duke807 你可以这样做，但是你的软件将不被认可为自由软件，需要依赖你软件的软件也会被传染同样的协议，简单来说自由软件不会使用你的软件，除非保留相同限制，也没有其他开源软件会去用它。这和开源精神是相悖的

[HikariLan]

@lostvincent @PMR 无论是 chooselicense 还是阮一峰翻译的这张图片我都有看过，阮一峰这张图片个人认为没能表现出 GPL 协议的传染性和自由性，而 chooselicense 的表格则是我这篇文章中主要参考的资料之一

[HikariLan]

@andyJado 也是心血来潮，而且看到中文互联网上类似资源并不多，所以就想写一些，顺便加深我自己对开源许可证的理解

[HikariLan]

@duke807 如果这个开源许可证允许的话，那么你可以这么说明，但是这实际上意味着，你创建了一个新的开源许可证，而这个许可证是不允许某个公司使用的。
这是合法的，但是这个许可证未必称得上“自由”亦或者是狭义上的“开源”

[weak]

好长啊，看不下去。

[HikariLan]

@weak 确实长一些:(，主要还是想把东西尽量说清

[PMR]

@HikariLan GPL 在自由也没 WTFPL 自由
GPL 传染 用 RPC 或其他绕过

[HikariLan]

@PMR 这取决于你对“自由”的定义，这里说的“自由”指的是通过一些限制给予更多人自由，而不是 WTFPL 那样单纯只对直接下游的自由

[billlee]

@PMR 这张图片完全没有考虑专利问题

[SchneeHertz]

MIT 就完事了，花这么多时间考虑不如直接闭源

[ysc3839]

建议使用“开放源代码”而不是“开源”，中文语境下的“开源”已经变成了“公开源代码”了，只要源代码公开，即使使用限制多么严格的许可协议都能被称作开源。
中华文化博大精深，我们日常使用的汉语中也包含众多一词多意的缩写词。但是在涉及专业领域、法律的文档中使用缩写词可能不是一个好的做法。
原本强调“Open”、“开放”的“开放源代码”缩写为“开源”后被大众认为是“公开源代码”。原本指代计算机运行时记忆数据的设备“内存”被大众认为是“内部存储”。以及前文提及的把 Copyleft 翻译成“版权所无”，很容易让人以为是放弃著作权。

[HikariLan]

@ysc3839 感谢您的建议。也因此在文章开头我对「开源」一词作了两种定义，且在介绍 Copyleft 许可证时提及了「使用 Copyleft 许可证依然不意味着放弃版权」。这可能确实有些缺乏严谨

[kkocdko]

写得很好，我之前一直找不到关于许可证之间的兼容性的资料，当时纠结了很久哈哈哈哈

[natforum]

这个开源协议有意思 http://www.wtfpl.net/