当前位置:首页->开发环境配置->代码管理

从零开始搞清楚各种开源协议及相互之间的差异

-- 从零开始搞清楚各种开源协议--持续更新,建议收藏
【官网】：无

应用场景

 在知识产权方面的法律日益完善，开源技术蓬勃发展的当下，懂得各种开源协议的区别，能够让我们在做技术决策时少踩一些坑，避免后期突然被起诉侵权，或者涉及知识产权类的民事纠纷等.

基础资源

 
无

使用须知

作为程序员，我们开发过程中难免会用到其他人的成果，开源协议规定了你在使用开源软件时的权利和责任，也就是规定了你可以做什么，不可以做什么。开源协议虽然不一定具备法律效力，但是当涉及软件版权纠纷时，开源协议也是非常重要的证据之一。现在市面上的开源协议至少有上百种，经过开源促进会（Open Source Initiative）认可的开源协议也多达 70 多种

配置步骤

无

常见问题

快速入门

A)开源协议常识.

a1)License是什么?


LICENCE 是软件的授权许可，详细声明了获得代码后拥有的权利，哪些行为是允许的，哪些行为是禁止的。软件的版权许可证可有很多方式，本文仅讨论开源软件协议 Open Source License。

一般我们不需自己写许可协议，更靠谱的是选择一种比较流行的开源协议，省时省力，更便于自己作品的传播，于人于己都有利。

除了直接使用开源代码，即便是仅仅受一个项目的启发（未引用一行代码），国外一些项目作者依然会声明受某某项目启发： Inspired by XXX link: https://www.xxxx.com 。

a2)开源协议中涉及的术语.

  • 协议和版权信息 (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），即要求软件的分发者必须向用户披露，软件里面有开源代码。
    一般来说，你只要在软件里面提供完整的原始许可证文本，并且披露原始作者，就满足了”披露要求”.

a3)开源许可的类型.


根据使用条件的不同，开源许可证分成两大类。

  • 宽松式许可证
  • Copyleft 许可证

宽松式许可证

特点

宽松式许可证（permissive license）是最基本的类型，对用户几乎没有限制。用户可以修改代码后闭源。

它有三个基本特点。

  1. 没有使用限制：用户可以使用代码，做任何想做的事情。
  2. 没有担保：不保证代码质量，用户自担风险。
  3. 披露要求（notice requirement）：用户必须披露原始作者。

常见许可证

常见的宽松式许可证有四种。它们都允许用户任意使用代码，区别在于要求用户遵守的条件不同。

  1. BSD（二条款版）：分发软件时，必须保留原始的许可证声明。
  2. BSD（三条款版）：分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。
  3. MIT：分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。
  4. Apache 2：分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。

Copyleft 许可证

Copyleft 的含义

Copyleft 是理查德·斯托曼发明的一个词，作为 Copyright （版权）的反义词。

Copyright 直译是”复制权”，这是版权制度的核心，意为不经许可，用户无权复制。作为反义词，Copyleft 的含义是不经许可，用户可以随意复制。

但是，它带有前提条件，比宽松式许可证的限制要多。

  • 如果分发二进制格式，必须提供源码
  • 修改后的源码，必须与修改前保持许可证一致
  • 不得在原始许可证以外，附加其他限制

上面三个条件的核心就是：修改后的 Copyleft 代码不得闭源。

常见许可证

常见的 Copyleft 许可证也有四种（对用户的限制从最强到最弱排序）。

  1. Affero GPL (AGPL)：如果云服务（即 SAAS）用到的代码是该许可证，那么云服务的代码也必须开源。
  2. GPL：如果项目包含了 GPL 许可证的代码，那么整个项目都必须使用 GPL 许可证。
  3. LGPL：如果项目采用动态链接调用该许可证的库，项目可以不用开源。
  4. Mozilla（MPL）：只要该许可证的代码在单独的文件中，新增的其他文件可以不用开源


a4)为什么要使用开源协议?


 1)对作者的保护，防止知识成果被恶意利用。

  • 开源协议中一般都包含免责声明(禁止代码的作者承担代码使用后的风险及产生的后果)，比如你开源了一个破解智能锁的代码，如果有人利用这个去盗窃导致他人损失，你是无需承担责任的。
2)对使用者（引用开源代码或组件的人）的保护，方便使用者。
  • 使用者一看就知道自己被许可允许进行哪些行为（拷贝，分发，修改，发布，声明，售卖等），不允许进行哪些行为。
  • 未添加协议的代码默认是作者保留所有权利的(对此不同国家的法律可能稍微存在区别)，这就像一颗定时炸弹，如果你在项目中使用了这一份没有协议的代码，原作者只要能证明你未经许可使用了他的代码，是能够起诉你的。


B)常见开源协议.

  • BSD（Berkeley Software Distribution license）

  • BSD-2-Clause

  • BSD-3-Clause

BSD可证也来源于大学，与MIT差不多，也非常简单、慷慨。

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

  1. 如果再发布的产品中包含源代码，则在源代码中必须带有原代码中的BSD协议。

  2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。

  3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD 开源协议鼓励代码共享，但需要尊重代码作者的著作权。BSD 开源协议允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布、销售，是对商业集成很友好的协议。因此，很多公司在选用开源产品的时候都首选BSD协议。

须知：

BSD 对商业比较友好，很多公司在选用开源产品的时候都首选 BSD 协议，因为可以完全控制这些第三方的代码，甚至在必要的时候可以修改或者二次开发。


  • MIT（Massachusetts Institute of Technology）


来源于大学，MIT 开源协议是史上最为简洁、慷慨的开源协议之一。作者只想保留版权，而无任何其他了限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。

     特点：

  • 用户可以拿你的代码做任何想做的事情。

  • 用户在项目副本中要包含版权声明和许可声明。

  • 你无需承担任何责任。

     代表作品:

  • jQuery,Rails ,PuTTY、X Window System、Ruby on Rails、Lua 5.0 onwards、Mono等。

须知：

目前限制最少的开源许可协议之一（比 BSD 和 Apache 的限制都少），只要程序的开发者在修改后的源代码中保留原作者的许可信息即可，因此普遍被商业软件所使用。

  • Apache Licence 2.0

  • Apache License, Version 2.0

  • Apache License, Version 1.1

  • Apache License, Version 1.0

来自 Apache，类似 MIT 开源协议，但它重视专利权。

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

  1. 需要为使用代码的用户提供一份 Apache Licence 。

  2. 如果你修改了代码，需要在被修改的文件中说明。

  3. 在延伸的代码中（修改和由源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原作者规定需要包含的说明。

  4. 如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence 。你可以在 Notice 中增加自己的许可，但不可对 Apache Licence 构成更改。

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

代表作品：

  • echarts

  • superset

  • dubbo

  • spark

须知：


Apache 协议还有以下需要说明的地方: 永久权利: 一旦被授权，永久拥有。

全球范围的权利: 在一个国家获得授权，适用于所有国家。

授权免费，且无版税: 前期，后期均无任何费用。

授权无排他性: 任何人都可以获得授权

授权不可撤消: 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码



  • 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 许可协议，也就是必须开源免费，不能闭源收费，因此这个协议并不适合商用软件


  • 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 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用



  • Eclipse Public License（EPL）

由于版权约束比LGPL弱，因此EPL许可证更加商业友好，因为它允许转授使用许可和构建由EPL和非EPL（甚至专有）许可代码组成的软件，前提是非EPL代码是“软件的单独模块”。


此外，在包括项目工作在内的商业产品引起的诉讼/损害的情况下，EPL为EPL代码贡献者提供了额外保护。它主要具有以下特点：


  • 较弱的版权约束（受限于软件“模块”）
  • 项目作品适合商业用途。
  • 被许可方可以修改项目。
  • 如果你修改了作品，则必须以相同的条款发布修改后的作品。
  • 如果你使用了作品，无需以相同的条款发布衍生作品。
  • 软件的商业分销商必须在因商业用途导致的诉讼/损害中保护或赔偿原始EPL贡献者。


使用EPL协议的常见项目


编程语言Clojure：

clojure.org/community/l


应用服务器Jetty（EPL v1.0）：

eclipse.org/jetty/licen


Java测试框架（EPL v1.0）：

junit.org/junit4/licens


  • Mozilla（Mozilla Public License）

Mozilla开源协议由Mozilla基金会开发并维护。
该协议融合了BSD许可与GNU通用公共许可协议的特性，追求平衡专有软件和开源软件开发者之间的顾虑（平衡开发者对源代码的需求和他们利用源代码获得的利益）。
Mozilla允许使用者在自己已有的源代码库上加一个接口，除了对接Mozilla Public License开源库的接口程序源代码以MPL许可的形式对外许可外，源代码中的其他源码可以不用MPL许可证的方式强制对外许可。
使用BSD前提条件：
经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来；
如果修改了代码，需要有一个专门文件描述对源代码程序的修改时间和修改方式；





C)常见开源协议的区别.

c1)引用者视角-协议差异.

  注;下图由乌克兰程序员PaulBagwell原创


 注;下图由阮一峰翻译


各许可对应的声明：


附1：常用开源协议的宽松程度：

MIT>BSD>Apache>LGPL>MPL>GPL>AGPL.


附2：一个来源于专业的开源许可风险识别平台WhiteSource上的分析报告(绿色代表风险低，红色代表风险高):


c2)开源作者视角-协议差异.


参考资料
关于作者
桃花岛主 lv-3
十年磨一剑
获得点赞 2,570
文章被阅读 76,700