开源软件受云服务商影响，共用条款终止开源滥用现象-白红宇

开源软件受云服务商影响，共用条款终止开源滥用现象

阅读量：5897 次

发布时间：2019-06-19

本文共 3485 字，大约阅读时间需要 11 分钟。

地平线上出现了一片乌云。亚马逊等云基础设施提供商的行为威胁到了开源的生存。

我是一名风险投资者，在13年中先后投资了许多开源项目背后的公司：

Spring

Mule

Ruby Rails

Groovy

Grails

Maven

Gradle

Redis

SysDig

Hazelcast

Akka

Scala

Cassandra

Spinnaker

以及其他公司

开源已经在为社会服务，开源商业模式已经大获成功、有利可图。

亚马逊的行为

我很钦佩亚马逊的执行力。在风险投资行业，我们习惯于大型软件公司（比如IBM、Oracle、惠普、Compuware、冠群、EMC、VMware和思杰等）主要成为庞大的销售和分销渠道，这需要获得创新（即收购初创公司）为渠道提供活力。亚马逊则不然。2015年7月，《华尔街日报》引述我的话说：“亚马逊的执行力太强了，几乎就像一家初创公司。这对于生态系统的每个人来说都很可怕。”那个月，我在投资者网站Seeking Alpha上撰写了《提防亚马逊巨无霸》（https://seekingalpha.com/article/3333195-fear-the-amazon-juggernaut）。自我撰写那篇文章以来，亚马逊的股价已上涨了400%。（我间接持有亚马逊的股份。）

但对于其客户之外的任何人来说，亚马逊可不是一家温情脉脉的公司。好多文章详述了其残酷无情的企业文化。为什么它对开源的使用会有何不同？

进入到AWS，将鼠标悬停在顶部的“产品”菜单上，你会看到亚马逊并不创建，但是作为服务来运行的无数开源项目。这些项目每年为亚马逊带来了数十亿美元的收入。

比如说，亚马逊享用Redis（StackOverflow的开发者调查中最受欢迎的数据库），几乎没有回馈，将其作为服务来运行，改头换面后取名为AWS Elasticache。其他许多流行的开源项目同样被拿来后作为AWS产品来提供，包括Elasticsearch、Kafka、Postgres、MySQL、Docker、Hadoop和Spark等。

要说明的一点是，这并不违法。但我们认为这是错误的，不利于可持续发展的开源社区。

共用条款(Commons Clause)

2018年初，我召集了20多家大型开源公司（其中一些已上市）的创始人、首席执行官或首席顾问，畅谈该如何是好。3月份，我向GeekWire介绍了这项工作。大家在经过一番建设性的深入讨论后一致认定，我们应制定一种禁止这种行为的简单条款，而不是拐弯抹角，混合搭配多种开源许可证以阻止这种行为。我们邀请备受尊敬的开源律师希瑟•米克（Heather Meeker）起草该条款。

2018年8月，Redis Labs宣布决定将这个名为共用条款（Commons Clause）的附加条款（即另增一段条文）添加到其针对某些附加模块的自由开源许可证。Redis仍然采用宽松的BSD许可证，Redis本身却没有任何变化！但是Redis Labs附加模块将包括共用条款这个附加条款（它使源代码具有可用性），但无法“出售”模块，其中“出售”包括将它们作为商业服务来提供。目的是明确防止云基础设施提供商的不良行为。

包括通用汽车（GM）或通用电气（GE）在内的其他所有公司仍可以对软件做它们之前所做的一切，即使添加了共用条款。它们可以查看和修改源代码，提交合并请求，以便将经过修改的内容添加到产品中。它们甚至可以在内部将软件作为服务提供给员工。共用条款阻止商业服务与别人的开源软件一起运行，就像云基础设施提供商所做的那样。

不出所料，这则宣布在开源社区引发了热烈的反响，有点赞，也有炮轰。说到过于简化的风险：那些点赞的人认为这是开源许可道路上合理而积极的演变，让开源公司得以在投入于开源项目的同时成功运营业务。Ansible的开发者迈克尔•德哈恩（Michael DeHaan）在《为什么开源需要新的许可证？》中特别清楚地阐述了一个方面：

我们看到运营开源“基金会”和网站的一些人简直就是电视评论员，就“开放源代码促进会”之类的组织所描述的“开源”的定义发表政治论调，该组织旗下的许多项目拥有一定的人气或拥趸。他们试图声明源代码免费可用但使用场景有限的这种许可证“不是开源”。遗憾的是，这艘船已启航了。

那些持中立或反对态度的人指出，共用条款使得软件不是开源软件，这很准确；使代码库的一部分成为专有代码违反开源精神；Redis Labs准是走到了绝路，很难赚钱。

首先，别为Redis Labs而操心。这家公司做得非常好。Redis比以往任何时候更强大、更受宠、更恪守BSD。

更重要的是，我们认为现在是时候在当今的环境下重新审视开源的精神了。开源变得流行时，它旨在供从业人员拿来实验和改进，同时回馈开源社区。当时没有一家公司将基础设施作为服务来提供，也没有一家公司拿来开源项目后改头换面另取名称，将其作为服务来运营，攫取利润，但回馈甚少。

我们认为，开源软件从来就没有打算让云基础设施公司拿去后售卖。这不是最初的开源精神。共用条款在重扛最初的开源精神这面大旗。希望使用流行的开源项目用于其应用程序的组件的学者、业余爱好者或开发人员仍可以这么做。但是如果你想拿来实际上别人开发的同一软件，将其作为服务来提供以牟取私利，那就不符合开源社区的精神。

事实证明，以共用条款为例，这会使源代码严格上来说不是开源的。但是为了捍卫最初的开源精神，这是我们必须忍受的。

Apache +共用条款

Redis Labs发布的某些附加模块采用Apache +共用条款。Redis Labs明确表示，运用共用条款让这些模块不是开源产品，Redis本身仍然开源和采用BSD许可证。

一些偏激的开源人士指责Redis Labs试图诱骗开源社区认为模块是开源的，因为它们使用了“Apache”这个字眼。

没有什么花招。共用条款是附加到任何宽松的开源许可证的补充条款。由于各种开源项目使用各种开源许可证，因此使用共用条款发布软件时，必须指定共用条款附加到哪种宽松的底层开源许可证。

为什么不用AGPL？

这种场景下不使用AGPL有两大原因。AGPL是一种开源许可证，表明你将采用AGPL许可证的代码作为服务来运行时，必须向公众发布所做的任何修改。

首先，AGPL只是让云基础设施提供商有上述的滥用行为很不方便，但阻止不子。它只是表明它们有这类行为时必须发布所做的任何修改。其次，AGPL含有的软件专利方面的条文毫无必要，许多企业不喜欢。

我们投资的许多拥有AGPL项目的公司已接到了大企业的要求，要求转而采用更宽松的许可证，因为使用AGPL违反了它们公司的政策。

平衡之道

云基础设施提供商不是什么坏人，也不是恶意行事。开源始终是一种平衡之道。我们许多人信任客户和同行查看我们的源代码，进行改进和回馈。别人免费分发其工作产品，并相信你能够有所回馈始终是一种信任的飞跃。有时候对于一些项目而言，无需太刻意的努力，就会自然平衡。但在其他时候，自然平衡并不出现：我们从基础设施开源身上越来越多地看到这一幕，尤其是云基础设施提供商试图通过走向堆栈的上游：从大众化计算和存储走向更高级的基础设施服务，以此实现差异化。