——指的是对某个开源软件或项目供给了代码（包括开始的或许修正正）的人或实体（退队、公司、安排等）。

　　依照奉献的先后可分为创始人（an initial Contributor）和参与者（subsequent Contributors）。

　　明显，subsequent Contributors也归于Recipients之列。

　　——指的是Source Code经过编译后，生成的相似“类库”相同的，供给了各种接口供他人运用的方针代码（就如,DLL、JAR等）。

　　3.Derivative Module 和 Separate Module

　　——指的是，依托或包括“开始的”或许“从他人处获取的”开源代码而发生的代码，是对“源代码模块”的增强、改进和连续。

　　——指的是，参阅或凭借“源代码”开发出来的独立的，不包括、不依赖于原“源代码模块”的功能模块。

　　*Eclipse Public License (EPL-1.0)注：原Common Public License 1.0已被Eclipse Public License (EPL-1.0)代替。Apache License, 2.0 (Apache-2.0)Apache Lience答应运用者修正和从头发布代码(以其他协议办法)，答应闭源商业发布和出售。Apache Lience鼓舞代码同享和尊重原作者的著作权。运用Apache Licence协议，需求恪守以下规矩：1.需求给代码的用户一份Apache Lience；2.假如你修正了代码，需求在被修正的文件中阐明；3.在延伸的代码中（修正或衍生的代码）需求带有本来代码中的协议、商标、专利声明和其他本来作者规矩需求包括的阐明。4.假如再发布的产品中包括了Notice文件，则需求在Notice文件中带有Apache Lience。你能够在Notice中添加自己的答应，但不能够表现为对Apache Lience构成更改。Apache Licence是对商业运用友爱的答应。运用者也能够在需求的时分修正代码来满足需求并作为开源或商业产品发布/出售。BSD开源协议（Berkerley Software Distribution）(BSD 3-ClauseBSD 2-Clause)现在分为BSD 3-Clause和BSD 2-Clause。望文生义，3-Clause包括3个条款，2-Clause只需两个。BSD答应运用者修正和从头发布代码(以其他协议办法)，答应闭源商业发布和出售。BSD鼓舞代码同享的一起，要求尊重代码作者的著作权。运用BSD协议，需求恪守以下规矩（2-Clause则不带第3条）：1.假如再发布的产品中包括源代码，则在源代码中有必要带有本来代码中的BSD协议；2.假如再发布的仅仅二进制类库/软件，则需求在类库/软件的文档那个和版权声明中包括本来代码中的BSD协议；3.不能够用开源代码的“作者/组织的姓名”或“本来产品的姓名”做市场推广。关键：商业软件能够运用，也能够修正运用BSD协议的代码。GPL (GNU General Public License)GPL的起点是代码的开源/免费运用和引证/修正/衍生代码的开源/免费运用，但不答应修正后和衍生的代码做为闭源的商业软件发布和出售。GPL具有“传染性”，只需在一个软件中运用(“运用”指类库引证,修正后的代码或许衍生代码)GPL协议的产品,则该软件产品有必要也选用 GPL协议,既有必要也是开源和免费。GPL对商业发布的束缚（引自Java视野论坛的Robbin）:“GPL是针对软件源代码的版权,而不是针对软件编译后二进制版别的版权.你有权免费取得软件的源代码,可是你没有权利免费取得软件的二进制发行版别.GP对软件发行版别仅有的束缚便是:你的发行版别有必要把完好的源代码一起供给.”运用GPL协议，需求恪守以下规矩：1、保证软件从头到尾都以开放源代码办法发布，保护开发效果不被盗取用作商业出售。任何一套软 件，只需其间运用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件自身也就主动成为受 GPL 保护并且束缚的实体。也便是说，此刻它有必要开放源代码。2、GPL 大致便是一个左边版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的表现。你能够去掉一切原作的版权 信息，只需你坚持开源，并且随源代码、二进制版附上 GPL 的答应证就行，让后人能够很明确地得知此软件的授权信息。GPL 精华便是，只需使软件在完好开源 的情况下，尽可能使运用者得到自由发挥的空间，使软件得到更快更好的开展。3、不管软件以何种办法发布，都有必要一起附上源代码。例如在 Web 上供给下载，就有必要在二进制版别（假如有的话）下载的同一个页面，清楚地供给源代码下载的链接。假如以光盘办法发布，就有必要一起附上源文件的光盘。4、开发或保护遵从 GPL 协议开发的软件的公司或个人，能够对运用者收取必定的服务费用。但仍是一句老话——有必要无偿供给软件的完好源代码，不得将源代码与服务做绑缚或任何变相绑缚出售。因为GPL严格要求运用了GPL类库的软件产品有必要运用GPL协议，所以商业软件就不合适选用运用GPL协议的开源代码。关键：商业软件不能运用GPL协议的代码。LGPL (GNU Library or Lesser General Public License)与GPL的强制性开源不同的是，LGPL答应商业软件经过类库引证(link)的办法运用LGPL类库而不需求开源商业软件的代码。可是假如修正LGPL协议的代码或许衍生,则一切修正的代码,触及修正部分的额定代码和衍生的代码都有必要选用LGPL协议。因而LGPL协议的开源代码很合适作为第三方类库被商业软件引证,但不合适期望以LGPL协议代码为根底,经过修正和衍生的办法做二次开发的商业软件选用。关键：商业软件能够运用，但不能修正LGPL协议的代码。MIT (MIT license)[MIT答应证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称「X条款」（X License）或「X11条款」（X11 License）]MIT是和BSD相同宽范的答应协议,作者只想保存版权,而无任何其他了束缚.也便是说,你有必要在你的发行版里包括原答应协议的声明,不管你是以二进制发布的仍是以源代码发布的。关键：商业软件能够运用，也能够修正MIT协议的代码，乃至能够出售MIT协议的代码。MPL (Mozilla Public License 1.1)

　　MPL协议答应免费重发布、免费修正，但要求修正后的代码版权归软件的建议者。这种授权保护了商业软件的利益，它要求根据这种软件的修正无偿奉献版权给该软件。这样，环绕该软件的一切代码的版权都会集在建议开发人的手中。但MPL是答应修正，无偿运用得。MPL软件对链接没有要求。

　　EPL答应Recipients恣意运用、仿制、分发、传达、展现、修正以及改后闭源的二次商业发布。运用EPL协议，需求恪守以下规矩：1. 当一个Contributors将源码的全体或部分再次开源发布的时分,有必要持续遵从EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权；

　　2. EPL协议下,你能够将源码不做任何修正来商业发布.但假如你要发布修正后的源码,或许当你再发布的是Object Code的时分,你有必要声明它的Source Code是能够获取的,并且要奉告获取办法；

　　3. 当你需求将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时分,你能够将整个Project/Product以私家的协议发布,但要声明哪一部分代码是EPL下的,并且声明那部分代码持续遵从EPL；