引言
写这篇博客的契机是我厂刚好开了一次这样的培训，听了以后觉得很有收获。碰巧自己最近也在写开源项目，因此觉得还是有必要写一下。
有小伙伴提到，这种问题，去网上找那个指导你如何选择 LICENSE 的图就好了。那个图能指导你选择正确的许可协议，但是并不会增进你对各个协议的了解。
本文里会通过几个例子让读者更能了解这些协议。
软件的分类
我们先来看看软件一共分为几种：
| 软件分类 | 版权保护 | 开放源码 | 再分发 | 修改 |
|---|---|---|---|---|
| 商业软件 | √ | 不一定 | × | × |
| 开源软件 | √ | √ | √ | √ |
| 共有软件 | × | 不一定 | √ | √ |
| 微软的共享源码软件 | √ | 部分提供 | 部分提供 | 部分提供 |
这里特别提一下公有软件，指的是著作人去世后一段时间之后，例如 50 年后，这个软件就变成了共有软件，谁都可以用，谁都可以拿去卖，但是署名不能改。
微软共享代码软件指的是，向部分用户提供了源代码，也允许部分用户进行再分发等。
开源软件
开源软件又称自由软件，提倡的是：
FREE TO RUN
FREE TO STUDY
FREE TO REDISTRIBUTE
FREE TO IMPROVE
既然把源代码共享了，如何保护自己的权利呢？可以通过著作权法和商标法。
著作权
著作权法主要要求：
复制、分发、修改时，附上版权说明。
修改时，对修改部分进行明示。
需要明确的是，软件的思想、功能是受专利保护，而不受著作权法保护。
商标权
是否允许使用者使用你的商标。Linux、Apple、IBM等就是商标。
许可协议
许可协议是很常见的权益声明。许可协议数量多达 82 种，主要分为三类：
GPL: Copyleft 原则。给你足够的自由去修改，去再分发。类似的协议：AGPL、LGPL。对商业软件来说，这是一项非常危险的许可，下文详细会讲 GPL 协议相关的内容。
BSDL: 绝对的自由，允许授权者修改、再分发、甚至闭源。类似的协议：Apache、MIT。
MPL: 集开源之力为我所用。类似的协议: Apple、Sun、Nokia、IBM。
许可协议的兼容性
一个软件中可能会集成多个开源项目。如果这几个的开源项目的许可有所冲突，或跟软件主体的许可有所冲突，表明这些项目许可不兼容，是不能在一起用的。
GPL、Apache不能集成在一起，更不能以Apache发布。
几个例子
下面的例子都是关于上文提到的一类非常危险的协议：GPL 协议的。
GPL 类许可协议是对商业最危险的许可协议。它规定你可以私自修改，使用，但是不能发布。例如 MySQL，拿过来改，只能自己用，没有问题。但绝对不能闭源发布。如果你发布了，GPL 要求你要向用户提供源码，并且一定要使用 GPL 授权。
什么意思呢？如果一个库是 GPL 发布的，则任何使用这个库的程序，必须使用 GPL 授权，必须要向用户开放源代码。这是一种非常有传染性的许可协议。
下面就来看几个例子：
例0：Linux 和 Android
先来提一下这两个个例。Linux 是 GPL 协议开源的，这意味着用户可以修改，可以再分发，但必须要开源。
问题来了，许多 Linux 的驱动程序，他们使用了 Linux 系统的库，按照 GPL 许可协议，他们必须开源。但他们为什么可以闭源发布呢？
原因在于，Linux 本人在他的许可协议加上了一句话：凡是以调用内核形式访问代码的，不受 GPL 限制。
那么又说到安卓，安卓为了规避 GPL 许可的风险，做了非常大的努力：
| 组分 | 许可 |
|---|---|
| Linux kernel | GPL-2.0 |
| Library | MIT BSD |
| Runtime | Apache |
| Framework | Apache |
上文提到了 Linux 使用的许可的特殊性，使安卓能把 GPL 协议限制在 kernel 层。上层全部采用了非 GPL 类许可，使厂商、用户可以闭源发布产品。只要这中间混进去了一个 GPL 库，那么这层以后的所有层，全部必须开源。包括大家开发的安卓App，也必须开源，这肯定是无法接受的。
通过 Linux 和 Android 的例子，大家一定对 GPL 的传染性有一定的概念。
例1：思科
思科开发自己的路由器时，对嵌入式 Linux 本身做了裁剪，最后安装在路由器里面发布了。
而 Linux 特殊的 GPL 许可只允许调用系统内核的情况下不受 GPL 限制，但修改源码是不行的。有一个理想主义组织，叫FSF，发现了这个情况后起诉了思科。
最终判决结果是，思科开源了代码，最终演变成了著名的openwrt。
例2：Hancom office
Hancom office 是一家韩国公司开发的一套 office 软件。这个软件集成了一套开源 PDF 解释器，Ghostscript。
这个 Ghostscript 呢，拥有两种协议。一种是免费协议，是 GPL。意味着你可以免费用他的库，但是许可协议是 GPL 协议，你发布的话也必须要开放你的源代码。另一种是商业许可协议，需要花钱购买，买了以后，你就可以闭源发布你的产品了。但该公司没有购买商业许可，用了免费的 GPL 许可，但是他闭源发布了他的产品。
所以最后的结果，你懂的。
上面是两个是比较常规的例子，下面来点刺激的。
例3：GPL和逆向
A 公司购买了 V 公司软件，进行反编译用来增加自己功能。V 公司发现后，起诉 A 公司的这种行为侵犯他们著作权。
但事情发生了转折，A 公司反过来起诉 V 公司，他们在逆向时候发现 V 公司使用了一个用 GPL 许可协议的开源库，但 V 公司没有开放产品的源代码。
判决结果，A 公司修改 V 公司软件是合法的。
风险规避
说了这么多，我们在做开源时如何才能规避风险呢？可以从以下几点考虑：
策略上。你为什么要开源，是为了让人随便用，到处都运行着你的代码，觉得很有成就感，还是为了其他目的。
权衡利弊，选择许可。
避免陷阱，对以下情况做限制：1、再分发要求。2、担保条款，免责条款。3、代码传染性。
定位什么人会用我的代码。
版权贡献者协议(CLA)。
最后，如果你需要更改你的开源项目的许可协议，你需要征得所有项目贡献者的同意。但如果在贡献项目以前，他们签署过版权贡献者许可协议（CLA），那么就意味着授权了版权给你，你可以不经过他们同意就修改许可协议。
结语
以上内容是依靠当场做的笔记写的，也有可能有错误，有疏漏，欢迎大家提出。
最后是一点个人建议，对于完成度比较高的工具类开源项目，GPL + 付费商业许可是比较好的选择。
作者：Enum
链接：http://www.jianshu.com/p/8a89c21c2093
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
