作为程序员你肯定或多或少的接触过开源项目，开源项目使我们软件开发小伙伴避免重复造轮子，把别人写好的代码或库直接拿来使用，可以大大节省我们的时间，提高工作效率，我们都是开源项目的受益者，但是又有多少人对开源协议真正了解呢？
多数人对待开源项目都是拿来主义，对开源项目的开源协议却很少关注（汗，我曾经也是这样），这可能和国内对知识产权不够重视的文化氛围有关，或是和目前国内的软件开源环境还是处在初级阶段有关，具体原因此处不做深入讨论。但我认为作为一个有节操，有理想的程序员，应该尊重和感激这些为开源项目辛苦付出的分享者们，了解与遵守开源项目的开源协议要求，就是我们尊重他们的第一步。下面就介绍一下现今主流的开源协议。

什么是开源协议

开源许可是一种计算机软件和其它产品的许可证，其允许源代码，蓝图或设计在规定的条款和条件下被使用，修改和共享。允许最终用户和商业公司审查和修改源代码，蓝图或设计，以满足他们自己的定制，好奇心或故障排除需求。开源许可软件大多是免费提供的（但并非必须如此）。只允许非商业的（个人使用的）重新分配或修改的源代码，通常不被认为是开源许可。但开源许可证可能有一些限制，特别是关于软件来源的表述，例如要求保留作者姓名和代码中的版权声明，或者要求重新分发许可软件仅在相同的许可下（如在Copyleft许可中）。一组流行的开源软件许可证是由开源计划(OSI)根据其开源定义(OSD)批准的。【Wikepedia】

为什么要制定开源协议

首先是对作者的保护，防止知识成果被恶意利用。

• 开源协议中一般都包含免责声明(禁止代码的作者承担代码使用后的风险及产生的后果)，比如你开源了一个破解智能锁的代码，如果有人利用这个去盗窃导致他人损失，你是无需承担责任的。

其次是对使用者的保护，方便使用者。

• 使用者一看就知道自己允许进行哪些操作，不允许进行哪些操作。
• 未添加协议的代码默认是作者保留所有权利的(对此不同国家的法律可能稍微存在区别)，这就像一颗定时炸弹，如果你在项目中使用了这一份没有协议的代码，原作者只要能证明你未经许可使用了他的代码，是能够起诉你的。
  本节引自GcsSloop的【程序员不可不知的版权协议】

如何选择合适的开源协议?

由于开源协议种类众多，作为普通人很难搞懂它们之间的区别，即便是常见的协议大家也不完全知道协议的内容，那么如何快速的选择一款适合自己的协议呢？如果你是一个怕麻烦的人，下面的建议或许对你有有帮助。

主流开源协议介绍

GPL协议

即通用性公开许可证(General Public License，简称GPL)。GPL同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。
GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的 整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通 的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为copyleft，表示与copyright(版权)的概念“相左”。

• 通俗点说，就是GPL协议具有感染性，一旦项目中使用了以GPL协议开源的代码，那么项目中的其他部分，也要遵循GPL协议，所以GPL不具备商业友好性，
• GPL这样设计的目的是为了使开源代码能够更好的传播和被改进，改进的代码不可以闭源，GPL是一个比较纯粹的、理想主义的开源协议。

GPL详细信息

AGPL协议

原有的GPL协议，由于现在网络服务公司兴起（如：google）产生了一定的漏洞，比如使用GPL的自由软件，但是并不发布与网络之中，则可以自由的使 用GPL协议确不开源自己私有的解决方案。AGPL则增加了对此做法的约束。
GPL的约束生效的前提是“发布”软件，即使用了GPL成分的软件通过互联网或光盘release软件，就必需明示地附上源代码，并且源代码和产品也受GPL保护。
这样如果不“发布”就可以不受约束了。比如使用GPL组件编写一个Web系统，不发布这个系统，但是用这个系统在线提供服务，同时不开源系统代码。
AGPL详细信息

LGPL协议

宽松公共许可证（Lesser General Public License）或库通用公共许可证（Library General Public License）基于 LGPL 的软件也允许商业化销售，但不允许封闭源代码。
如果您对遵循 LGPL 的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承 LGPL 协议，不允许封闭源代码。但是如果您的程序对遵循 LGPL 的软件进行任何连接、调用而不是包含，则允许封闭源代码。

• LGPL较GPL具备一定的商业友好性。以动态库的引用方式使用开源软件是不需要开源商业项目的所有代码的。
• 如以源代码方式使用，或对代码做了修改，则与GPL协议类似，要公开相关的改进代码。

LGPL详细信息

Apache协议

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：

• 需要给代码的用户一份Apache Licence
• 如果你修改了代码，需要在被修改的文件中说明。
• 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
• 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
Apache协议详细信息

BSD 协议：

BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

• 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
• 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
• 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者 二次开发。
BSD协议详细信息

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相容。
MIT协议详细信息

参考文章：
1.软件许可证——GPL、AGPL、LGPL、Apache、ZLIB/LIBPNG、MIT
2.作为前端，你需要了解的开源协议知识
3.解析GPL3.0与GPL2.0及其草案的区别