随着各个国家以及国内的知识产权法律逐渐的完善，同时各个公司的程序员普遍会引用各种开源项目或组件.....这使得越来越多的涉及开源许可，商业知识产权纠纷，恶意知识产权侵权索赔案件涌现出来了。如果你不想一不小心被起诉，请君阅读并收藏本文。
a1)设置开源协议能够对作者进行一些保护，防止知识成果被恶意利用。
开源协议中一般都包含免责声明(禁止代码的作者承担代码使用后的风险及产生的后果)，比如你开源了一个破解智能锁的代码，如果有人利用这个去盗窃导致他人损失，你是无需承担责任的。a2)重视开源协议对使用者（引用开源代码或组件的人）起到保护作用，避免知识产权相关的法律纠纷。
使用者一看就知道自己被许可允许进行哪些行为（拷贝，分发，修改，发布，声明，售卖等），不允许进行哪些行为。未添加协议的代码默认是作者保留所有权利的(对此不同国家的法律可能稍微存在区别)，这就像一颗定时炸弹，如果你在项目中使用了这一份没有协议的代码，原作者只要能证明你未经许可使用了他的代码，是能够起诉你的。B)开源协议的基本常识b1)开源项目中的License是什么？
LICENCE 是软件的授权许可，详细声明了获得代码后拥有的权利，哪些行为是允许的，哪些行为是禁止的。软件的版权许可证可有很多方式，本文仅讨论开源软件协议 Open Source License。
如下图所示：
开源许可示例
一般我们不需自己写许可协议，更靠谱的是选择一种比较流行的开源协议，省时省力，更便于自己作品的传播，于人于己都有利。
除了直接使用开源代码，即便是仅仅受一个项目的启发（未引用一行代码），国外一些项目作者依然会声明受某某项目启发： Inspired by XXX link: https://www.xxxx.com
b2)开源协议中涉及的术语。
协议和版权信息 (License and copyright notice)：在代码中保留作者提供的协议和版权信息。声明变更 (State Changes)：在代码中声明对原来代码的重大修改及变更。公开源码 (Disclose Source)：代码必需公开。库引用 (Library usage)：该库可以用于商业软件中。责任承担 (Hold Liable)：代码的作者承担代码使用后的风险及产生的后果。如果禁止，那么作者将不会承担责任，可以理解为免责条款。商标使用 (Use Trademark)：可以使用作者的姓名，作品的Logo，或商标。附加协议 (Sublicensing)：允许在软件分发传播过程中附加上原来没有的协议条款等。分发（distribution）:除了 Affero GPL (AGPL) ，其他许可证都规定只有在”分发”时，才需要遵守许可证。换言之，如果不”分发”，就不需要遵守。简单说，分发就是指将版权作品从一个人转移到另一个人。这意味着，如果你是自己使用，不提供给他人，就没有分发。另外，这里的”人”也指”法人”，因此如果使用方是公司，且只在公司内部使用，也不需要遵守许可证。云服务（SaaS）是否构成”分发”呢？答案是不构成。所以你使用开源软件提供云服务，不必提供源码。但是，Affero GPL (AGPL) 许可证除外，它规定云服务也必须提供源码.专利: 某些许可证（Apache 2 和 GPL v3）包含明确的条款，授予用户许可，使用软件所包含的所有专利。另一些许可证（BSD、MIT 和 GPL v2）根本没提到专利。但是一般认为，它们默认给予用户专利许可，不构成侵犯专利。总得来说，除非有明确的”保留专利”的条款，使用开源软件都不会构成侵犯专利.披露要求：所有的开源许可证都带有”披露要求”（notice requirement），即要求软件的分发者必须向用户披露，软件里面有开源代码。一般来说，你只要在软件里面提供完整的原始许可证文本，并且披露原始作者，就满足了”披露要求”.C)常见开源协议间的区别以及如何选择?当我们了解各种开源协议许可及之间的差异时，我们才可以在众多技术上可选的项目中筛选协议类型，为我们自己的项目研发过程保驾护航，避免未来被起诉和陷入知识产权纠纷。
c1)从引用者视角看协议间的区别。
主流开源协议之间的差异
各主流协议对应的声明
附1：常用开源协议的宽松程度：
MIT>BSD>Apache>LGPL>MPL>GPL>AGPL.
附2：一个来源于专业的开源许可风险识别平台WhiteSource上的分析报告(绿色代表风险低，红色代表风险高)
开源协议的知识产权纠纷风险程度
c2)从项目发布作者角度看协议间的区别。
开源作者如何选择开源许可
D)常见开源协议的详细介绍d1)BSD（Berkeley Software Distribution license）
BSD-2-ClauseBSD-3-ClauseBSD可证也来源于大学，与MIT差不多，也非常简单、慷慨。
BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。前提是当你发布使用了BSD协议的代码，或者以BSD协议代码为基础开发自己的产品时，需要满足三个条件：
如果再发布的产品中包含源代码，则在源代码中必须带有原代码中的BSD协议。如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。BSD 开源协议鼓励代码共享，但需要尊重代码作者的著作权。BSD 开源协议允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布、销售，是对商业集成很友好的协议。因此，很多公司在选用开源产品的时候都首选BSD协议。
须知：
BSD 对商业比较友好，很多公司在选用开源产品的时候都首选 BSD 协议，因为可以完全控制这些第三方的代码，甚至在必要的时候可以修改或者二次开发。
d2)MIT（Massachusetts Institute of Technology）
来源于大学，MIT 开源协议是史上最为简洁、慷慨的开源协议之一。作者只想保留版权，而无任何其他了限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。
特点：
用户可以拿你的代码做任何想做的事情。用户在项目副本中要包含版权声明和许可声明。你无需承担任何责任。代表作品:
jQuery,Rails ,PuTTY、X Window System、Ruby on Rails、Lua 5.0 onwards、Mono等。须知：
目前限制最少的开源许可协议之一（比 BSD 和 Apache 的限制都少），只要程序的开发者在修改后的源代码中保留原作者的许可信息即可，因此普遍被商业软件所使用。
d3)Apache Licence 2.0
Apache License, Version 2.0Apache License, Version 1.1Apache License, Version 1.0来自 Apache，类似 MIT 开源协议，但它重视专利权。
Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许修改代码、再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：
需要为使用代码的用户提供一份 Apache Licence 。如果你修改了代码，需要在被修改的文件中说明。在延伸的代码中（修改和由源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原作者规定需要包含的说明。如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence 。你可以在 Notice 中增加自己的许可，但不可对 Apache Licence 构成更改。Apache Licence 也是对商业应用友好的许可，使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
代表作品：
echartssupersetdubbospark须知：
Apache 协议还有以下需要说明的地方: 永久权利: 一旦被授权，永久拥有。
全球范围的权利: 在一个国家获得授权，适用于所有国家。
授权免费，且无版税: 前期，后期均无任何费用。
授权无排他性: 任何人都可以获得授权
授权不可撤消: 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码
d4)GPL（General Public License）
GPL（GNU GENERAL PUBLIC LICENSE）来源于自由软件联盟GNU，GPL/LGPL侧重于代码及衍生代码的开源与免费使用。
GPL协议的主要内容是只要在一个软件中使用（”使用”指类库引用，修改后的代码或者衍生代码）GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。 这就是所谓的”传染性” 。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是 代码的开源/免费使用/引用/修改 和 衍生代码的开源/免费使用 ，但 不允许 修改后和衍生的代码做为 闭源 的商业软件发布和销售。
其它细节和BSD/Apache等协议类似。
代表作品：
Linux须知：
只要软件中包含了遵循 GPL 协议的产品或代码，该软件就必须也遵循 GPL 许可协议，也就是必须开源免费，不能闭源收费，因此这个协议并不适合商用软件
d5)LGPL（Lesser General Public License）
LGPL（GNU LESSER GENERAL PUBLIC LICENSE）来自于自由软件联盟GNU，可以翻译为更宽松的GPL协议，也属于传染性开源协议。
LGPL是GPL的一个主要为类库使用设计的开源协议。和 GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议 不同，LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议，因此，LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
须知：
LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用
d6)Eclipse Public License（EPL）
由于版权约束比LGPL弱，因此EPL许可证更加商业友好，因为它允许转授使用许可和构建由EPL和非EPL（甚至专有）许可代码组成的软件，前提是非EPL代码是“软件的单独模块”。
此外，在包括项目工作在内的商业产品引起的诉讼/损害的情况下，EPL为EPL代码贡献者提供了额外保护。它主要具有以下特点：
较弱的版权约束（受限于软件“模块”）项目作品适合商业用途。被许可方可以修改项目。如果你修改了作品，则必须以相同的条款发布修改后的作品。如果你使用了作品，无需以相同的条款发布衍生作品。软件的商业分销商必须在因商业用途导致的诉讼/损害中保护或赔偿原始EPL贡献者。使用EPL协议的常见项目
编程语言Clojure：
https://clojure.org/community/license
应用服务器Jetty（EPL v1.0）：
https://www.eclipse.org/jetty/licenses.html
Java测试框架（EPL v1.0）：
https://junit.org/junit4/licens
d7)Mozilla（Mozilla Public License）
Mozilla开源协议由Mozilla基金会开发并维护。该协议融合了BSD许可与GNU通用公共许可协议的特性，追求平衡专有软件和开源软件开发者之间的顾虑（平衡开发者对源代码的需求和他们利用源代码获得的利益）。Mozilla允许使用者在自己已有的源代码库上加一个接口，除了对接Mozilla Public License开源库的接口程序源代码以MPL许可的形式对外许可外，源代码中的其他源码可以不用MPL许可证的方式强制对外许可。使用BSD前提条件：经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来；如果修改了代码，需要有一个专门文件描述对源代码程序的修改时间和修改方式；
最喜欢的是GPL，非商业用途随便玩