引言

2018 年，因为使用他人「免费」提供的源代码，国内一家软件公司被告上了法庭。

在数字天堂（北京）网络技术有限公司（「数字天堂公司」）诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司（「柚子公司」）侵犯计算机软件著作权纠纷一案中，原告数字天堂公司主张：被告柚子公司的 APICloud 软件抄袭了其按照 GPL 许可证分发的 HBuilder 开发工具软件源代码，侵犯了其著作权，要求赔礼道歉、消除影响并赔偿损失。

经北京知识产权法院初审、北京高级人民法院二审，柚子公司最终被判停止侵权并赔偿 71 万元。

如果缺少背景知识，这个被称为「中国 GPL 诉讼第一案」的重要案件可能有些不好理解。根据法院的认定，「原告的 HBuilder 软件是 GPL 协议下的开源软件分支。根据 GPL 协议的规定，任何第三方有权在 GPL 协议授权下使用其代码并构建衍生软件产品 […] 原被告双方的涉案软件均为免费软件 [对应英文术语为 free software，通译为「自由软件」，但原文如此]。」

既然是「任何第三方有权使用」的「免费」软件，为什么会侵权又要赔偿呢？

弄清楚这个问题不仅仅具有法律上、学术上的意义。俗话说「不要重复造轮子」，对于很多软件开发项目而言，开源软件正是那些起着地基作用的「轮子」。因此，如何合规利用开源软件，了解开源许可证的内容已成为各大互联网公司的重要课题。

过去，对开源软件合规问题的讨论在美国相对较多，各类判例也相对丰富；「中国 GPL 诉讼第一案」则让国内公司也意识到了开源问题的重要性。实际上，中国互联网企业的崛起有赖于开源；GitHub 预测到 2030 年中国开发者将成为全球最大的开源群体。新一代的操作系统、分布式数据库、人工智能框架都通过开源项目快速进步。如 360 的董事长周鸿祎所言，如果没有开源软件，就没有中国互联网的飞速发展。

因此，无论你是准备在开发项目中使用开源代码，还是计划将自己的软件以开源方式，抑或只是下载使用开源软件的普通用户，都值得花些时间认真了解开源软件及其许可证。

开源软件与开源许可证

开源软件

顾名思义，从最简单的意义上说，「开源软件」就是开放源代码的软件；换言之，是人们能够免费且不受限制地使用、再开发、再发布的软件。

但从狭义上说，只有符合开放源代码促进会（Open Source Initiative）定义的软件才是开源软件。该定义提出了十个特征，必须全部符合才能认定为开源软件；除了包括可自由再分发、提供源代码、允许衍生作品这些应有之义，还要求不得过度限制原始代码的修改，不得歧视特定人、群体或用途，必须「技术中立」等。

在这样的标准下，一些看似自由使用的软件就「不够格」称为开源软件了。例如，知名的全文搜索引擎 Elasticsearch 原来使用 Apache 2.0 授权，是货真价实的开源软件。但面对 AWS 等云服务厂商使用 Elasticsearch 作营利用途、却又不反向回馈其所做改进的现状，Elasticsearch 在 2021 年 1 月选择改用SSPL（Server Side Public License、服务器端公共许可证）和 Elastic License 两种许可证并行。

其中，SSPL 的条款基本与常见开源许可证 GPLv3 一致，但要求「如果将程序的功能或修改后的版本作为服务提供给第三方，那么必须免费公开提供服务源代码」；换言之，如果你用了我的程序提供服务，就要大方地把整个配方（包括前后台）都交出来。这违背了 OSI 对开源软件定义的第 9 条规定（许可证不能限制其它的软件），因此不能算「开源」。

另一方面，Elastic License 虽然不限制其他软件，但要求不能向第三方提供主机或托管服务。这违反了 OSI 定义的第 6 条（不得限制使用领域），因此也不算严格意义上的「开源」。

开源许可证

所谓软件许可证，就是随软件一起发布，对软件的使用、修改和分享及其他相关事宜作出规定的条款。开源许可证，就是开源软件使用的许可证。

这里，一个存在争议的重要问题是软件许可证的法律界定。在美国，一些法院认为软件许可证是合同（contract），一些法院则认为是许可（license）。两者的区别在于，许可在传统上是由地产或物主作出的，目的在于允许他人使用自己的地块或物品。因此，它是单方向的，不构成完整的合同，而是作为合同的一个要素，用来和他人交换的条件。

合同和许可之分在美国法上具有重要意义。如果是合同，那么需要适用各州不同的合同法；如果是许可，那么需要适用统一的联邦版权法。除此以外，合同的违约救济和版权的侵权救济也有着诸多不同，比如禁令（行为保全）的适用、判赔额的确定、律师费的分担等。

不过，包括中国在内的大陆法系国家，则普遍认为开源软件许可证构成合同；只不过这种许可合同并非协商得到，而是事先规定好的标准化格式合同罢了。具体来讲，开源许可证是涉及版权、专利、商标等一系列权利义务的格式合同，且自动生效。

法律并没有限定许可证不能包含什么条款，这导致许可证的类型极其繁多、内容也非常自由。据不完全统计，广义上的开源许可证目前有超过 200 种，即便是 OSI 批准的许可证目前也有 96 个之多。

一些开源许可证的规定可谓「天马行空」。例如，啤酒软件许可证（Beerware License）规定，用户与作者聚会时可以请作者喝一杯啤酒；Jason Hunter 许可证规定，如果将该许可证下的代码用于商业目的，那么项目开发团队的所有成员都必须拥有 Jason Hunter 撰写的《Java Servlet编程》最新版。

但幸运的是，绝大多数开源软件使用的都是几种常见的许可证之一。因此，了解常见许可证的内容一般就足以应付大多数实务场景了；根据专门提供开源软件合规服务的 Whitesource 的调查报告，90% 左右的开源软件都在使用 10 个许可证（包括同一许可证的不同版本），具体如下图所示：

下面，我们挑选其中排名靠前的几个重要许可证具体介绍。

常见开源软件许可证介绍

Apache

排名第一、风头正劲的是 Apache 2.0 许可证，它在近年夺下了 MIT 许可证的宝座，成为使用最多的许可证。

Apache 许可证是一种「宽松」（permissive）的许可证，目前常用版本是 2.0。这里，「宽松」是指不保证被使用软件的派生版会继续保持自由软件的形式。换言之，就是「怎么用都行，用在哪都行」。与之相对的是著佐权许可证（Copyleft），要求使用者修改后的衍生作品必须要以同等的授权方式释出以回馈社会，即强调「互惠性」。

具体而言，Apache 2.0 许可要求保留版权和许可声明，但允许许可作品、修改和更大的作品在不同的条款和没有源代码的情况下分发，只是未修改的部分仍然需要保留 Apache 许可证。此外，Apache 许可证不仅及于软件的版权，还及于软件的专利权，解决了开发者的另一大心病。

由于上述利好条件，Apache 2.0 成为了相当多流行的开源项目的许可证，最著名的例子之一就是 Kubernetes。

MIT

排名第二的 MIT 许可证之名源自首倡者麻省理工学院（Massachusetts Institute of Technology, MIT），又称「X许可协议」（X License）或「X11许可协议」（X11 License）。

据统计，2015 年 Github 上高达 45% 的项目都使用 MIT 许可证。哪怕最近几年 MIT 许可证的份额有所下滑，甚至 2020 年市场份额第一的位置被 Apache 2.0 取代， MIT 许可证仍然是最受开发者欢迎的许可证之一。

MIT 的特点在于条款非常简单，实质内容就是一句长长的授权：「被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和/或贩售软件及软件的副本，及授予被供应人同等权利」，加上要求被许可人保持同样的声明。

如 GitHub 高级产品经理、同时也是一名律师和开发者的 Ben Balter 所说，开发者选择 MIT 许可是因为「它简短而直接 […] 显然是一个为开发者优化的许可证。你不需要法律学位就能理解，而且实施起来也很简单。」

几年前，Facebook 公开用 MIT 许可证取代了有争议的 React 许可证。其他使用 MIT 许可证的知名开源软件或者项目包括 Angular.js、Rails 和 .Net Core 等。

GPL 许可证家族

这就是文首所述案件的主角，让柚子公司翻船的开源许可证，也是争议和疑问最多的许可证之一。

GPL 许可证是一个许可证家族的泛称，先行常用的具体包括 GPL v2、GPL v3 和 LPGL v2.1 等。这组许可证的共同特征在于「臭名昭著」的传染性：任何基于 GPL 代码编写的软件都必须成为开源软件。换言之，使用了任何 GPL 代码的软件，无论 GPL 代码的占比多少，都必须将完整的源代码公开，并允许他人修改、发布。

或许正是由于限制过于严苛，GPL 家族的许可证的市场份额持续下降。但考虑到其历史地位和实务重要性，仍然有了解研究的价值。

GPL

初版 GPL 由前自由软件基金会的主席、知名开发者理查德·斯托曼于 1989 年编写，提供给列入 GNU 项目的一些软件程序使用（最有名的包括文字编辑器 Emacs、C 语言编译器 GCC 等）。1991 年 6 月，稍加完善的 GPLv2 发布，这也是很长一段时间以来使用最广泛的版本。

GPLv2 许可证尽管经典，但也存在一些漏洞。例如，它不能阻止一个软硬件结合的系统中，通过对硬件部分施加限制，间接阻止用户在在该硬件上运行软件的修改版本，即所谓的「Tivo 化」问题。此外，它没有包括关于专利的约定，导致实践中出现 Microsoft-Novell 专利协议这类试图将专利申请用作于对付自由软件社群的武器的现象。

为解决这些问题，GPL v3 于 2007 年发布。除了填补上述漏洞，跟 GPL v2 相比，GPL v3 的兼容性更好。所谓兼容性，是指这两个许可证下的代码可以合并为一个更大的项目。自由软件基金会明确表示GPL v3 与 Apache 2.0 许可证兼容。

目前，仍然使用 GPL 许可证的重要项目包括 Linux 内核和 MySQL 等，但新兴的项目会一般会选用更宽松的许可证。

LGPL

开源软件并不一定是能独立运行的完整软件，也可能是不能独立运行，而是作为其他软件的组成部分、提供功能支撑的代码库（library）。对于这类使用场景，原版 GPL 的规定显得过于严苛了。

因此，在 GPL v2 发布同时，程序库通用许可证（Library General Public License，LGPL）也随之诞生。最初，LGPL 是 GPL 的补充，版本也追随 GPL，但从 LGPL v2.1 发布开始具有了独立身份，也被重命名为GNU宽通用公共许可证（Lesser General Public License，简称仍然是 LGPL）。

LGPL 的特点在于，链接到该软件库的软件可以不适用 LGPL 或 GPL，换言之，可以不公开源代码。LGPL 的这一特性消除了在 GPL 下软件商用的最大障碍。尽管如此，基于该库修改而得到的软件仍然需要遵循 GPL 许可证。

一个很有趣的问题是。理查德·斯托曼本是一个坚持软件自由丝毫不可侵犯的人，为什么像他这样的人会同意将自己的代码用于闭源产品？这其实是他以退为进、推广 GNU C 语言库的策略。1991 年的时候，市场上有很多 C 语言库可以选择。如果 GNU 的 C 库是原版 GPL 许可证授权，那么很多私有软件不会选择它。闭源软件中有开源的成分，总比一点没有好。（这也就解释了为什么后来 JavaScript 的代码库，大多数都选择了类似 BSD 的宽松许可证而不是 GPL 许可证——因为可替代的竞争者实在太多了。）

BSD

BSD 许可证是由加州大学伯克利分校首倡和维护的，同样是一个版本繁多的「家族」。目前常用的版本包括原始的 4 句许可证（BSD）、修改的 3 句许可证（BSD3）以及简化的 2 句许可证（BSD2）。

BSD 属于宽松许可证，与 MIT 许可证接近但更加宽松，甚至跟公有领域更为接近。在最简化的 BSD2 许可证下，保留著作权声明、许可证内容以及免责声明即可；只要满足许可证设定的条件，就可以自由地修改并发布代码。

BSD3 许可证在 BSD2 许可证的基础上增加了禁止背书条款（未经事先书面许可不得使用原作者之名来推广衍生作品）；BSD许可证进一步增加了广告条款（衍生作品的广告材料必须说明该软件「包含由加州大学伯克利分校及其贡献者开发的软件」）。

开源许可证的选择

既然开源许可证如此多元，如果你自己打算开展一个开源开发项目，该如何从上百个开源许可证选择合适自己项目的开源许可证？

对于这个问题，比较实用的工具是乌克兰程序员 Paul Bagwell 的分析图，通过简单的三步判断给出推荐，基本能满足大部分人的需求。由阮一峰制作的中文版如下：

如果需要更专业的分析，建议查询 Github 建立的 choosealicense.com。该网站从 13 个维度对比许可证，并提供选择建议。

顺带一提，从上表可以看出，除了上文提到过的允许商业性使用、分发和修改外等常见特征外，开源许可证还有两个共同点：首先，开发者不承担保证责任（瑕疵担保责任）。开源代码通常都是免费提供的，因此开发者不应为他人使用该软件造成的损失而承担责任。其次，要求保留著作权标记。开源软件并不意味着放弃著作权。相反，开源许可证的强制效力来源，恰恰来自于作者对开源软件的著作权。因此，许可证一般都要求以适当的形式保留著作权标记（包括许可证正文以及作者署名）。

结语：开源软件的动向和展望

浏览过去几年开源领域的动态，就会发现商业公司对于开源的重视程度不断提高，即使传统厂商对于开源软件和技术的态度也越来越开放。先有 IBM 以 340 亿美元收购了开源软件制造商 Red Hat，后有 Salesforce 以 65 亿美元收购了 Mulesoft。

就连一直以封闭而「臭名昭著」的微软，也努力展现拥抱开源的姿态：在 2018 年携 6 万件专利加入开放发明网络（OIN，Open Invention Network），后又斥资 75 亿美元收购 GitHub。大型科技公司一方面依赖于开放源码项目，另一方面也为其贡献代码，或在开源许可证下提供自己的内部工具，并将其作为反映企业责任感的宣传点。由此可以预见，整个开源体系的扩大使得开源许可张会发挥越来越重要的作用。

开源领域的另一个动向是，开发者试图突破传统开源许可证的固有模式，在创造可行的商业模式和维护成功的开源项目之间寻找更好的平衡。越来越多小型但关键项目的开发者，开始寻求更新开源许可证或者创建新的许可证。上文所提到 Elastic 之所以不惜放弃开源之名，也要换掉 Apache 许可证，正是现有许可证不能满足新需求的一次矛盾集中体现。

最后，开源项目所体现的数字优先思维方式和远程优先协作模式，在新冠疫情的背景下也价值凸显，为行业调整工作方式提供了经验。

在讨论开源开发模式的《大教堂与集市》一书中，Eric Raymond 力主那种在开发过程中即将源代码公开以便查阅和反馈的「集市模式」，并预言：

开放式的文化会最终胜利，这或许不是因为「开放」在道德上正确，或者「封闭」在道德上错误，而只是因为开放式合作可以在一个问题上投入多几个数量级的技术工时，封闭的世界无法赢得这样的竞争。

今天回看，「集市」的理念无疑正被越来越多的公司和开发者接受。不过，集市越大、交易越多，规则的重要性也就更高。开源许可证正是开源软件这个思维「集市」中的交易规则；让我们一起期待它更精彩的演化。