本文从2019年多家著名开源公司因为云服务对其业务的威胁而更改代码许可的事件出发，分析了正反两方意见和心理，再通过开源发展中的历史教训举例，强调了开源的核心是慷概，并呼吁企业必须在开源和利用开源赚钱的权利之间划一条线。

站在2019年，自由软件和开源软件让我们当下所熟知的世界成为现实。从Web服务器到互动式咨询服务站，再到挖掘Facebook社交媒体消息的大数据算法，现在几乎所有与我们交互的计算机系统，至少都部分地使用了自由软件。而在更广阔的科技行业中，自由软件不仅催生了一大批创业公司，还促成了世界历史上最大的软件收购——IBM收购红帽（Red Hat）。

自由软件是一份让我们当前所熟知的世界成为可能的礼物。一开始，自由软件的出现让世界上的很多大企业产生抵触心理，以至于最初让那些不习惯这种模式的众多企业深感不安。这些公司并不是不愿意使用开源软件，只是这个概念太激进，于是就延伸出浓重的政治化色彩。它必须重新换一个名字，于是，它被命名为“开源”。

这一旦发生，开源软件就如洪水猛兽般占领了世界。

然而，最近在这些开源力量中出现了一种骚动。在过去的一年中，像Redis Labs、MongoDB和Confluent这样的公司都更改了软件许可证，从原来的开源许可证转向更严格的条款，限制了软件的功能，使其不再属于开源软件。

Redis Labs、MongoDB和其他公司对此的辩解是，这些变动的主要原因来自于一个更现代的技术趋势——托管软件服务。也就是众所周知的“云”。而在很多真实的应用场景下，这又专指亚马逊公司的AWS。

在这种骚动下，针对Elastic（Elastic Search背后的公司）的许可变更，亚马逊公司在今年春天发布了自己的Elastic Search代码版本。除了针对亚马逊的版本命名而状告亚马逊注册商标侵权以外，Elastic公司对此的回应与MongoDB和Redis非常不同，这家公司甚至都没有表示任何抗议。

“云”的爆发

MongoDB公司因其“NoSQL”的数据库产品MongoDB而创立。MongoDB的数据库对于存储非结构化数据（例如图像）非常有用，它可以像处理那些传统的数据类型一样处理图像。数据存储在类似JSON格式的文档中，而不是存储为关系数据库中传统的列和行。由于MongoDB中没有结构化的表，就没有所谓的“结构化查询语言（SQL）”来处理数据，因此产生了术语“NoSQL”数据库。

MongoDB并不是唯一的NoSQL数据库，但它是其中使用最广泛的数据库之一。根据DB Engines的行业汇总报告，当前MongoDB已经是全世界第五大最受欢迎的数据库产品，从谷歌、Code Academy到Foursquare，现在很多公司都在使用MongoDB。

而且，MongoDB还引领潮流地创建了一种新的开源许可，这家公司的CTO Eliot Horowitz认为，随着计算机技术进入云的新世界，有必要采取一些措施对开源软件业务进行保护。

Horowitz和其他人对此的解释是，在当前的云环境下，开源社区需要重新思考并有可能更新原来的开源许可，以“应对新环境中的新挑战”。从本质上来说，这些挑战来自于AWS、Google Cloud和微软Azure这些巨头，因为他们都有足够的能力将开源软件打包成自己的服务，然后转售出去。AWS或Azure打包MongoDB并将其作为基于云的SaaS服务（Software as a service）的一部分进行售卖，这样的问题在于，这些服务直接与MongoDB自己基于云的SaaS服务——MongoDB Atlas形成了竞争。这种情况下，受到威胁的不是MongoDB的源代码，而是MongoDB自己的SaaS服务，而这恰恰是该公司的主要收入来源。

为了应对这种挑战其底线的潜在威胁，MongoDB就试图将自己的许可证从GNU通用公共许可证（GPL）更改为所谓的服务器端公共许可证（SSPL）。SSPL许可证中写道，本质上，你可以用这个软件做任何想做的事情，除了用它来构建一些与MongoDB Atlas形成商业竞争的东西。

一开始，MongoDB将该SSPL许可证提交给开放源代码促进会（OSI）， OSI负责监督和批准新的开源许可证。但是，经过OSI来来回回的一系列邮件讨论后，再加上该许可证本身的措辞问题，使得SSPL不太可能被OSI 批准，所以MongoDB今年早些时候已经取消了对SSPL许可的申请。于是，SSPL并不是开源许可，而且将来也不可能成为正式许可。

如果要究其原因，可以首先了解一下情况，MongoDB并不是第一个遇到这种情况的开源企业。事实上，这个问题的一部分其实是，许多公司随意使用这些开源软件，但又对开源社区毫无回馈贡献，而来自多方的回馈和完善原本应该是开源软件存在的全部意义。

各类开源许可虽然各有不同，但其普遍适用的核心要旨自1998年成立OSI起便被定义如下：你可以使用这段代码，做任意你想做的事情，但是你不能拥有这段代码的专有所有权，如果你在另一个项目中使用了这些代码，那么这个项目也不能成为专有的。这些许可使用这样的字眼就是为了防止有些公司把开源代码放在自己的代码中使用，但又不把任何工作成果共享回原始的开源项目。

但是SaaS的概念在20年前并不存在。而到了今天，Horowitz认为，在SaaS产品中夹带一段代码其实就等同于在应用程序中使用它。

这是一个新颖的论点，但这其实是在为一个非常古老的问题做出辩护，而该问题已经远远超出了许可证的范畴。这是一个可以追溯到很久以前还未成立OSI，在自由软件诞生之时的问题——如果你免费提供软件，你该如何从软件中赚钱呢？

这个问题的一个传统的答案是，你可以围绕你的开源软件进行服务销售。但对Horowitz来说，这个答案还不够好。他告诉Ars Technica技术新闻资讯网站：“通过服务支持性合同来为开源软件赚钱从来都不是一个好的商业模式。” 红帽公司可能不会同意这点，但Horowitz坚信，更多的保护性许可将带来更多的风险资本投资，并在MongoDB使用的开放模式的基础上催生更多的软件业务。“我们很独特，” 他说，“但我希望这成为开源软件的风潮，让我们变得不那么独特。”

他可能是对的。保护性更强的许可证可能会吸引更多的风险资本投资，因为（当然也有待证明）这让他们的投资有更大的回报可能性。但是，如果这些资金真的向此处投资，这已经不算是投资于开源开发了，因为这种加在软件上的限制已经意味着它不再符合开源软件的定义。

反对的意见

然而，还有相当多的开源倡导者已经对MongoDB其CTO Horowitz的观点提出了反对意见。这些人认为，目前的这一套开源许可证的定义并没有问题，需要改进的是商业模式。

Bruce Perens，最初开源定义（OSD）的联合作者之一，他认为SSPL与OSI的开源定义第九条是不兼容的，第九条说“许可证不能限制其他软件”。由于SSPL强制地让任何包含了该软件的整个SaaS软件，即使其中有些代码并不是该软件的衍生部分，统统都成为开源软件，因此和开源定义的第九条是相斥的。“当初我把第九条写进了OSD，就是为了禁止这种行为，” Perens说，“我认为OSD中该部分文本的意思清楚无误。”

而且，MongoDB也绝对不是唯一一个抱怨云计算正在侵蚀其利润的公司。另一家数据存储公司Redis Labs，是第一个针对云提供商对自身业务的威胁发出警告的公司，而Redis Labs最终可能会比MongoDB有更好的解决方案。一开始Redis Labs改变了它的许可证，加入了一种叫做“通用条款子许可证”（Common Clause sub-license）的东西，它禁止任何人出售包含这些代码的任何软件。当然，不管依照何种定义而言，带有这种通用条款许可的软件都不能算是开源的，而Redis Labs也认同这一点。它也从未将这些更改了许可的部分描述为开源性质的软件。

但是到了今年春天，Redis Labs又做出了另一项许可变更，从本质上放弃了其所有关于开源软件的伪装，对其中部分模块采用了自主开发的专有许可。说得更清楚一些就是，虽然大多数Redis代码是由三句BSD许可所监管的，但有些模块不是，具体而言即指RedisJSON、RedisSearch、RedisGraph、RedisML和RedisBloom这些模块。

根据Redis Labs加于这些模块的许可证，虽然用户可以查看和修改代码，或在其应用程序中使用这些代码，但该许可限制了用户可以构建的应用程序类型。有了Redis Labs的新许可证，你就不能用这些代码自由地构建任何你想要的东西。比如，你不能构建数据库产品、缓存引擎、处理引擎、搜索引擎、索引引擎或任何ML或AI衍生服务引擎。换句话说，你不能使用Redis Labs的代码来与Redis Labs竞争。这样的许可当然违背了开源许可的核心原则之一——对衍生软件没有限制。

遗憾的是，对于Redis Labs和MongoDB来说，不能一方面说自己是开源的，一方面又嚷嚷自己应该从开源软件中获利，这在道理上讲不通。而在另一个商业模式中，道理上是行得通的，那就是带专有所有权的软件。

这也正是Elastic所选择的一条道路，而且这条路已经开凿有一阵时间了。虽然这里面还有部分问题没有形成板上钉钉的规则，但不可否认的是，一些公司已经通过他们的开源代码和私有代码成功地蓬勃发展起来。Elastic公司就是这样一个例子，虽然它面临着来自AWS的激烈竞争，但还是顽强地坚持下去。

亚马逊公司不仅多年来一直在AWS上提供Elastic search，表面上已与Elastic自己的产品形成了竞争，最近亚马逊还打包了自己版本的Elastic search代码库，并将其扩展为免费提供的好几项服务，而Elastic公司尚未在这些服务方向上发布其开源服务。面对这样的挑战，Elastic公司我自岿然不动，其反应不过是潇洒地耸耸肩罢了。

历史的教训

为什么MongoDB还是想要让自己归类于开源呢？毕竟，专有商业软件非常成功的例子也比比皆是。为什么MongoDB并不愿意选择拥抱这条大道继续前进呢？

Horowitz告诉Ars Technica，他坚信“开源会产生更好的系统软件，尤其是在数据库方面”，他还强调了，继续让代码保持开源的性质就能拥有安全和社区两大优势。这两方面的优势他确实说得很对，只要保持开源，对该软件更多的关注就意味着更少的bug，更好的安全性。

但是让我们再回头看一看最初的开源定义，很明显，Horowitz忽略了深深地嵌入每种开源许可中的另一个关键要素——慷慨。

真正意义的开源永远不会限制你对软件的使用。绝对不会。这可能是开源这一概念能取得巨大成功的主要原因，这当然也是让这些开源产品成为大企业首选软件的原因。

这种慷慨是推动软件社区发展的方式，它是所有成功的开源项目的基石。通过允许尽可能多的用户使用你的软件，就可以为之获得尽可能大的软件社区。这意味着会有更多的人关注bug，有更多的人修复bug。这样的开源社区才有蓬勃发展的势头。而这种发展势头会变成产品的市场份额。有时市场份额会转化成为利润，但并不总是这样，开源产品并不能保证你最终一定能获取商业利润。

正如Perens所说，“我们必须在‘开源’和利用开源赚钱的权利之间划一条线。虽然开源定义允许你赚钱，但开源的本质并不支持你赚钱的权利。而且我们不会改变这条规则，因为你可以通过他种方式更好地赚钱。”

值得赞扬的是，Horowitz和MongoDB公司如今似乎已经接受了这一观点，或者至少说，在他们撤回SSPL作为OSI许可证的申请时已经接受了这一不可避免的事实。不会仅仅因为你创造了开源产品，产品问世了，这些产品就非得为你带来巨大的商业利润。

事实上，如果你创造了一个开源产品，他们问世了并传播了，然后此时你把它从市场上拿走了，这种状况可能比你从来没有创造过这款产品更糟糕。

Redis Labs从开源中收割了所有开源所能带来的好处，其中最主要的好处有社区支持、广泛传播和来自广泛来源的代码贡献，然后，Redis Labs选择背弃了开源。坦率地说，Redis Labs此举激怒了整个开源社区。

当自由软件开发者开始抓狂时，他们就会选择为代码拉出分支，而事实上，针对Redis变更许可问题，已经拉出一个名为GoodFORM的分支。GoodFORM分支为重新授权的Redis模块保留了许可变更之前的版本，这个项目将为Debian、Fedora和其他Redis不再发布专有软件的Linux版本一直维护这些模块。

于是Redis Labs的新许可证带来了一个意想不到的后果，那就是任何想要使用完整的、开源的Redis代码的人都必须使用GoodFORM分支版本，而不是Redis自己发布的版本。

或许个体开发人员不会太在意这其中的区别，但是希望使用开源软件的大公司就不会那么无所谓了。对他们来说，这通常会归结于一个选择——要么使用带有OSI许可的开源软件，要么打电话给律师咨询相关法律法规。没有人愿意仅仅为了安装一个软件而打电话给律师。

Perens告诉Ars Technica，这正是他们写下最初的开源定义（最初是为Debian项目编写的）背后的主要动机之一。“开源的定义意味着你不会仅仅为了成为一个软件的用户而需要一个律师，” Perns说。“而我们做到这一点的方法之一，就是最小化法律负担。”

然而Redis Labs的新许可证却将自己的公司用户置于需要律师的位置，因此GoodFORM成为了更合乎情理的选择。这也暗示了为什么MongoDB最终仍然想要保持其开源的特性。

从历史上看，其他从开源转为闭源许可证的项目进展并不算一帆风顺。在20世纪90年代的大部分时间里，Xfree86项目是运行X Windows的事实标准，这一直持续到21世纪初。从2004年起，Xfree86发布的代码，被自由软件基金会认定违背了GPL许可。那些使用Xfree86的下游操作系统认为这种状况是不可接受的，于是一个分支X.org诞生了。到了今天，X.org完全替代了Xfree86曾经占据的地位，而Xfree86则已经被历史所抛弃了。

其他不难找到的类似例子还包括：从OpenOffice中分离出来的LibreOffice分支，从MySQL的许可变更中分离出来的MariaDB分支，从Ethereal中分离出来的Wireshark分支，这样的例子简直举不胜举。在所有这些情况下，需要注意的关键点不仅仅是诞生了分叉，随之而生的还包括新项目带来的开发人员、社区和长期支持开源软件的发展动力。如果失去了来自开源社区的善意，那么它相应的报复就可能造成灭顶之灾。而报复的反扑常常也是非常高效的：Xfree86实际上在X.org启动六个月后就迅速死亡了，而OpenOffice也同样很快地就变得无足轻重。

因此，开源的历史带给我们的最重要的教训是，一旦你成为了开源集体中的一员，你就不太可能中途改道并依然生存下来。

开源的核心是贡献

如果开源的历史告诉我们，在开源这条路上没有回头路，那么值得思索一下，一开始为什么要选择开源。

Beanbooks是由Linux计算机制造商System76所派生出来的一个小项目，它也是Perens所认为的，开源软件理想场景的一个完美示例。在“新兴的开源经济范式”这篇文章中，Perens认为公司的非差异化软件是使用开源软件的最佳场景。也就是说，开源软件能提供公司业务的基础架构，但不是核心业务部分。

换句话说，Beanbooks并不是System76的利润中心，但它为System76的利润中心提供了一种支撑性技术，该公司的利润中心仍然是构建基于linux的计算机。

然而，尽管Beanbooks是开源许可证的最佳候选项目，但事实上它却并不是开源的。为什么呢？

System76的实际选择是出售一个托管的Beanbooks版本，即一个SaaS，当时公司担心之后会出现一个更大的公司，采用GPL许可监管的代码，但产品内容本质上是对Beanbooks的克隆，并从System76的投资中夺走所有的利润。所以System76的创始人Carl Richell说，他对MongoDB和Redis Labs这些公司的担忧表示感同身受，但是他之前就做出了选择，已经走在了“担心有人为了竞争而窃取你的代码而出售闭源SaaS软件”的非开源道路上，并为之深感后悔。

Richell对Ars Technica说：“我们担心有人会把这样的软件打包，那样的话我们会失去所有的投资。” 他说，System76在想要用一些类似专利保护的东西来保护这些软件几年，但那“最终伤害了我们，伤害了平台，我们本不应该抱有那些顾虑。”

虽然Beanbooks的SaaS版本看上去不错，但是这些可用的代码不会得到更新，而从自由软件的角度来看，没有更新的代码其实就毫无用处。这些代码的Github页面就像是是一个死寂的无人镇一样。没有人来推动代码的发展，没有交流的社区。尽管Beanbooks的服务还在继续，但伴随这种服务的并没有一个社区去贡献各种想法、代码、以及其他活跃的开源项目所拥有的一切公共社区资源。Richell认为，如果Beanbooks从一开始就拥有GPL或类似的开源许可证，它可能会避免自己现在的命运。

“如果有人想要使用这些软件，单就这一点来讲就已经足够好了，” Richell这样说。对他而言，成功的关键不是软件开源本身，而是随之而来的创新动力。“这其中的差异不是去看你今天的成就，而是你能以多快的速度进步，” 他有感而发地说。作为软件开发者，你有一个良好的开端，单就这一点并不够，你还希望对自己的长远目标有一个规划。用Peren的术语来说，这些才是在竞争中真正体现差异的地方。

“取得成功的唯一途径就是始终保持领先，” Richell补充说道，“我并不认为这和软件许可证有任何关系。”

多种软件自动化和部署工具的制造商Chef公司似乎对这一点深表同意。基于这一精神，又开辟了与MongoDB和Redis截然相反的一条道路。在今年春天，Chef宣布将之软件许可更改为在Apache 2.0许可下的完全开源。Chef首席执行官Barry Crist写道：“我们欢迎任何人使用我们的软件，并根据自由软件的四项基本自由原则对其进行扩展开发。” 虽然Crist发表的言论中并没有提及其他任何公司，但仔细揣摩，还是能看出“四项基本自由原则”这里的措辞正是针对Redis和MongoDB的一种回应。

展望未来

人人都喜欢听受压迫的弱者奋起反抗的故事，Redis Labs和MongoDB也想要把自己粉饰成一个开源的受压迫者，揭竿而起英勇反抗以AWS为代表的邪恶势力。而他们真的是受压迫的弱者吗？

至少目前看起来，Redis Labs和MongoDB仍然是非常健康发展的公司。今年早些时候，Redis Labs还筹到了6000万美元的资金，而且根据提供资金的公司而言，Redis已经为一次成功的IPO做好万全准备。而从各方面而言，MongoDB在2017年的IPO都算得上是一个巨大的成功。该公司股票首次公开发行价格为24美元，此后一直稳步攀升。如今，它的股价已经在每股100美元以上。在2019年早些时候，虽然MongoDB最大的用户之一Lyft确实转用了亚马逊，但在股价小幅下跌之后，MongoDB的股价又回到了Lyft变节之前的水平。

由此可见，两家公司其实都没有受到太大影响。或者说，至少现在还没有。他们许可证变更的影响还有待观察，但是考虑到之前MongoDB的大部分开发贡献本就来自于自家员工，所以无论是否开源，MongoDB很可能都能够一直保持不错的状态。

其实，这两家公司的业务都不会直接影响更大范围的整个开源生态。开源生态环境从来就不是适合每家企业的。正如Perens在今年早些时候的一次对话中所说的那样，“只要你不将之称为开源，你可以使用任何你想要的软件许可，那是你的自由。但如果选择开源，就得服从于某些权利，为了保护自己的商业模式而放弃这些权利在道理上是讲不通的。”

事实上，在我与开发人员和创始人的所有对话中，有一句话总是浮现在我的脑海中。System76的创始人Carl Richell说得再明确不过：“如果没有把‘奉献’嵌入到开源中，开源就无法工作。”

所以，在这种情况下，无论你报以什么目的来使用开源软件，奉献都是使用开源软件的基本权利。

这一直以来都是对所有新的开源许可的基本定性测试，即该许可是否限制了软件的慷慨程度？开源之所以能发展到今天，是因为它可以在任何地方、任何东西上使用。想要把开源软件和专有软件结合起来吗？可以。想要重新编写开源代码库，以便它可以与你的专有代码进行接口吗？也可以。想要把那个开源代码库拿过来，把它包装成一种服务，然后卖掉它吗？仍然可以。因为最终，这就是开源的定义：通过奉献而获得自由。正如Perens所指出的那样，即使这种模式对某些特定的企业不奏效，开源就是开源，本该如此。

英文原文：

In 2019, multiple open source companies changed course—is it the right move?

创作场景

2019 年多家开源公司改变了方向，这是正确的举动吗?