开源协议：为什么要添加开源协议？那又如何选择开源协议
Author：zhoulujun Date：
开源软件在追求“自由”的同时，不能牺牲程序员的利益，否则将会影响程序员的创造激情，因此世界上现在有 60 多种被开源促进组织（https://opensource.org/licenses/alphabetical）认可的开源许可协议来保证开源工作者的权益。
开源协议规定了你在使用开源软件时的权利和责任，也就是规定了你可以做什么，不可以做什么。
开源协议虽然不一定具备法律效力，但是当涉及软件版权纠纷时，开源协议也是非常重要的证据之一。
为什么要添加开源协议?
首先是对作者的保护，防止知识成果被恶意利用。
开源协议中一般都包含免责声明(禁止代码的作者承担代码使用后的风险及产生的后果)，比如你开源了一个破解智能锁的代码，如果有人利用这个去盗窃导致他人损失，你是无需承担责任的。
其次是对使用者的保护，方便使用者。
使用者一看就知道自己允许进行哪些操作，不允许进行哪些操作。
未添加协议的代码默认是作者保留所有权利的(对此不同国家的法律可能稍微存在区别)，这就像一颗定时炸弹，如果你在项目中使用了这一份没有协议的代码，原作者只要能证明你未经许可使用了他的代码，是能够起诉你的。
如何选择开源协议
乌克兰程序员Paul Bagwell，画了一张分析图，说明应该怎么选择。
通常情况下：
看看维基百科： https://zh.wikipedia.org/wiki/自由及開放原始碼軟體許可證比較
| 许可证 | 作者 | 最新版本 | 公布日期 | 与使用不同许可证的代码链接 | 在不同的许可证下重新发布 |
|---|---|---|---|---|---|
| Academic Free License | Lawrence E. Rosen | 3 | 2002 | 是 | 是 |
| Affero通用公共许可证 | 自由软件基金会 | 3 | 2007 | 仅 AGPLv3 + GPLv3 | 否 |
| Apache许可证 | Apache软件基金会 | 2.0 | 2004 | 是 | 是 |
| 苹果公共源代码许可证 | 苹果公司 | 2.0 | 20032003年8月6日 | 是 | 否 |
| 艺术许可协议 | 拉里·沃尔 | 2.0 | 2000 | 是 | 带有限制 |
| Berkeley Database License | 甲骨文公司 | ? | 20082008年2月7日 | 否 | 否 |
| BSD许可证 | 加州大学董事会 | ? | ? | 是 | 是 |
| Boost许可证 | Boost.org | 1.0 | 20032003年8月17日 | 是 | 是 |
| CeCILL（英语：CeCILL） | CEA / CNRS / INRIA | 2.0 | 20052005年5月21日 | 否 | 否 |
| 通用开发与散布许可证 | Sun微系统 | 1.0 | 2004-122004年12月1日 | 是 | 是 |
| Code Project Open License | The Code Project | 1.0 | 2007 | 是 | 否 |
| Common Public License | IBM | 1.0 | 2001年5月 | 是 | 否 |
| Cryptix General License | Cryptix基金会 | ? | 1995 | 是 | 是 |
| Eclipse公共许可证 | Eclipse基金会 | 1.0 | 2004-02February 2004 | 是 | 否 |
| Educational Community License | ? | 1.0 | ? | 是 | 是 |
| Eiffel Forum License | NICE | 2 | 2002 | 是 | 是 |
| 欧洲联盟公共许可证 | 欧洲联盟委员会 | 1.1 | 20092009年1月 | 是 | 有明确的兼容性列表 |
| Fair Licence | ? | 不适用 | 2004 | 是 | 是 |
| GNU通用公共许可证 | 自由软件基金会 | 3.0 | 20072007年6月 | 否 | 否 |
| GNU宽通用公共许可证 | 自由软件基金会 | 3.0 | 20072007年6月 | 是 | 否 |
| Hacktivismo Enhanced-Source Software License Agreement | Hacktivismo（英语：Hacktivismo）/死牛崇拜 | ? | 20022002年11月26日 | ? | ? |
| IBM公共许可证（英语：IBM Public License） | IBM | 1.0 | 19991999年8月 | 是 | 是 |
| 英特尔开放源代码许可证 | 英特尔 | ? | ? | 是 | 是 |
| ISC许可证 | ISC | ? | 20032003年6月 | 是 | 是 |
| LaTeX项目公共许可证 | LaTeX项目 | 1.3c | ? | 是 | 是 |
| MIT许可证 | 麻省理工学院 | 不适用[note 1] | 1988 | 是 | 是 |
| Mozilla公共许可证 | Mozilla基金会 | 2.0 | 20122012年1月3日 | 是 | 有限 |
| 网景公共许可证（英语：Netscape Public License） | 网景 | 1.1 | ? | 是 | 有限 |
| OPaC Free Public License | OPaC bright ideas | ? | 1998 | 否 | 否 |
| Open Software License | Lawrence Rosen | 3.0 | 2005 | 是 | 否 |
| OpenSSL许可证 | OpenSSL项目 | ? | ? | 是 | ? |
| PHP许可证 | PHP开发团队 | 3.01 | ? | 是 | 是 |
| 公有领域 | 不适用 | 不适用 | 不适用 | 是 | 是 |
| Python软件基金会许可证 | Python软件基金会 | 2 | ? | 是 | 是 |
| QPL | Qt发展框架 | ? | ? | 否 | 否 |
| Sun Industry Standards Source License | Sun微系统 | ? | ? | 是 | 否 |
| Sun Public License | Sun微系统 | ? | ? | 是 | 否 |
| Sybase Open Watcom Public License | ? | ? | ? | 是 | 否 |
| W3C Software Notice and License | ? | ? | ? | 是 | 是 |
| XCore Open Source License | XMOS | ? | 2011February 2011 | 是 | 是 |
| XFree86 1.1版许可证 | ? | ? | ? | 是 | 是 |
| Zlib授权 | ? | ? | ? | 是 | 是 |
| Zope公共许可证 | Zope基金会 | 2.1 | ? | 是 | 是 |
常见的开源协议简介
GNU GPL（GNU General Public License，GNU通用公共许可证）
只要软件中包含了遵循 GPL 协议的产品或代码，该软件就必须也遵循 GPL 许可协议，也就是必须开源免费，不能闭源收费——GPL传染性，因此这个协议并不适合商用软件。
GPL协议和BSD，Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
遵循 GPL 协议的开源软件数量极其庞大，包括 Linux 系统在内的大多数的开源软件都是基于这个协议的。
| 特点 | 说明 |
|---|---|
| 复制自由 | 允许把软件复制到任何人的电脑中，并且不限制复制的数量。 |
| 传播自由 | 允许软件以各种形式进行传播。 |
| 收费传播 | 允许在各种媒介上出售该软件，但必须提前让买家知道这个软件是可以免费获得的；因此，一般来讲，开源软件都是通过为用户提供有偿服务的形式来盈利的。 |
| 修改自由 | 允许开发人员增加或删除软件的功能，但软件修改后必须依然基于GPL许可协议授权。 |
BSD开源协议(original BSD license、FreeBSD license、Original BSD license)
BSD 协议基本上允许用户“为所欲为”，用户可以使用、修改和重新发布遵循该许可的软件，并且可以将软件作为商业软件发布和销售，前提是需要满足下面三个条件：
如果再发布的软件中包含源代码，则源代码必须继续遵循 BSD 许可协议。
如果再发布的软件中只有二进制程序，则需要在相关文档或版权文件中声明原始代码遵循了 BSD 协议。
不允许用原始软件的名字、作者名字或机构名称进行市场推广。
BSD 对商业比较友好，很多公司在选用开源产品的时候都首选 BSD 协议，因为可以完全控制这些第三方的代码，甚至在必要的时候可以修改或者二次开发。
Apache Licence 2.0
Apache 许可证版本 有多个版本，其实相差不大。我也没有仔细研究(Apache License， Version 2.0、Apache License， Version1.1、Apache License， Version 1.0)
Apache 和 BSD 类似，都适用于商业软件。Apache 协议在为开发人员提供版权及专利许可的同时，允许用户拥有修改代码及再发布的自由。
现在热门的 Hadoop、Apache HTTP Server、MongoDB 等项目都是基于该许可协议研发的，程序开发人员在开发遵循该协议的软件时，要严格遵守下面的四个条件：
该软件及其衍生品必须继续使用 Apache 许可协议。
如果修改了程序源代码，需要在文档中进行声明。
若软件是基于他人的源代码编写而成的，则需要保留原始代码的协议、商标、专利声明及其他原作者声明的内容信息。
如果再发布的软件中有声明文件，则需在此文件中标注 Apache 许可协议及其他许可协议。
LGPL(GNU Lesser General Public License)
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品
MIT(MIT)
目前限制最少的开源许可协议之一（比 BSD 和 Apache 的限制都少），只要程序的开发者在修改后的源代码中保留原作者的许可信息即可，因此普遍被商业软件所使用。
使用 MIT 协议的软件有 PuTTY、X Window System、Ruby on Rails、Lua 5.0 onwards、Mono 等。
但是如果修改 LGPL 协议的代码或者衍生品，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
参考内容：
开源协议是什么？有哪些？如何选择？ http://c.biancheng.net/view/2947.html
如何选择开源许可证？ https://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html
主流开源协议之间有何异同？ - GcsSloop的回答 - 知乎 https://www.zhihu.com/question/19568896/answer/122973704
《开源时代》2010.02 第十七期
转载本站文章《开源协议：为什么要添加开源协议？那又如何选择开源协议》,
请注明出处：https://www.zhoulujun.cn/html/res/law/popularizingLaw/8575.html