开源世界里面必须遵循各种协议，这里进行汇总。支持开源.
开源BSD协议
BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
- 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在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协议
这是一份 GNU 较宽松公共许可证非正式的中文翻译。它不是自由软体基金会所发布，并且不能适用于使用 GNU LGPL 的软体 —— 只有 GNU LGPL 英文原文的版本才行。然而，我们希望这份翻译能帮助中文的使用者更了解 GNU LGPL。
GNU 较宽松公共许可证
1999.2, 第 2.1 版
版权所有 (C) 1991, 1999 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
允许每个人复制和发布本授权文件的完整副本，
但不允许对它进行任何修改。
[这是第一次发表的较宽松公共许可证 (Lesser GPL) 版本。它同时也可视为 GNU 函数库公共许可证 (GNU Library Public License) 第 2 版的后继者，故称为 2.1 版]
开源MIT协议
MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称「X条款」（X License）或「X11条款」（X11 License）
MIT内容与三条款BSD许可证（3-clause BSD license）内容颇为近似，但是赋予软体被授权人更大的权利与更少的限制。
被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。
被授权人可根据程式的需要修改授权条款为适当的内容。
在软件和软件的所有副本中都必须包含版权声明和许可声明。
此授权条款并非属copyleft的自由软体授权条款，允许在自由/开放源码软体或非自由软体（proprietary software）所使用。
此亦为MIT与BSD（The BSD license, 3-clause BSD license）本质上不同处。
MIT条款可与其他授权条款并存。另外，MIT条款也是自由软体基金会（FSF）所认可的自由软体授权条款，与GPL相容
开源Apache协议
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：
- 需要给代码的用户一份Apache Licence。
- 如果你修改了代码，需要再被修改的文件中说明。
- 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
- 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
开源MPL协议
MPL是The Mozilla Public License的简写，是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对 源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA 认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处:
◆ MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个 豁口。
◆ MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
◆ 对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是 专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
◆ 对源代码的定义:而在MPL（1.1版本）许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择 取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’（原文为‘Script’），或者不是与初始 源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
◆ MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。
开源CDDL协议
CDDL全称Common Development and Distribution License.它是一个开源许可证书，采用著名的Mozilla公共许可证（MPL），使其在未做任何改动的情况下可重用。我们希望得到一个能为开源提供保护和自主的非盈利版权许可证，这个许可证也可以用于创建更大的作为商业用途的工程。
CDDL是否已获得OSI认可？
是的。CDDL满足 Open Source Definition 的要求并且已经获得 开放源码促进会的认可作为开放源代码的许可证。
为什么要再写一份开放源代码许可证？
我们参阅了很多现有的开源许可证书但是没有找到适合OpenSolaris源代码的，所以我们修改了最符合我们需求的许可证（MPL）并且发现这些改动使得开源贡献者的权力更加清晰。我们将CDDL设计成可重用的，使得它对其他类似的开源项目同样具有吸引力。
所有的Solaris操作系统是否都必须按照CDDL来发布？
我们打算发布尽可能多的符合CDDL许可的源代码。Solaris操作系统使用的第三方开源软件代码将保留其已有的许可证书。例如，Opensolaris源代码库中的 Perl 版本就遵守Perl Artistic License许可。那些无法开源获得的代码将以二进制的形式提供。关于特定技术是否可获取的信息，请参考roadmap。
- 为什么你们要将MPL作为CDDL的基础？
MPL是一个公认的许可证书并且有着Sun所要的一些特性，包括： - 要求能在开源许可证书下获得被修改的代码;
- 可以在不同的许可证书下发布可执行文件的权力；
- 是一个“基于文件”的修改和覆盖软件的定义；
- 是一个清楚的专利许可证。
你们对MPL做了哪些改进？
除了保留所有所希望的MPL特性以外(参考前面)，CDDL许可证被设计成可重用的，并做了一些改进使其更加通用： - 要求注意点简单明了;
- 阐明了修改代码的定义使得人们更加容易理解许可中包括的以及未包括的内容；
- 涉及了一些关于法律、地点、权限选择的问题；
- 添加了一个按照特定许可版本的发布软件的方法。
我们提供了一个 改动综述，以及redline diffs (PDF)说明MPL1.1和CDDL之间的区别。
为什么不直接使用GPL 或 LGPL作为非盈利版权许可？
我 们需要这样一个开源许可，在这个许可证书下发行的文件可以和在其他证书下发行的文件关联起来。尽管像GPL这样的许可允许动态代码链接。在上述情况，我们 还需要能够发行可以静态链接在其他许可下获得的文件的这样一个软件。并且，我们想让他人能够通过不同许可证书扩展OpenSolaris。这些只能在一个 类似于MPL的许可下实现；但是我们不能直接使用MPL因为它不是一个可以被其他人重复使用的“许可模版”。所以我们起草了MPL的另一种形式，将其变成 一个模版许可，并利用这个机会作为朝着减少许可扩散所迈出的一步。
CDDL如何看待专利？
CDDL为 在此许可下发布的代码提供了清楚的专利许可。这意味着您可以使用、修改并且重新发布CDDL授权的代码而不需要担心代码开发者(包括Sun)的任何技术专 利。许可证同时包括了一项条款如果有任何人因为他们所提供的代码而对一个开发者进行专利起诉的话，该条款通过废除代码所有权来阻止任何对于开发者的专利指 控。
CDDL下的代码许可与其他开源许可可以结合使用吗?
CDDL是基于文件的，也就是说CDDL下的文件许可可以与其他文件许可（开源或所有权）并用。但是其他许可可能有不同的限制，有可能阻止并用的可能；那么你需要阅读并遵守这些限制。
双许可怎么办呢？我可以既遵守CDDL，也遵守其他许可吗？
可以，如果你是拥有代码版权，你可以选择遵守多个许可，包括CDDL。
如果在我的私有产品中使用CDDL许可的代码，我也需要共享我的源代码吗？
需要。对于任何遵守CDDL许可的源文件，以及你所做的任何修改都需要共享。但是，你不必将你的私有源文件共享。
如果我为OpenSolaris贡献代码，除了相关许可外，我还需要做些什么？
贡献给OpenSolaris的代码必须遵守CDDL许可，另外你必须提交一个签名的 贡献者合同. 。每个项目有不同的贡献提交流程。你可以联系项目列表中的项目负责人来获得具体信息。
我可以用OpenSolaris的一部分代码来构建其他项目吗？
可以，你可以在其他项目中使用OpenSolaris的代码，但是你需要遵守CDDL许可的条款。
我可以重新发布或出售我修改后的OpenSolaris代码吗？
可以，你可以修改，然后遵守CDDL许可将代码重新发布，如果你愿意也可以进行收费。但是，你需要遵循CDDL的条款，包括遵守CDDL许可将你修改的代码共享。
我可以商用OpenSolaris源代码或二进制文件吗？
可以。你可以在商用产品中使用OpenSolaris源代码。需要注意的是，如果你使用遵循CDDL许可的源代码来构建二进制文件并进行发布，你需要遵循CDDL条款，并遵循CDDL许可将相应的源代码发布出去。详情参见许可。
我可以在我的项目（与OpenSolaris项目无关）中使用CDDL许可吗？
可以，此许可可以被任何人重用。
Sun会将OpenSolaris源代码拿走，不继续开源吗？
不会，代码对开源社区永远可得。