每次访问github时，自述都包含各种格式。 该软件符合xx协议。 一开始我没怎么注意，但我以为这些是一样的。 之后，当我访问很多地方时，我开始意识到它因开源软件协议而异。 那么，这些协议有什么不同呢？ 首先请看下图：
虽然说了很长时间，但是耐心地看看也不错吧。
开源协议之前基本名词概况：
1. Contributors 和 Recipients
Contributors是向某个开放源代码软件或项目提供代码(包括最初或变更的内容)并公开的人或实体(团队、公司、组织等)，Contributors是指某个软件的
Recipients指的是开放源代码软件或项目的获取者，显然subsequent Contributors也属于Recipients的列表。
2. Source Code 和 Object Code
源代码是指以多种语言编写的源代码，通过源代码与文档结合，可以了解整个软件的体系结构和具体功能的实现方式等。
Object Code是提供各种接口供他人使用的目标代码，如编译Source Code后生成的“类库”。 我的理解是，这是常见的DLL、ActiveX、OCX控件这样的性质。 （
澄清这两个概念的目的是，一些开源只发布Object Code。 当然，很多都发行了Source Code。 很多协议对“发布哪个Code时应该怎么办”也有明确的制约。
3. Derivative Module 和 Separate Module
Derivative Module是依赖或包含“最初”或“从他人处获得”的开源代码而生成的代码，是对原始“源代码”进行强化(不等于增加)、改善、持续的模块
Separate Module是指参考或借用原来的“源代码”开发的独立的、不依赖于原来的“源代码模块”的“独立的模块”。理解这两个概念的目的是
虽然现在存在的开源合同很多，但是由Open Source Initiative组织批准的开源合同现在有58种。 BSD、GPL、LGPL、MIT等一般的开源合同是OSI批准的合同。 如果要对自己的代码进行开源，最好选择这些经过批准的开源协议。
http://www.Sina.com/http://www.Sina.com /
BSD开源协议是给用户很大自由的协议。 基本上使用者可以“随心所欲”自由使用。 可以修改源代码，也可以将修改后的代码作为开源或专有软件重新分发。 但是，作为“随心所欲”前提的qcdxlc发行使用BSD协议的代码时，或者以BSD协议代码为基础二次开发本公司产品时，需要满足三个条件
1 .如果重新发行的产品包含源代码，则源代码中必须包含原始代码的BSD协议。
2 .如果只有二进制库/软件重新发行，则库/软件的文档和版权声明必须包括原始代码的BSD协议。
3 .不得以开放源代码作者/机构名称和原始产品的名称进行营销。
其实，这几条规则约定的目的也只是达到一个目的。是他人的，一旦他人在BSD上开源，就不能在不做任何声明的情况下属于自己，也不能以他人的名义推进业务。 只对自己的东西有绝对的控制权。
例如，使用开放源代码(a )进行修改或其他添加后，产品b应运而生。 此时，b的控件可以自己决定。 可以使用任何协议开源，也可以关闭源代码并商业公开。 但是，如果b中包含a或a的一部分(因为如果一点也不包含，就不称为修正)。 在那种情况下，必须提到b产品的著作权表示中使用了a。
BSD代码鼓励共享代码，但必须尊重代码作者的版权。 BSD也可用于BSD代码，因为使用者可以修改并重新发布代码
因为开发并销售商务软件，所以是商务集成非常友好的协议。 许多企业在选择开源产品时首选BSD协议。 因为完全控制这些第三方的代码，所以可以在必要的时候修改或者进行二次开发。
开源协议说明：
Apache Licence是著名的非营利开源组织Apache采用的协议。 该协议与BSD类似，同样鼓励共享代码和尊重原作者的版权，同样允许修改代码后发布(作为开源或商业软件)。 应满足的条件也与BSD相同
类似:
1. 需要给代码的用户一份Apache Licence
2. 如果你修改了代码,需要再被修改的文件中说明.
3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明.
4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence.你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改.
Apache Licence也是对商业应用友好的许可.使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售.
GPL (Gun General Public License)
我们很熟悉的Linux就是采用了GPL.GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样.GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售.这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了.
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL协议的产品,则该软件产品必须也采用 GPL协议,既必须也是开源和免费.这就是所谓的“传染性”.GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势.
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础.
最常见的开源协议,使用它作为授权协议的有大名鼎鼎的 Linux .GPL最显著的两个特点就是网上称为的“病毒性传播”和“不允许闭源的商业发布”.
所谓的“病毒性传播”,指的是,GPL规定,所有从GPL协议授权的源码衍生出来的(即上面提到的Derivative Module),或者要跟GPL授权的源码混着用的Project,都要遵循GPL协议,就像病毒一样,粘上了关系,就“中毒”了.GPL这样规定的目的是,保证在GPL协议保护下的产品,不会再受到其他协议或者授权的约束.即让跟GPL有关系的源码都能免费获取.举个例子,如果你的改进的Linux中使用了GPL授权下的开源模块(也必须使用,你不可能自己重新去做个内核吧,如果做出来了,你也没必要叫Linux了.),那么你整个Linux产品也必须遵循GPL协议去开源,不能以其他方式去开源发布,更不允许闭源发布.这样一来,就不会出现这样一个Linux–这个功能是GPL协议授权的,可以免费获取源码,而另外一个功能是其他协议下的,拿不到源码.这点规定对使用或者研究该产品的人来说,是一个极大的便利.
而“不允许闭源商业发布”指的是,在GPL授权下,你的软件产品可以商业发布,拿去卖钱,但是在这同时,你也必须将该产品的源码以GPL协议方式开源发布出去,供他人免费获取.也许有人会迷惑,拿去卖,又同时开源,那谁来买阿?这个产品怎么赚钱呢??这就涉及到开源产品的商业模式的问题了,想了解相关一些信息的话,可以看看以上我给出链接的一些文章.至于后面,可能会写一篇关于开源项目的商业模式的随笔.
GPL协议下的商业发布的一个关键点就像 Java 视线论坛的 Robbin所说的,GPL是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权.你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本.GP对软件发行版本唯一的限制就是:你的发行版本必须把完整的源代码一同提供.
它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似.
LGPL
LGPL是GPL的一个为主要为类库使用设计的开源协议.和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同. LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码.这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售.
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议.因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用.
GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品.
CPL(Common Public Liecense)
CPL是IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议.主要用于一些IBM或跟IBM相关的开源软件/项目中.如很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等.
CPL也是一项对商业应用友好的协议.它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布,这点跟 BSD 很类似,也属于自由度比较高的开源协议.但是,需要遵循:
1. 当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循 CPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权.
2. CPL协议下,你可以将源码不做任何修改来商业发布.但如果你要将修改后的源码其开源,而且qcdxlc再发布的是Object Code的时候,你必须声明它的Source Code 是可以获取的,而且要告知获取方法.
3. qcdxlc需要将CPL下的源码作为一部分跟其他私有的源码混和着成为一个 Project 发布的时候,你可以将整个Project/Product 以私人的协议发布,但要声明哪一部分代码是CPL下的,而且声明那部分代码继续遵循CPL.
4. 独立的模块(Separate Module),不需要开源.
MIT(Massachusetts Institute of Technology)
MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.
读完以上，大家之后再在github上看到相关开源协议不会再一脸懵逼了吧！