作为一个开源爱好者，我们经常会写一些开源的软件或者工具在网上分享，或者为一些其他的开源软件贡献一些自己的力量，但是对于开源许可（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是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 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也是对商业应用友好的许可。使用者也可以修改代码来满足需要，并把修改过的代码作为开源或商业产品发布/销售。
Massachusetts Institute of Technology简称MIT，也就是大名鼎鼎的麻省理工学院，最早于1988年由MIT起草，跟BSD类似，作者只想保留版权，而无任何其他了限制。
也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。商业软件可以使用，也可以修改MIT协议的代码，甚至可以出售MIT license (MIT)的代码。
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)
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)
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是版权许可证。相当于软件版权。软件版权属于知识产权的著作权范畴，具有知识产权的特征，即时间性，专有性和地域性。软件版权在法律上称为“计算机软件著作权”。属于著作权（知识产权）的一种。国家颁布有《计算机软件保护条例》,保护权益人的软件著作权。
自由软件/开源软件是自由的，免费的，源代码开放的，我们可自由下载安装和使用。同时，为了维护作者和贡献者的合法权利，保证这些软件不被一些商业机构或个人窃取，影响软件的发展，开源社区开发出了各种的开源许可协议。
我们常用的开源软件协议大致有GPL、BSD、MIT、Mozilla、Apache和LGPL
先看看网上搜索的第一张表格
详述 GitHub 中声明 LICENSE 的方法
当我们在 GitHub 浏览一些开源项目时，我们经常会看到这样的标志：
如上图所示，Apache-2.0，我们可以将其称之为开源许可证，那么到底开源许可证是什么呢？
开源许可证即授权条款。开源软件并非完全没有限制。最基本的限制，就是开源软件强迫任何使用和修改该软件的人承认发起人的著作权和所有参与人的贡献。任何人拥有可以自由复制、修改、使用这些源代码的权利，不得设置针对任何人或团体领域的限制；不得限制开源软件的商业使用等。而许可证就是这样一个保证这些限制的法律文件。
常见的开源许可证包括：
Apache License 2.0
GNU General Public License v3.0
MIT License
开源许可证种类很多，以上三个许可证是比较常用的。至于 GitHub 都允许什么类型的许可证，以博主的项目cg-favorite-list为例：
如上图所示，在项目首页，点击Create new file，创建名为LICENSE文件：
实际上，当我们键入LICENSE文件名的时候，GitHub 就已经自动提示Choose a license template选项啦，点击进入：
如上图所示，最左侧展示了 GitHub 可以选择的开源许可证名称，以MIT License为例，点击之后，中间部分显示具体开源许可证的内容。在此处，我们可以自由选择自己想要的许可证，然后点击Review and submit：
标注 1：Commit directly to the master branch.
标注 2：Create a new branch for this commit and start a pull request.
如上图所示，在这里，我们有两个选择。如果我们选择 标注 1 所示的内容，则直接将此许可证提交到master分支；如果我们选择 标注 2 所示的内容，则是新建立一个分支，然后我们可以提PR到master，再进行合并。在此，我们选择 标注 1 所示的内容，直接将MIT License提交到master分支：
如上图所示，我们已经为cg-favorite-list项目创建了一个开源许可证。那么，你还在等什么？赶紧为你的项目创建开源许可证吧！