摘要：license，中文译为“许可证”。在开源世界里，license是具有法律效力的，通过选择相应的license，版权拥有者可以声称自己相应的权利，包括其他人使用、修改、引用、共享等一系列涉及版权的操作。

01 开源license，是啥?

场景：壮壮是一个程序员，他最近开发了一个小功能，并且将代码放到了github上。过了一段时间，壮壮发现，好多人引用他的代码，但没有声称他的著作权，壮壮觉得很气愤，且不理解：为什么大家这么不尊重我的劳动成果呢?所以他就问他的好朋友小源同学，小源同学了解情况后，告诉他：是因为你没有采用符合你需求的license啊!

license，中文译为“许可证”。在开源世界里，license是具有法律效力的，通过选择相应的license，版权拥有者可以声称自己相应的权利，包括其他人使用、修改、引用、共享等一系列涉及版权的操作。

实际上，目前国际上公认的开源许可证有80余种，如果对开源了解不多的人，确实会觉得仅许可证一项就很复杂，但在实际使用许可证时，我们可以将使用场景归纳一下，并且将一些常用的许可证种类列举并解释，就极大的方便开发者选用合适的许可证了。下面一道就梳理一下那些常用的许可证~

02 开源license，咋用?

故事：Stallman是自由软件之父，他在上世纪八十年代开发GNU系统时，创造了Copyleft一词，用以区分商业公司copyright。实际上，在上世纪七、八十年代，就已经有相当一部分开源许可证被发布出来，供开源软件选择使用。

如上图所示：Copyright是目前商业公司采用的版权保护办法，旨在杜绝用户之间通过复制、分发等形式，共享产品，造成商业利益的损失;

Public domain则属于另一极端，即在未声明任何license的情况下，著作者与著作物不存在任何关联。

我们所讲的开源license，则集中在Copyleft和Permissive两类情况中，具化来讲，可以理解为：

Copyleft：衍生代码必须开源，且采用相同的开源license;

Permissive：衍生代码不必开源，可采用不同的开源license;

所以，作为代码的生产者，无论是个人抑或是公司，可以确立自身在面对开源时的原则，进而能够确定自身所选定的license类型。

03 开源license，有哪些?

如前文所述，国际公认的开源license，有多达80余种，理解起来殊无必要。只要掌握常用的几类，在需要的时候，采用相应的license，即可解决许可证相关问题。

至于更多的时间精力，不如留给继续coding或者撩妹~

1GPL

全称为General Public License，是Stallman老爷子在鼓捣GNU时所采用的开源协议。GPL最特殊的一点在于：只要一个软件使用了GPL协议的产品，则该软件也必须采用GPL协议，即衍生或修改后的代码，不可用于闭源的商业软件销售和发布。

这种特性，使得GPL具有病毒的特性——传染性。但GPL的传染是为了所有相关代码能够开放，使更多人受益。

2BSD

全称为Berkeley Software Distribution，是一个较为宽松的开源协议，唯一关注的是保护代码作者的著作权要受到尊重，这给予使用者很大的自由度。在满足二次发布时需要声明原来代码的BSD协议及不将原作者/产品用作市场推广时，，使用者可以自由的使用、修改源码，甚至在源码基础上二次开发后进行商用发布和销售。

3MIT

全称为Massachusetts Institution of Technology，又名“X条款”，MIT与BSD较为类似，差异较小。仅提供版权保护和声明，即在二次开发后的发行版中，需要包含原许可证声明。

4MPL

全称为Mozilla Public License，是网景公司的Mozilla小组于1998年设计的软件许可证。该许可证介于GPL和BSD之间，是为了更好的平衡“开发者对源码的需求和他们利用源代码获得的收益”。比如MPL协议下，可以通过折中办法，隐藏具有商业诉求的源代码，为商用场景提供了许可。MPL协议规定较为详细，感兴趣的读者可以自行搜索该协议，作进一步的研究。

5Apache License 2.0

没错，该许可协议就是来自于大名鼎鼎的Apache Software Foundation，总体来说，该许可协议与BSD/MIT协议类似，属于比较宽松、商业友好的开源协议。只需要使用者在使用了该协议下的源代码后， 再发布后，依然带有对源代码的协议、商标、及其他作者规定的说明，即可。

6LGPL

全称为Lesser General Public License，亦称GPL V2，虽然它与GPL同出一处，但他具有不同性：LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。但如果是修改LGPL的代码或者衍生的代码，则所有修改或衍生的代码，均需要遵循LGPL协议。

04 开源license，用哪个?

开源license，并没有严格地讲孰优孰劣，只有在根据实际的使用场景，才能明确开源license的最佳选择。

“道理我都懂，可还是过不好这一生”，那么不妨，我们从两个小故事中窥探开源license的真假浮沉吧~~

故事一

2016年5月，Facebook开源了自身的前端软件React，引来业界震动。

7月，Facebook在React开源许可协议中的附加专利条款开始引发争议。

11月，Facebook官方澄清附加专利条款，但并未获得认同，业界仍然忧心忡忡。

2017年7月，Apache基金会禁止使用遵循BSD+附加专利条款的jar包。

同时，中国互联网的一批企业开始意识到问题严重性，并且积极抵制该协议，并且寻求新的前端技术以替代React。

10月，Facebook迫于压力，宣布将react及其他一系列采用BSD+专利许可协议的软件改用MIT许可协议。

点评：BSD+专利许可协议的精髓是“如果你觉得Facebook侵犯了你的知识产权，你不能起诉Facebook;如果Facebook起诉你，那么你不能反诉，否则你就立即停止使用React”。

瞧瞧!小扎很精明嘛!

可惜!群众也不傻呀!

故事二

2009年，甲骨文宣布收购SUN公司。本来是一件正常的商业行为，但却有一个人坚决反对，他就是Michael Widenius——MySQL的创始人。可他为什么反对呢?

因为MySQL是SUN公司所有，一旦被收购，就将属于Oracle公司。而众所周知，Oracle和MySQL那可是死敌啊!MySQL的未来境遇，可想而知。于是Michael Widenius甚至发起了万人签名，提交请愿书，要求欧盟委员会否决这项交易。

当然，历史的进程已经表明：SUN还是被Oracle收购了;MySQL并没有因此而死掉;这又是为什么呢?

因为MySQL采用的是GPL协议，按照该协议：任何源码的衍生产品，如果对外发布，都必须采用相同的许可协议。即我们前边提到的“传染性”。也就是说，在MySQL已经被广泛采用的情况下，使用的GPL协议，反而成为了他最好的保护伞，因为即使Oracle公司废弃MySQL，其他企业或个人依然可以发布MySQL的最新版本和特性;从另外一个角度讲，Oracle公司舍不得MySQL的规模和技术，如果在此基础上进行修改，则二次发布的产品因为GPL协议的传染性，也不得不采用该协议，依然使得MySQL或者重生。

但如果MySQL一开始使用的是MIT/BSD等协议，那么Oracle很容易将MySQL并入自己的商业产品中，并且通过一系列新的特性和功能，使得开源版本被边缘化。

回过头看，开源协议之威力，竟至于斯!

05 写在最后：简单粗暴的选择你的开源协议

乌克兰程序员Paul Bagwell画了一张分析图，介绍了最为流行的几种开源license的实际使用情况。国内技术牛人汉化过来，贴在此处，供大家参考。