共用条款终止 AWS 亚马逊、Azure 微软等云服务商滥用开源软件

开源

开源软件社区出现了一片乌云，亚马逊等云基础设施提供商的行为已经威胁到了开源软件的生存。

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

SpringMuleRuby RailsGroovyGrailsMavenGradleRedisSysDigHazelcastAkkaScalaCassandraSpinnaker等

开源已经在为人类社会服务，开源商业模式已经被证明有利可图，例如 RedHat 红帽公司。

亚马逊的行为

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

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

进入到 AWS 网站，将鼠标停在顶部的 “产品” 导航菜单上，您会看到亚马逊提供作为服务来运行的无数开源项目。这些项目每年为亚马逊带来了数十亿美元的营业收入。

比如说，亚马逊享用 Redis 开源软件，几乎没有回馈社会，将其作为服务来提供，改头换面后取名为 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 违反了它们公司的相关政策。

平衡之道

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

修订

截至本文发稿时的共用条款的版本是 1.0。将来会进行修订和调整，确保共用条款实现其开源精神的目标。我们想听听大家的意见。

我们看到的迄今为止就共用条款所表达的不同观念实际上是理念上的差异。许多批评来自并不属于用软件来赚钱这个行当的开源人士。他们有不同的理念，但这不足为奇，因为他们的工作是成为政治活动家，而不是为公司打造价值。

一些人误以为共用条款阻止人们提供维护、支持或专业服务。这是一种对该条款的错误理解。一些人声称，共用条款与 AGPL 有冲突。共用条款旨在与比 AGPL 更宽松的开源许可证一起使用，因此不必使用 AGPL ！不过，即便使用 AGPL，也很少有使用作者开发的软件的产品的人，认为完全无视作者运用共用条款的意向声明是明智的。

保护开源

一些开源利益相关者感到困惑。他们应该站在哪一边呢？共用条款是新的，我们认为有争论也正常。支持这个倡议的人是铁杆的开源倡导者，我们的目的就是保护开源软件所倡导的精神。我们希望其他人能团结起来、支持共用条款，那样开源公司能赚钱，开源能存活下来，开源开发者能为他们的贡献得到报酬。

原文网址：https://techcrunch.com/