作为一个开源爱好者，我们经常会写一些开源的软件或者工具在网上分享，或者为一些其他的开源软件贡献一些自己的力量，但是对于开源许可（License）是有很多种的哦，每一种是有不同的约束的，在法治国家是具有法律约束的。
概念
首先我们来了解一些基本的概念。
贡献者（Contributors）& 受益者（Recipients）
贡献者（Contributors）指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等)，按照参与某个软件开源的时间先后，可以分为 初始贡献者（Initial Contributor）和 后续贡献者（Subsequent Contributors）。
受益者（Recipients）指的是开源软件或项目的获取者，也就是那些用了这个开源软件的人，后续贡献者（Subsequent Contributors）也属于 受益者（Recipients）之列。
源码（Source Code） & 类库（Object Code）
源码（Source Code） 这个好理解，就是指各种语言写成的源代码，通过Source Code，结合文档，有了源码我们就可以了解各个开源软件的具体细节，也可以做很多的修改。
类库（Object Code）就是指的由源码编译过后生成的“类库”，当然很多语言不需要编译，那源码本身就是类库。
其实分清楚这两个概念还是挺重要的，有些开源协议，对 “你发布的是哪种Code的时候应该怎样”，有着明确的约束。
衍生模块（Derivative Module）& 独立模块（Separate Module）
衍生模块（Derivative Module） 指的是，依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码，是原“源代码”的增强(不等于增加)、改善和延续的模块，意为衍生模块。
独立模块（Separate Module）指的是,参考或借助原“源代码”，开发出的独立的，不包含、不依赖于原“源代码模块”，意为“独立的模块”。
理解这两个概念的目的在于，很多开源许可对涉及到商业发布的时候，会有哪些是衍生的，哪些是独立的，有着明确的商业发布规定。
开放源码促进会（Open Source Initiative）
这是一个组织，简称OSI，叫做开放源码促进会，1998年2月份由Bruce Perens and Eric S. Raymond创立，旨在推动和促进开源软件的发展。现在开源软件的蓬勃发展跟这个组织的倡导是分不开的。官网是opensource.org。
经过这么多年的发展，现今存在的开源许可很多，而经过Open Source Initiative组织批准的开源协议目前有76种，后面可能还会再增多的，列表在官网上有，还有一个介绍也比较全面的。
常见协议
我们常见的开源License：BSD、Apache、GPL、LGPL、MIT、MPL都是Open Source Initiative组织批准的，而且他们对于受益者有着不同的约束，如果要开源自己的代码，最好也是选择这些被批准的开源License。
BSD License
BSD是Berkeley Software Distribution的缩写，叫做伯克利软件发行版，它出现在上世纪70年代，那个时候是一个UNIX操作系统的衍生版本，为了发行它的这个操作系统，他们起草了BSD License。
这个License给了使用者很大的自由，基本上使用者可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
对使用者也有约束:
- 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD License。
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD License。
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
举个栗子：你用开源代码(A)修改或做其他增添之后，产生了产品B，这时候，你对B的控制由你自己决定，你可以用任何协议再开源，也可以闭源商业发布。但是因为如果B中包含了A或A的一部分，那你在B产品的版权声明中提到你有使用到 A，并且附带上 A 的开源协议。而且不能做商业推广的时候将B 冠以原开源作者的名义以促进商业推广。
其实这几个规则约定的目的也只是达到一个目的:是他人的东西，别人以BSD开源了，你就不能不做任何声明而占为己有，更不能用他人的名义来做商业推广，你只对你自己的东西拥有绝对控制权。
当然后面随着BSD的发展和系统衍生发行，BSD License也有了多个版本和衍生版，比如BSD 3-Clause "New" or "Revised" License (BSD-3-Clause)、BSD 2-Clause "Simplified" or "FreeBSD" License (BSD-2-Clause)。
Apache License
这里就需要提一下Apache Software Foundation(ASF)这个组织了，中文我们一般叫 Apache软件基金会，最早这个组织还只有Apache这一个主要开源软件，所以基金会起草了Apache License 的1.0版本，随着后面的发展，很多的开源软件加入了基金会，本着鼓励代码共享，推动软件开源的原则，基金会修改了这个License，放宽了最初许可里边的一些约束规定，于是 有了 Apache License1.1和2.0的版本，1.0和1.1是老早之前的事情了，现在流行的都是Apache License 2.0 (Apache-2.0)。
该License和BSD License类似，鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。
需要满足的条件也和BSD类似:
- 需要给代码提供一份Apache Licence。
- 如果你修改了代码，需要在被修改的文件中说明。
- 在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的Licence、商标、专利声明和其他原来作者规定需要包含的说明。
- 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以对Apache Licence的要求进行更改。
这意味着Apache Licence也是对商业应用友好的许可。使用者也可以修改代码来满足需要，并把修改过的代码作为开源或商业产品发布/销售。
MIT License
Massachusetts Institute of Technology简称MIT，也就是大名鼎鼎的麻省理工学院，最早于1988年由MIT起草，跟BSD类似，作者只想保留版权，而无任何其他了限制。
也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。商业软件可以使用，也可以修改MIT协议的代码，甚至可以出售MIT license (MIT)的代码。
GPL
GNU General Public License简称GPL ，第一个版本起草于1989年2月，这个License旨在 代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。目前使用该License最为我们熟悉的估计就是Linux了。
GPL许可的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 许可的产品，则该软件产品必须也采用GPL许可，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL许可，对于使用GPL许可的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
同样经过长时间的发展，它也有有好几个版本，比较流行的是GNU General Public License version 2.0 (GPL-2.0)、
GNU General Public License version 3.0 (GPL-3.0)
LGPL
GNU Lesser General Public License简称LGPL，因为GPL实在是太严苛了，很多商业公司其实对这个协议是不太认可的，所以为了让商业公司也能使用，设计了LGPL。
和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL许可的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL许可。因此LGPL许可的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL许可代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
简单点说就是商业软件可以使用，但不能修改LGPL许可的代码，改了人家的代码你也就要开源。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
经OSI批准的有两个版本：GNU Library or "Lesser" General Public License version 2.1 (LGPL-2.1)、GNU Library or "Lesser" General Public License version 3.0 (LGPL-3.0)
MPL
The Mozilla Public License简称MPL，1998年初Netscape公司的 Mozilla小组为其开源软件项目设计的软件License。
MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对 源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同。
MPL许可证允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改，无偿使用。
商业软件可以使用，也可以修改Mozilla Public License 2.0 (MPL-2.0)协议的代码，但修改后的代码版权归软件的发起者。
各种License对比
其实这样来看一点都不直观，需要一定的理解能力去理解，其实针对几个方面我们可以总结一下。
| 项目 | 描述 | 解释 |
|---|---|---|
| License and copyright notice | 许可和版权信息 | 在代码中保留作者提供的许可和版权信息 |
| State Changes | 声明变更 | 在代码中声明对原来代码的重大修改及变更 |
| Disclose Source | 公开源码 | 代码必需公开。如果是基于LGPL协议 下，则只需使用的开源代码公开，不必将整个软件源码公开 |
| Library usage | 库引用 | 该库可以用于商业软件中 |
| Hold Liable | 责任承担 | 代码的作者承担代码使用后的风险及产生的后果 |
| Use Trademark | 商标使用 | 可以使用作者的姓名，作品的Logo，或商标 |
| Sublicensing | 附加许可 | 允许在软件分发传播过程中附加上原来没有的许可条款等 |
各License的约束
对于No license 的情况，你保留所有权利，不允许他人分发，复制或者创造衍生物。当你将代码发表在一些网站上时需要遵守该网站的协议，此协议可能包含了一些对你劳动成果的授权许可。比如你将代码发布到GitHub，那么你就必需同意别人可以查看和Fork你的代码。
在许多国家，默认版权归作者自动拥有，所以Unlicense协议提供了一种通用的模板，此协议表明你放弃版权，将劳动成果无私贡献出来。你将丧失对作品的全部权利，包括在MIT/X11中定义的无担保权利。
| License | 要求 | 允许 | 禁止 |
|---|---|---|---|
| BSD | <ul><li>许可和版权信息</li></ul> | <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>附加许可</li></ul> | <ul><li>责任承担</li></ul> |
| Apache | <ul><li>协议和版权信息</li><li>声明变更</li></ul> | <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li><li>附加许可</li></ul> | <ul><li>责任承担</li><li>商标使用</li></ul> |
| MIT | <ul><li>许可和版权信息</li></ul> | <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>附加许可</li></ul> | <ul><li>责任承担</li></ul> |
| MPL | <ul><li>公开源码(全部)</li><li>协议和版权信息</li></ul> | <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li><li>附加许可</li></ul> | <ul><li>责任承担</li><li>商标使用</li></ul> |
| GPL | <ul><li>公开源码(全部)</li><li>协议和版权信息</li><li>声明变更</li></ul> | <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li></ul> | <ul><li>责任承担</li><li>附加许可</li></ul> |
| LGPL | <ul><li>公开源码(修改部分)</li><li>协议和版权信息</li><li>库引用</li></ul> | <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li><li>附加许可</li></ul> | <ul><li>责任承担</li></ul> |
| No license | <ul><li>协议和版权信息</li></ul> | <ul><li>商用</li><li>私用</li></ul> | <ul><li>分发</li><li>修改</li><li>附加许可</li></ul> |
| Unlicense | <ul><li>N/A</li></ul> | <ul><li>商用</li><li>私用</li><li>分发</li><li>修改</li></ul> | <ul><li>责任承担</li></ul> |
开源软件的区分图
其实这里还有一个需要注意的，那就是专利授权，这可能会引起法律问题。比如BSD、MIT在License里边就没有明确专利授权的声明，这就让采用这种License授权的开源软件有可能存在专利授权的争议。GPL-2.0、LGPL-2.1虽然有专利相关的规定，但没有明确指出专利授权与其如何被利用的方式，这点容易产生争议，GPL-3.0就明确了专利授权，就不会存在这个问题。所以公司商业软件使用开源软件需要注意License的版本和里边的具体的描述，当然我们在采用License的时候也可以附加许可。
你会选择哪种开源授权许可？
参考：
http://opensource.org/licenses/alphabetical
http://choosealicense.com/
https://www.mozilla.org/en-US/MPL/1.1/
http://www.openfoundry.org/tw/legal-column-list/8914-patent-clause-in-foss-licenses
http://blog.csdn.net/techbirds_bao/article/details/8785413
http://www.oschina.net/news/27273/main-os-license-comparison
