从GitHub上看开源许可证多舛的命运

要是没有一个适当的开源许可，那么那样的开源就不能称之为开源。除非你已经明确地告诉别人他们可以修改和重用你的工作，因为你只给别人看了你的代码，还没有把它共享出去。

在 GitHub 上，我们都是开源的忠实粉丝，所以我们需要更好的去更好地了解我们的用户是如何根据查看公共的、non-forked 存储库方面的许可证来选择适合他们的开源代码许可证的，所以，做这个调查的目的就是希望鼓励更多的用户与他人分享他们的工作。

如果你经常关注这个注册存储库图表的话，你就会发现注册存储库的比例正在下降，徘徊在 GitHub 20% 的历史记录上（加上已 forked 的大约是 30%）。2013 年中期的注册数量飙升代表我们第一次在 GitHub 上简化开源许可证的选择流程获得了一定程度的成功。更大程度上鼓励用户选用合适的开源许可证来开放他们的项目。

实际上，开源许可证的使用情况并不像我们想象的那么乐观，一起来看看 choosealicense.com 网站之前做的调查：比较一下相对流行的开源许可的利用现状。下面根据项目许可证在 GitHub.com 上的比例可以看到他们的受欢迎程度：

1.  MIT                     44.69%  
2.  Other                  15.68%  
3.  GPLv2                12.96%  
4.  Apache               11.19%  
5.  GPLv3                 8.88%  
6.  BSD 3-clause      4.53%  
7.  Unlicense            1.87%  
8.  BSD 2-clause      1.70%  
9.  LGPLv3               1.30%  
10.  AGPLv3               1.05% 

不出所料，MIT、Apache 和 GPL 是明显的领跑者，其中就有 15% 的注册项目选择了标准的或者是不标准的开源许可证，而这些许可证根本不在 choosealicense.com 的名单上。

最后，我们应该来研究一下许可证使用情况发生改变的原因。这三个极具特色的许可证（MIT、Apache、GPL）在 2013 年中期开始不断上扬，其增长的数量是过去六年的总和。开发人员使用 GitHub 是因为他们想与世界分享他们的代码。数据表明，当我们觉得某一工具使用起来较之前容易得多的时候，那就说明百分之百是开发者做了改进。更多的时候当面对选 择时，他们还是会选择开源许可证的，而且非常自由地执行着。

---

说到开源协议，很多人是不怎么清楚，如今的开源协议达到 60 多种，其中主流的包括以下这些。

1. BSD

BSD 开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了 BSD 协议的代码，或则以 BSD 协议代码为基础做二次开发自己的产品时，需要满足三个条件：

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

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

2. Apache License, Version 2.0

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

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

Apache Licence 也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。Apache 旗下的软件包括 Apache Web 服务器、Hadoop、Open Office 等软件都是采用的 Apache License。

3. GNU General Public License (GPL)

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

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

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

其它细节如再发布的时候需要伴随 GPL 协议等和 BSD/Apache 等类似。这也是小米涉嫌违反的一项开源协议。GPL 是最严格和最彻底的开源协议。使用该协议最重要的代表就是 Linux 操作系统了，当然也包括一众跑在 Linux 上的软件，像著名的图像处理软件 GIMP 等也采用了 GPL 协议。

4. GNU Library or “Lesser” General Public License (LGPL)

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

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

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

LGPL 出现是因为 GPL 实在太严格了，有点类似开源的原教旨主义，这也导致该协议对商业用户并不友好。而没有商业化的软件其发展前景也大多不好，所以 LGPL 就应运而生。

5. Mozilla Public License

MPL 是 The Mozilla Public License 的简写，是 1998 年初 Netscape 的 Mozilla 小组为其开源软件项目设计的软件许可证。MPL 许可证出现的最重要原因就是，Netscape 公司认为 GPL 许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的 GPL 许可证和 BSD 许可证相比，MPL 在许多权利与义务的约定方面与它们相同（因为都是符合 OSIA 认定的开源软件许可证）。但是，相比而言 MPL 还有以下几个显著的不同之处：

MPL 虽然要求对于经 MPL 许可证发布的源代码的修改也要以 MPL 许可证的方式再许可出来，以保证其他人可以在 MPL 的条款下共享源代码。但是，在 MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着 MPL 允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以 MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用 MPL 许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。

MPL 许可证第三条第 7 款中允许被许可人将经过 MPL 许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。

对软件专利的态度，MPL 许可证不像 GPL 许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代 码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

使用 MPL 协议的软件主要包括 Mozilla 基金会下面的l浏览器 Firefox、FTP 工具 Firezilla、邮件处理软件 Thunderbird、大名鼎鼎的 BUG 管理系统 Buglzilla 等。

6. MIT license (MIT)

MIT 是和 BSD 一样宽范的许可协议，作者只想保留版权，而无任何其他了限制。也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。

7. EPL (Eclipse Public License 1.0)

使用 EPL 协议，需要遵守以下规则：

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

EPL 允许 Recipients 任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。商业软件可以使用，也可以修改 EPL 协议的代码，但要承担代码产生的侵权责任。

开源软件现在已经成为整个互联网的基础。包括 Linux 操作系统、主流 Web 服务器、常用的浏览器引擎、网络传输加密、大数据挖掘等都离不开开源。而开源运动可以持续下去的保证就是这些开源协议。虽然这些协议看上去只是一纸文书， 并没有太多强制力。但正是这些看上去很奇怪的协议促进了整个软件行业的发展，使得很多开源软件成为最重的软件，而开源也成为最重要的一种开发方式。