开源许可证的变迁：从 Elastic 两次变更开源协议说开去

| 2022-05-21

图18: 开源许可证的变迁：从 Elastic 两次变更开源协议说开去

开源从开始到现在已经有几十年历史，开源许可证在开源运动的发展中起到了基石作用，不管是从文化还是法律的角度，都较好地推动了开源的发展。

去年（2021 年），Elastic 公司的 Elasticsearch 和 Kibana 这两个开源项目都更改了开源协议，从 7.11 版本开始，由之前的 Apache 2.0 许可证调整成 SSPL 与 Elastic License 双许可。这次调整在开源社区以及技术界引起了轩然大波，有人说是因为云厂商的阻力，有人说是因为 Elasticsearch 不再需要社区协作的资源。最后 Elastic 公司在官网上澄清，说这两个项目改了许可证之后就不再是开源项目，但是它们依然具有一定的开放性，比如依然可以访问源码，依然可以参与协作。Elasticsearch 目前是否仍是开源的呢？如果不是，是否具有一定的开放性呢？

本文整理自字节跳动知识产权高级法务孙振华在DIVE全球基础软件创新大会 2022的演讲分享，主题为“开源许可证的变迁”。

分享主要分为四个部分展开：第一部分简要介绍开源、开源协作的相关内容；第二部分是目前开源许可证的分类；第三部分是开发者如何较好地解读开源许可证；第四部分是开源的商业模式以及对开源和开放的理解。

以下是分享实录：

基本概念

开源的定义

业界目前对开源还没有统一定义，比较主流的解释包括了四五种。比如开放源码促进会（OSI）给开源下了个定义，包含十条内容，是开源领域中比较重要的共识。但是这个定义是针对开源软件许可证的定义，而非给“开源”本身的定义。

我认为开源也是一种开发模式。我们通过追溯历史，可以看到，不管是 Linux 这种非常成功的操作系统方面的开源项目，还是后来新生代云原生的 K8s 项目，都依赖个人和组织的合作，开发了对合作方以及其他第三方都有益的公用产品。“个人”包括开发者、文档撰写者或社区建设专家；“组织”包括各个公司，比如谷歌、IBM、微软，这些公司都先后投入其中，推动开源开发模式的发展。

第二点，从法律角度来看，开源聚焦于软件分发相关的权利。传统的专用软件限制相关作品的分发，作者把所有权利都控制在自己手中，没有作者的允许，不能修改、复制和分发，放在软件行业，就在一定程度上限制了软件的分发过程。开源则把这些权利都放开，这有助于软件的分发，甚至让软件变得更加流行，因而成为一种事实标准。

开源究竟是不是商业模式？这一点比较有争议。微软的一些专家认为它只是一种开发模式；但 IBM 的一些专家，比如现在其开源办公室的负责人，他就坚持认为开源是一种商业模式。为此，两方几乎每年都会要辩论一次。

著作权

接下来我介绍一下开源相关的法律知识，以著作权作为基点。著作权的标记是一个圆圈，中间有个字母 C，向右开口。有人把它解释成这是一种保留性权利，作者或者软件开发者会把源码控制权，包括后续的分发权、复制权和修改权都控制在自己手里。如果没有作者允许，任何人不能修改、复制和分发这些代码。这不利于大家参与软件的后续改进。因为如果想获得改进的权力，要逐一和作者或者软件拥有人签署相关协议。这客观上从法律方面限制了协作。

著“佐”权

为了达成好的协作方式，开源领域中的英雄人物，理查德·斯托曼，发明了一种著佐权，称为 copyleft，是伴随自由软件运动兴起的一种基于著作权的权利。软件分发人或者作者限制了自己的权利，来保证所有用户都能获得源码，并且允许下游用户修改、复制和分发。

虽然著佐权和自由软件运动联系在一起，里面有“自由”一词，但这个“自由”保障的是下游用户获得源码的自由，并且具有修改、复制和分发软件的自由。这其实是对作者或者分发者的权利限制。

使用类似于 copyleft 的自由软件的代码，需要承担向下游用户提供代码的义务，这就是使用这种自由软件代码需要付出的成本。

Copyleft 还是从最初的著作权分化出来的一种比较好的许可模式。作者或分发者在众多的权利中，给下游用户赋予了其中一些权利，默认大家可以自由修改、复制和分发相关软件和代码。在不断修改的过程中，修改可以回馈到上游开源项目的主分支中，让开源项目不断成长扩大，拥有更多功能，修复更多 bug。正因如此，Linux、K8s 这种项目得以不断成长扩大。

为了表示和传统著作权不同，理查德·斯托曼把原来著作权标志里的 C 转成开口往左，表示对原作者某些权利的让渡或者放弃，包括对二次分发软件的分发人的权利限制，从而保证下游所有用户的源码自由。这个保证不是针对特定用户，而是保证所有接收到软件的人，都有获得源码的自由。

著“?”权

随着自由软件运动的不断发展，不少人认为，这种自由虽然保证了下游用户的源码自由，但是对软件开发人、传递人的权利限制过多，或者对公司不够友好。所以大家又把传统的自由软件进一步发展成开源软件运动。同时，开源软件运动也选择了非常有意思的标记——把著作权标志里的 C 往下转，表明自己对权利的限制、让渡没有那么紧。具体而言，分发代码给下游用户不再强制要求分发相关的源码。很多商业公司都比较喜欢这种方式。这种对商业比较友好型的开源软件运动慢慢成为主流，胜过了原来自由软件运动的一些思潮，被更广泛地接受。

开源许可证的分类

如上所述，开源软件、自由软件运动的基石都在于对权利、许可方面义务的让渡或限制。因此，可以通过对不同权利的让渡和限制来给具体的开源许可证划分类别。

自由软件

自由软件之前是专有软件的盛行时期，软件基本都是闭源开发的，不允许下游用户修改、复制或者发行。源码控制在一些大型商业公司手里。但是哪里有限制哪里就会有反抗，逐渐出现了像理查德·斯托曼这种大神。

斯托曼在使用一台打印机时，发现打印机软件有一点问题，想去问厂商索取源码，自己修改一下，让打印机正常工作。但是过了很长时间，打印机厂商也没有提供相关源码给他。从此斯托曼心里埋下了一颗种子，他认为用户应该有更大的权利，能获得相关的源码进行改进，双方的权利才会对等。于是他开始逐步推广自由软件运动。同时，他也和一些律师合作，拟定一些相关的许可协议，以及认可其他已经制订的开源软件协议或自由软件协议。

这些协议包括众所周知的 GPL、LGPL、AGPL、MPL、EPL 等协议，它们最大的共同点是要求在发布软件时分发相应的源码。其中像 GPL 这种协议要求最严格，一般会要求提供或分发包含 GPL 代码的独立软件给下游用户时，要提供相应的源码，或者至少提供一个书面要约，声明在三年之内可以向下游用户提供和软件一致的相关源码。

后来大家觉得 GPL 太霸道，要求提供的源码太多了。如果说针对 GPL 软件做了较多更改，就得把几乎所有源码都提供出去，商业公司可能会因此丧失竞争优势。于是诞生了另外的一种协议——LGPL 协议。使用 LGPL 协议分发软件，并不要求分发整个软件源码，只要求分发相关的库或部分源码。因此 LGPL 协议在一段时间内迅速流行起来。

进入网络时代后，分发软件场景有了变化。比如说在云服务或者 SaaS 服务的场景下，虽然不再分发实体软件，但是它们通过提供服务，实质上等同于分发了软件。所以后来又出现了 AGPL 协议，它规定当用户和软件通过网络进行交互时，可能就会产生一部分披露源码的义务。

因为每次发布自由软件时，都无论如何要提供一定的源码，所以很多人也把自由软件称为具有互惠性的软件。也就是说，改进他人源码分给下游用户时，作为一种互惠，也需要把自己修改的源码提供给下游用户。这限制了分发者或者原作者的某些权利，所以在某些场景下，也被称为限制性的开源协议。

在早期（约 2003 年或者以前），有些大商业公司认为，GPL 协议或者 GPL 背后的 Linux 系统会对他们的软件生态产生较大影响。特别是把 GPL 代码引入到相关的代码仓库后，再次分发时有义务提供比较多源码，于是他们就在社区和技术领域中制造某些恐慌，认为 GPL 具有传染性。我个人认为说“传染性”是不恰当的，因为用别人的软件时应该明白，既然不用付钱去获取代码，就应该在其他方面付出对价，比如披露某些源码。把这描述成一种互惠更加合适。

每次运动背后都有一些英雄人物。比如之前提到的自由软件运动的创始人理查德·斯托曼。他认为专有软件对用户不公平，因为用户没有权利获得源码，等于购买东西后完全不能控制。他认为用户有权获得源码，因此他创建了 GNU 项目，推动自由软件运动。

自由软件示例

随着自由软件运动不断发展，诞生了一些非常成功的项目，比如 Linux、GCC、Firefox 和 Eclipse，它们分别用了 GPL2.0 协议、GPL3.0 协议、MPL2.0 协议和 EPL2.0 协议。这些协议同时也是开源软件协议。开源软件协议虽然不再强调在分发软件时必须分发源码，但是自由软件协议里鼓励大家参与的共享精神，或者说允许修改、复制、分发一些权利，和开源软件定义也契合。所以说部分自由软件协议也被认可是开源软件协议。

开源软件

开源软件许可证由开放源码促进会（即 OSI）认证。该促进会维护一份开源协议清单，包括常见的 BSD 协议、MIT 协议和 Apache 许可协议等等。开源软件不再强调用户自由，更加注重商业友好性，所以把 C 改为开口向下，让用户和软件开发者都既可以选择分享源码，也可以把源码保护起来，仅分发二进制的软件。

这里有一个历史契机。在 1998 年，开放源码运动发展时，Linux 和其他一些自由软件已经相当成功。大家发现，即便不强迫分发源码，大家也愿意参与上游开源软件或自由软件开发，这在某种程度上已经达到了一种共识：不做过多强迫。大家参与到开源协作中，如果认为可以从中获利，比如开发者可以研究、学习新知识；商业公司可以推广一种标准，或者基于开源软件构建商业产品，都是可行的。这种比较友好的方式可能能够吸引更多人来参与共建。

开源软件背后也有相应的推动人物。比如开放源码促进会，就是由埃里克·S·雷蒙德和布鲁斯·佩伦斯在 1998 年创立的。作为非营利机构，开放源码促进会为了传播和捍卫开源共识，或者为公司推广这种模式而成立。

前面提过，开放源码促进会对开源软件的定义包含十条内容。这十条不是严格的制度，而是共识，是从 Debian 社区里继承来的，并非凭空产生。所以说，从自由软件到开源软件，以及开源软件定义的角度来看，整个运动的发展就是不断达成共识的过程。

开源软件除了符合 OSD 的定义，在某些情况下和自由软件有类似的好处。比如说用户在最初时也会获得源码，不管对软件最初的开发者还是传递分发者，限制都比较少。因此大家可能更愿意去参加这种开源运动。

雷蒙德的看法

雷蒙德在推动开源软件的同时，也为专有软件辩护。他认为开放协作是一种方式，闭源研发也是一种方式，可以自由参加。想相互合作的可以一起协作，不愿意也无所谓。这种比较柔和的像水一样的态度，反而能够吸引更多人来参与项目开发。他当年在 Firefox 对抗微软的过程中做出了一定的贡献，帮助网景公司发布了 Netscape 的源码，同时也协助开源律师一起创建了 MPL2.0 开源协议，促进了开源运动的发展。

开源软件示例

开源软件也有一些非常成功的示例，比如大家耳熟能详的 Android 系统、Apache 基金会下的系列开源项目，以及后来的 PHP、Python 这样的语言，都是开源软件的成功范例。随着开源软件不断发展，目前在操作系统、数据库以及中间件各个领域中，出现了越来越多的开源软件。大家也慢慢认为开源在技术软件领域，在协作和共识方面都能达到比较好的效果。

从自由软件到开源软件的历史

谈到从自由软件到开源软件的历史，除了斯托曼和雷蒙德外，还有一个人不得不提，那就是 Linux 之父 Linus。他在整个运动中起到了非常重要的作用。如果我们只有协议和共识，很难推动开源项目的发展。Linus 最大的两个推动作用，一是编写了 Linux 内核，这几十年一直在推动内核不断进展；另一个是开发了 Git 系统，让大家能够通过一种机制更好协作，让系统不断发扬光大。借着这两项创举，他让开源协作（或者说是自由协作）变成了可能。

开源许可证的解读方式

很多情况下，大家都是从使用开源项目开始，逐步过渡到向开源社区提 PR 或 issue，参与到共建过程中。在使用开源的过程中，怎样比较好地解读许可证，又不至于过度烦琐呢？

自由软件和开源软件有一定重叠，比如说 GPL、MPL、EPL 这些协议，都是既满足开源软件许可证需求，又满足自由软件定义。https://spdx.org/licenses这个网址列了一些非常主流的开源许可证，标出了自由软件和开源软件各自认可的许可证，还用目前的 SPDX 国际标准对这些许可证做了缩写。在网页上可以通过点击链接查看每个许可证的具体条文，建议仔细读一下。即使已经在开源软件或者自由软件领域工作较久，还是非常有必要关注一下细节，或者它们产生的前因后果，比如历史背景是什么，当时解决了什么问题，对我们现在解决问题有没有帮助。

自由/开源许可证的谱系

解读开源许可证往往从两个角度来看。一是从互惠型角度，涉及对自己权利的某些让渡，包括分发代码时可能要分发源码。二是从比较宽容的角度，像 MIT、BSD 这种协议，对分发者或使用者没有特别多要求，不强制要求分发源码。

我建议大家在使用开源软件时，从比较严格的互惠型许可证看起。使用相关许可证的代码时，要看一下许可证是否要求披露一定的源码。像 GPL 这种协议，要求披露所有修改或者程序内所有源码，如果源码里放了不方便公开的信息，就容易违反开源协议，出现社区问责或者诉讼，就会比较难处理，一是有法律风险，二是损害公司声誉。特别是现在，不管美国、欧盟还是中国，都有案例证明开源许可证受法律保护和认可。美国往往会认为开源许可证是一种单方的授权；在大陆法系，比如中国，则会认为是一种合同。使用了 GPL 的代码就要遵守相关的开源协议，否则会造成侵权和违约，代码所有方或授权方可以依据相关协议提起诉讼。去年，国内已经有不少法院认可开源许可证的效力。这很有意义，可以让大家更加正视开源许可证，吸引更多人来关注许可证在软件发展、开源自由运动中产生的积极作用。

至于宽松型协议，像 MIT，它的要求是最佳宽松的，只要求分发代码或软件时说明用了哪个开源项目、开源项目的作者、许可证是什么。

BSD 下面细分好几种协议，但要求也不是特别高。要求最高的，可能会强调一下不准用项目开发人的商标。

木兰协议有点特殊。它是这两年中国推出的一种协议，比 Apache 协议还要宽松，不要求修改代码之后明示修改了哪些代码。木兰协议有中英文双语，双语都作准，所以在推广开源运动、开源精神和普及开源方面都有非常重要的作用。

宽松型协议里还有一个重要成员是 Apache 协议。它有一个专利授权条款，只要使用 Apache 的软件，便不能对软件的发起人或者上游所有贡献者就软件本身提出专利诉讼。这样其实是让大家变成一个实质上的社区，维护相关软件。从这个角度上来说，意义也非常重大。

木兰宽松许可证

这里也专门提一下木兰宽松许可证，它有非常多优点。

首先，许可证的内容以中英文双语表述，两种版本具有同等法律效力，方便更多本土开发者阅读和使用，可以作为学习开源许可证的入门。

其次，木兰宽松许可证经过了国内技术专家、法律专家的共同修订，也经过了开放源代码促进会 OSI 的认定，现在也是 OSI 认可的符合 OSD 标准的协议。它明确了合同双方在行为约束的前提情况下，尽可能精简相关条款，优化了相关表述，同时可以降低产生法律纠纷风险。

自由/开源许可证的适用

在使用开源许可证时可以参考上图。许可证里有很多特别细的细节和难懂、模糊的条款，开发者使用时，需要注意从自由到开源的不同要求。

当使用强互惠型的开源许可证，比如 GPL 类型的许可证，为了保障下游用户获得源码的权利，分发软件时需要提供相关的版权、许可证的信息，并且要披露相关的源码，或者至少要提供书面要约，承诺在三年内会提供源码。

相对来说，弱互惠型的协议为了保障下游用户部分源码的自由，分发软件时要披露部分源码，也要提供相关的著作权以及许可证声明。

比较宽松的许可证往往不再要求分发软件时提供源码，但是往往会要求提供相应的版权信息、许可证信息，甚至一些其他声明信息。

另外还有一些，可以说是超级宽松的许可证条款，往往就是使用者权利最大化，基本上没有什么义务。

这是开发者平时需要关注的基本要点。但是公司使用时，可能还要关注许可证的商标或者专利方面的需求，避免法律风险。

总结来说，使用许可证虽然可以免费获取代码，但并不代表使用或分发时完全无偿，使用者也有一定的合规义务，从重到轻依次分为披露独立程序代码、披露部分代码、至少保留相关的版权以及许可证信息。

基于开源的商业模式

基于开源的商业模式，其中一个基本点是：所有的开源软件都要求你获取分发代码，你分发代码时基本上是免费分发，所以用户可以免费获得你代码的副本。

支持服务

我们往往不能从对代码本身的限制或者售卖副本来收费，而要围绕代码提供其他服务来收费。比如说红帽，为用户提供有偿技术支持和咨询服务。还有一些其他收费模式，比如说商标授权等。

托管服务

第二种商业模式是托管服务，代表企业是 Databricks，供应商会将把其他的开源软件作为服务，托管到云上，每个月收取相关费用。

限制性许可

第三种是限制性许可，以 redis 为代表。限制性许可已经不是开源许可证了，会在某些场景下限制使用。比如说使用双许可，用 GPL 协议发布代码，当不想发布产品时同时提供源码，又可以买一个商业的协议版本，这就取消了对 GPL 相关协议的限制。

开放核心

第四种是一种开放核心的做法。软件主要功能都是用开源协议开发的，但还有一些专有部分，打包成与开源服务连接的模块或服务，或者在一些分叉版本中特别为某些企业客户提供。这也是一种牟利的方式，代表企业就是 Confluent。

开放核心+混合许可

第五种被称为开放核心，以及混合许可，代表企业正是 Elastic。Elasticsearch 和 Kibana 在 6.3 到 7.10 版本时，采用的就是这种许可方式。它大部分源码都是用 Apache 2.0 协议发布的，一些特别核心的功能则采用了比较专有的 Elastic License 协议，不允许用户修改或者破解代码。这种方式同时在产品中使用了专有代码和开源代码，所以被称为开放核心和混合许可模式。

以 Elasticsearch 为例

Elasticsearch 在 6.3 版本时，在公开的代码仓库中，把代码分成了两部分（如上图）。一部分是开源代码，以 Apache2.0 协议作为许可，另一部分专有代码放在专门的名为“X-pack Code”的文件夹中，这部分代码是用 Elastic License 许可的。想用这部分代码功能需要付费。

一段时间后，Elasticsearch 发现有些云厂商还是能突破限制。比如说云厂商会可能会基于 Apache 协议，尽量拓展在功能方面的限制，比如利用自己的某些优势获取更多客户。所以 Elastic 就把它的开源项目做了进一步限制，在公开的代码仓库中，把代码许可方式分为了两种，其中第二种是用 Elastic License 2.0 作为许可，针对云厂商做了一些限制，如果把 Elastic License 2.0 用在云上或者作为托管服务，肯定要向 Elastic 付钱；而第一种选择则把整个代码仓库代码分为了两部分，一部分是 SSPL 协议下的代码，另一些是 Elastic License 2.0 下的代码。如果把 SSPL 的代码用在托管服务上，需要披露用于服务的整个代码。也许是因为要求披露代码太多，SSPL 协议并没有被开放源码促进会认可为开源协议。

基于这种改变，Elastic 也不再把这两个软件称为是开源项目，而是称为比较开放的项目。

需要注意的是，Elastic 还有很多项目保持着 Apache2.0 协议许可，所以它还是拥有很多开源项目的。

要点总结

第一，自由软件保障下游所有用户的源码自由，对软件的分发者或使用者（“使用”是指把代码嵌入到一些专有代码中）再向下发布时，权利会受到一定的限制。

第二，开源软件更加商业友好，不再强调用户的自由，用户可以选择参与或不参与相关的开源共建。

第三，自由软件和开源软件都鼓励广泛协作。相对来说，开源软件更加商业友好。开源协作确实对商业有很大的帮助作用，所以公司往往会比较积极参与到开源运动中。

第四，某些软件不符合自由软件或开源软件定义，但具有一定的开放性（源码是可以获得的），而又对某些使用场景或厂商进行一定限制。当使用这些软件时，要仔细甄别这些许可证的要求。首先要甄别它是否属于自由或者开源软件，然后根据相关的许可证来保障自己确实能够合规使用。如果看到一个非开源许可证，就需要仔细分析，在什么方面有限制，是否需要购买，或者采用开源项目替换。

本文文字及图片出自 InfoQ

开源许可证的变迁：从 Elastic 两次变更开源协议说开去