各种开源协议介绍

一张图看懂开源协议
各种开源协议License明细
开源许可证教程

我的博客同步

作为一个开发者，如果你打算开源自己的代码，千万不要忘记，选择一种开源许可证（license）。

一、什么是开源许可证

开源许可证是一种法律许可。通过它，版权拥有人明确允许，用户可以免费地使用、修改、共享版权软件。
版权法默认禁止共享，也就是说，没有许可证的软件，就等同于保留版权，虽然开源了，用户只能看看源码，不能用，一用就会侵犯版权。所以软件开源的话，必须明确地授予用户开源许可证。

二、开源许可证的种类

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

如果一种开源许可证没有任何使用条件，连保留作者信息都不需要，那么就等同于放弃版权了。这时，软件可以直接声明进入”公共领域”（public domain）。

根据使用条件的不同，开源许可证分成两大类：
* 宽松式（permissive）许可证
* Copyleft 许可证

1. 宽松式许可证

宽松式许可证（permissive license）是最基本的类型，对用户几乎没有限制。用户可以修改代码后闭源。
它有三个基本特点：
* 没有使用限制，用户可以使用代码，做任何想做的事情。
* 没有担保，不保证代码质量，用户自担风险。
* 披露要求（notice requirement），用户必须披露原始作者。

常见宽松式许可证

• BSD（二条款版）

  分发软件时，必须保留原始的许可证声明。

• BSD（三条款版）

  分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。

• MIT

  分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。

• Apache 2

  分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。

2. Copyleft 许可证

Copyleft 是理查德·斯托曼发明的一个词，作为 Copyright （版权）的反义词。
Copyright 直译是”复制权”，这是版权制度的核心，意为不经许可，用户无权复制。作为反义词，Copyleft 的含义是不经许可，用户可以随意复制。但是，它带有前提条件，比宽松式许可证的限制要多：
* 如果分发二进制格式，必须提供源码
* 修改后的源码，必须与修改前保持许可证一致
* 不得在原始许可证以外，附加其他限制

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

常见Copyleft 许可证

• Affero GPL (AGPL)

  如果云服务（即 SAAS）用到的代码是该许可证，那么云服务的代码也必须开源。

• GPL

  如果项目包含了 GPL 许可证的代码，那么整个项目都必须使用 GPL 许可证。

• LGPL

  如果项目采用动态链接调用该许可证的库，项目可以不用开源。

• 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 代码（法律上叫做”停止侵害”），而不会强制要求你将源码开源，因为《版权法》里面的”违约救济”没有提到违约者必须开源，只提到可以停止侵害和赔偿损失。

三、协议详细介绍

• Apache Licence 2.0
• MIT
• BSD
• GPL
• LGPL
• MPL

Apache Licence 2.0

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：
* 永久权利

一旦被授权，永久拥有。
* 全球范围的权利

在一个国家获得授权，适用于所有国家。
* 授权免费，且无版税

前期，后期均无任何费用。
* 授权无排他性

任何人都可以获得授权

• 授权不可撤消
  一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码。

几点说明：
* 需要给代码的用户一份Apache Licence。
* 如果你修改了代码，需要在被修改的文件中说明。
* 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
* 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
* Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

MIT

MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称“X条款”（X License）或“X11条款”（X11 License）。

MIT内容与三条款BSD许可证（3-clause BSD license）内容颇为近似，但是赋予软件被授权人更大的权利与更少的限制。

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

• 被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本。
• 被授权人可根据程序的需要修改授权条款为适当的内容。
• 在软件和软件的所有副本中都必须包含版权声明和许可声明。

此授权条款并非属copyleft的自由软件授权条款，允许在自由/开放源码软件或非自由软件（proprietary software）所使用。

MIT的内容可依照程序著作权者的需求更改内容。此亦为MIT与BSD（The BSD license, 3-clause BSD license）本质上不同处。

MIT条款可与其他授权条款并存。另外，MIT条款也是自由软件基金会（FSF）所认可的自由软件授权条款，与GPL兼容。

该软件及其相关文档对所有人免费，可以任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。唯一的限制是，软件中必须包含上述版 权和许可提示。

BSD

BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

• 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
• 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
• 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销 售，因此是对商业集成很友好的协议。很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者 二次开发。

BSD 在软件分发方面的限制比别的开源协议（如 GNU GPL）要少。该协议有多种版本，最主要的版本有两个，新 BSD 协议与简单 BSD 协议，这两种协议经过修正，都和 GPL 兼容，并为开源组织所认可。
新 BSD 协议在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制。另外，该协议还禁止拿开发者的名义为衍生产品背书，但简单 BSD 协议删除了这一条款。

GPL

在自由软件所使用的各种许可证之中，最为人们注意的也许是通用性公开许可证(General Public License，简称GPL)。

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

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

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

LGPL

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

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

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

MPL

MPL既是得到自由软件基金会承认的自由软件许可证，也是得到开放源代码促进会承认的开源软件许可证。MPL允许在其授权下的源代码与其他授权的文件进行混合，包括私有许可证。但在MPL授权下的代码文件必须保持MPL授权，并且保持开源。这样的条款让MPL既不像MIT和BSD那样允许派生作品完全转化为私有，也不像GPL那样要求所有的派生作品，包括新的组件在内，全部必须保持GPL。通过允许在派生项目中存在私有模块，同时保证核心文件的开源，MPL同时激励了商业及开源社区来参与帮助开发核心软件。
使用MPL授权的软件并不受专利的限制，其可以自由使用，修改，并可自由的重新发布。带有专利代码的版本仍然可以使用，转让，甚至出售，但未经许可则不能修改代码。此外，MPL并不授予用户对于开发者商标的使用权。

为了满足MPL的条款限制，用户必须负担一些“责任”，主要是关于散发使用MPL授权的软件。用户必须确保重新散发的软件所有源代码均以MPL授权，即使是以可执行文件的方式提供或是与其他使用专有软件授权的源代码结合也一样。但若跟以GNU通用公共许可协议、GNU宽通用公共许可证、Affero通用公共许可证授权的源代码结合则是例外。此时开发者则可选用以上三种更加严格的条款来授权。