开源协议解读

前言

越来越多的开发者与设计者希望将自己的产品开源，以便其他人可以在他们的代码基础上做更多事，开源社区也因此充满生机。然而一旦开源，如何为代码选择开源许可证就是一个非常重要的问题。

相信很多人和我一样，在 Github 创建 repo 时对可以选择的多种 license 很迷糊，不知道该选哪个好，因此本篇博客就简单介绍一下常见的 license 和他们之间的区别，以做记录和学习。

什么是许可协议

关于授权的确切含义存在很多困惑。当你授权你的作品时，你并没有放弃你的任何权利，你仍然拥有该作品的原始版权（或专利）。许可协议所做的是授予其他人使用该作品的特定权限。

不管产品是免费向公众分发还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。

开源许可使得其他人无需寻求特殊许可就可以很容易地对项目做出贡献。它还保护了你作为原始创造者的身份，确保你至少能从自己的贡献中获得一些荣誉，这也有助于防止别人把你的工作据为己有。

常见许可协议

目前，国际公认的开源许可证共有 80 多种。它们的共同特征是，都允许用户免费地使用、修改、共享源码，但是都有各自的使用条件。以下介绍一些常见的许可协议

GNU GPL

GNU GPL（GNU General Public License）同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。

GPL 还规定：只要这种修改文本在整体上或者其某个部分来源于遵循 GPL 的程序，该修改文本的整体就必须按照 GPL 流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循 GPL 流通的程序不能同非自由的软件合并。GPL 所表达的这种流通规则称为 copyleft，表示与 copyright（版权）的概念“相左”。

GPL 协议最主要的几个原则：

1. 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
2. GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
3. 无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
4. 开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。

GPL 协议和 BSD, Apache Licence 等鼓励代码重用的许可协议很不一样。GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种 linux，包括商业公司的 linux 和 linux 上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

GNU LGPL

LGPL 是 GPL 的一个为主要为类库使用设计的开源协议。和 GPL 要求任何使用/修改/衍生之 GPL 类库的的软件必须采用 GPL 协议不同。LGPL 允许商业软件通过类库引用 (link) 方式使用 LGPL 类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此 LGPL 协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL 都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。

GNU AGPL

原有的 GPL 协议，由于现在云服务厂商兴起（如：AWS）产生了一定的漏洞，比如使用 GPL 的自由软件，但是并不发布于网络之中，则可以自由的使用 GPL 协议却不开源自己私有的解决方案。AGPL 增加了对此做法的约束。

GPL 的约束生效的前提是“发布”软件，即使用了 GPL 成分的软件通过互联网或光盘 release 软件，就必需明示地附上源代码，并且源代码和产品也受 GPL 保护。

这样如果不“发布”就可以不受约束了。比如使用 GPL 组件编写一个 Web 系统，不发布这个系统，但是用这个系统在线提供服务，同时不开源系统代码。

GNU SSPL

SSPL (Server Side Public License) 为 MongoDB 基于 GPLv3 上修改并提出的软件授权协议。

MongoDB 认为 AGPL “Remote Network Interaction” 条款叙述不够明确，容易造成混淆。加上许多云端服务商一直在挑战 AGPL 的底线，大量使用 MongoDB 来进行营利行为却不遵守 AGPL，所以才提出明确定义的 SSPL。

SSPL 服务器端公共授权。许可证更改并不影响当前使用社区服务器的常规用户。根据 MongoDB 之前的 GNU AGPLv3 协议，想要将 MongoDB 作为公共服务运行的公司必须将他们的软件开源，或需要从 MongoDB 获得商业许可，该公司解释说，“然而，MongoDB 的普及使一些组织在违反 GNU AGPLv3 协议的边缘疯狂试探，甚至直接违反了协议。”

尽管 SSPL 与 GNU GPLv3 没有什么不同，但 SSPL 会明确要求托管 MongoDB 实例的云计算公司要么从 MongoDB 获取商业许可证，要么向社区开源其服务代码。最近闹得特别火的 ElasticSearch 修改开源协议 就是从 Apache 2.0 修改到了 SSPL 协议以限制 AWS 厂商。

但是，大名鼎鼎的 OSI（Open Source Initiative）在官网上明确说 SSPL 是伪开源许可证（fauxpen source license），感兴趣的吃瓜群众可以关注此 推送。

BSD

BSD 是 “Berkeley Software Distribution” 的缩写，意思是”伯克利软件发行版”。

BSD 在软件分发方面的限制比别的开源协议（如 GNU GPL）要少。该协议有多种版本，最主要的版本有两个，新 BSD 协议与简单 BSD 协议，这两种协议经过修正，都和 GPL 兼容，并为开源组织所认可。

新 BSD 协议（3 条款协议）在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制。另外，该协议还禁止拿开发者的名义为衍生产品背书，但简单 BSD 协议删除了这一条款。

MIT

MIT 是和 BSD 一样宽范的许可协议，源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称 X11 协议。

MIT 协议可能是几大开源协议中最宽松的一个，核心条款是：该软件及其相关文档对所有人免费，可以任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。唯一的限制是，软件中必须包含上述版权和许可提示。

这意味着：你可以自由使用，复制，修改，可以用于自己的项目。可以免费分发或用来盈利。唯一的限制是必须包含许可声明。

MIT 协议是所有开源许可中最宽松的一个，除了必须包含许可声明外，再无任何限制。

Apache

Apache License（Apache 许可证），是 Apache 软件基金会发布的一个自由软件许可证。

Apache 协议 2.0 和别的开源协议相比，除了为用户提供版权许可之外，还有专利许可，对于那些涉及专利内容的开发者而言，该协议最适合。

Apache 协议还有以下需要说明的地方：

1. 永久权利：一旦被授权，永久拥有。
2. 全球范围的权利：在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
3. 授权免费，且无版税：前期，后期均无任何费用。
4. 授权无排他性：任何人都可以获得授权
5. 授权不可撤消：一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码。

分发代码方面包含一些要求，主要是，要在声明中对参与开发的人给予认可并包含一份许可协议原文。

MPL

MPL（Mozilla Public License 1.1）协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但 MPL 是允许修改，无偿使用得。MPL 软件对链接没有要求。（要求假如你修改了一个基于 MPL 协议的源代码，则必须列入或公开你所做的修改，假如其他源代码不是基于 MPL 则不需要公开其源代码）

Creative Commons

Creative Commons (CC) 并非严格意义上的开源许可，它主要用于设计。Creative Commons 有多种协议，每种都提供了相应授权模式，CC 协议主要包含 4 种基本形式：

1. 署名权
   必须为原始作者署名，然后才可以修改，分发，复制。
2. 保持一致
   作品同样可以在 CC 协议基础上修改，分发，复制。
3. 非商业
   作品可以被修改，分发，复制，但不能用于商业用途。但商业的定义有些模糊，比如，有的人认为非商业用途指的是不能销售，有的认为是甚至不能放在有广告的网站，也有人认为非商业的意思是非盈利。
4. 不能衍生新作品
   你可以复制，分发，但不能修改，也不能以此为基础创作自己的作品。

CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的 CC 协议会声明 “署名权，非商业用途，禁止衍生”条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的 CC 协议类型当属 “署名”协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。

许可协议区别

根据使用条件的不同，开源许可证分成两大类。

• 宽松式许可证
• Copyleft 许可证

宽松式许可证

特点

宽松式许可证（permissive license）是最基本的类型，对用户几乎没有限制。用户可以修改代码后闭源。

它有三个基本特点。

1. 没有使用限制：用户可以使用代码，做任何想做的事情。
2. 没有担保：不保证代码质量，用户自担风险。
3. 披露要求（notice requirement）：用户必须披露原始作者。

常见许可证

常见的宽松式许可证有四种。它们都允许用户任意使用代码，区别在于要求用户遵守的条件不同。

1. BSD（二条款版）：分发软件时，必须保留原始的许可证声明。
2. BSD（三条款版）：分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。
3. MIT：分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。
4. Apache 2：分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。

Copyleft 许可证

Copyleft 的含义

Copyleft 是理查德·斯托曼发明的一个词，作为 Copyright （版权）的反义词。

Copyright 直译是”复制权”，这是版权制度的核心，意为不经许可，用户无权复制。作为反义词，Copyleft 的含义是不经许可，用户可以随意复制。

但是，它带有前提条件，比宽松式许可证的限制要多。

• 如果分发二进制格式，必须提供源码
• 修改后的源码，必须与修改前保持许可证一致
• 不得在原始许可证以外，附加其他限制

上面三个条件的核心就是：修改后的 Copyleft 代码不得闭源。

常见许可证

常见的 Copyleft 许可证也有四种（对用户的限制从最强到最弱排序）。

1. Affero GPL (AGPL)：如果云服务（即 SAAS）用到的代码是该许可证，那么云服务的代码也必须开源。
2. GPL：如果项目包含了 GPL 许可证的代码，那么整个项目都必须使用 GPL 许可证。
3. LGPL：如果项目采用动态链接调用该许可证的库，项目可以不用开源。
4. Mozilla（MPL）：只要该许可证的代码在单独的文件中，新增的其他文件可以不用开源。

区别示意图

图胜千言

常见问题

什么叫分发（distribution）

除了 Affero GPL (AGPL) ，其他许可证都规定只有在”分发”时，才需要遵守许可证。换言之，如果不”分发”，就不需要遵守。

简单说，分发就是指将版权作品从一个人转移到另一个人。这意味着，如果你是自己使用，不提供给他人，就没有分发。另外，这里的”人”也指”法人”，因此如果使用方是公司，且只在公司内部使用，也不需要遵守许可证。

云服务（SaaS）是否构成”分发”呢？答案是不构成。所以你使用开源软件提供云服务，不必提供源码。但是，Affero GPL (AGPL) 许可证除外，它规定云服务也必须提供源码。

开源软件的专利如何处理

某些许可证（Apache 2 和 GPL v3）包含明确的条款，授予用户许可，使用软件所包含的所有专利。

另一些许可证（BSD、MIT 和 GPL v2）根本没提到专利。但是一般认为，它们默认给予用户专利许可，不构成侵犯专利。

总得来说，除非有明确的”保留专利”的条款，使用开源软件都不会构成侵犯专利。

什么是披露要求

所有的开源许可证都带有”披露要求”（notice requirement），即要求软件的分发者必须向用户披露，软件里面有开源代码。

一般来说，你只要在软件里面提供完整的原始许可证文本，并且披露原始作者，就满足了”披露要求”。

GPL 病毒是真的吗

GPL 许可证规定，只要你的项目包含了 GPL 代码，整个项目就都变成了 GPL。有人把这种传染性比喻成”GPL 病毒”。

很多公司希望避开这个条款，既使用 GPL 软件，又不把自己的专有代码开源。理论上，这是做不到的。因为 GPL 的设计目的，就是为了防止出现这种情况。

但是实际上，不遵守 GPL，最坏情况就是被起诉。如果你向法院表示无法履行 GPL 的条件，法官只会判决你停止使用 GPL 代码（法律上叫做”停止侵害”），而不会强制要求你将源码开源，因为《版权法》里面的”违约救济”没有提到违约者必须开源，只提到可以停止侵害和赔偿损失。

如何选择开源协议

推荐一个 网站，有助于我们每个人做开源协议的选择。

总结

随着时代的发展，开源协议也一直在迭代进化，希望我们大家都能够了解开源协议，遵守开源协议并捍卫开源协议。

这篇博客参考了许多相关博客以做一个汇总总结，如有侵权之处可联系我删除~

参考资料

如何选择开源许可证？（阮一峰）
简介 5 大开源许可协议
拒绝云服务商白嫖，Elasticsearch 和 Kibana 变更开源许可协议
全球各种开源协议介绍
若你要开源自己的代码，此文带你了解开源协议