GPL,MIT,Apache-2.0各大开源协议你懂多少?

前言:

刚刚在刷贴吧时看到了CSDN发布的一篇文章(十年无果,Linux 开发者放弃 VMware 诉讼):

多年前那场 VMware 源码侵权案,在诉讼请求被法院一次次驳回后,最近原告著名 Linux 开发者 Christopher Helwig 已经决定不再上诉,因为他认为这已经没有意义了。

其中提及到Hypervisor vSphere VMware ESXi 5.5.0 违反了 Linux 使用的开源许可协议 GPL,然后我在想,Open Source Initiative 批准的那么多开源协议,都有什么区别呢?那么我们就一起来看看吧。

现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开源协议目前有58种(http://www.opensource.org/licenses /alphabetical)。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码,最好也是选择这些被批准的开源协议。

常见的协议介绍

BSD协议(original BSD license、FreeBSD license、Original BSD license)

BSD开源协议是一个给予使用者很大自由的协议。开发者可以自由使用和修改源代码,也可以讲修改后的源代码作为开源或者专有软件再发布。但是有一下几个要求:

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

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

Apache Licence 2.0(Apache-2.0)

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和最终原作者的著作权,同样允许源代码修改和再发布。但是也需要遵循以下条件:

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

使用这个协议的好处是:

  • 永久权利 一旦被授权,永久拥有。
  • 全球范围的权利 在一个国家获得授权,适用于所有国家。假如你在美国,许可是从印度授权的,也没有问题。
  • 授权免费 无版税, 前期、后期均无任何费用。
  • 授权无排他性 任何人都可以获得授权
  • 授权不可撤消 一旦获得授权,没有任何人可以取消。比如,你基于该产品代码开发了衍生产品,你不用担心会在某一天被禁止使用该代码

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

GPL

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

LGPL

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品

MIT

MIT是和BSD一样宽范的许可协议,源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称X11协议。作者只想保留版权,而无任何其他了限制。MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。
MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。

MPL (Mozilla Public License 1.1)

MPL协议允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益,它要求基于这种软件的修改无偿贡献版权给该软件。这样,围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改,无偿使用得。MPL软件对链接没有要求。

EPL (Eclipse Public License 1.0)

EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
使用EPL协议,需要遵守以下规则:

  1. 当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权;
  2. EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法;
  3. 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL;
    4.独立的模块(Separate Module),不需要开源。

小结

如果看完还是一头雾水的话,乌克兰程序员Paul Bagwell,画了一张分析图,说明应该怎么选择,下图为国内大牛阮一峰汉化了版本。

参考资料:

segmentfault:“几种常见的开源协议介绍

深度开源:

各种开源协议介绍 BSD、Apache Licence、GPL V2 、GPL V3 、LGPL、MIT

开源中国: “如何为你的开源项目选择一个合适的开源协议?

评论

  1. 苏醒
    iPhone AppleWebKit
    2年前
    2019-4-06 23:24:27

    天秀!流弊!

  2. 萌Q
    Android Chrome
    2年前
    2019-4-07 9:14:03

    表示完全看不懂……Austen真是巨佬

  3. 马云
    Windows Chrome
    2年前
    2019-4-07 11:59:56

    非常棒,年轻人我看好你

  4. 麻辣
    Windows Firefox
    2年前
    2019-4-13 23:08:12

    如此好文章一定要留下名啊

  5. 猫鼬博客
    Windows Chrome
    2年前
    2019-4-13 23:33:05

    巧了,我愣是一个没看懂。

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇