地平线上出现了一片乌云。亚马逊等云基础设施提供商的行为威胁到了开源的生存。
我是一名风险投资者，在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违反了它们公司的政策。
平衡之道
云基础设施提供商不是什么坏人，也不是恶意行事。开源始终是一种平衡之道。我们许多人信任客户和同行查看我们的源代码，进行改进和回馈。别人免费分发其工作产品，并相信你能够有所回馈始终是一种信任的飞跃。有时候对于一些项目而言，无需太刻意的努力，就会自然平衡。但在其他时候，自然平衡并不出现：我们从基础设施开源身上越来越多地看到这一幕，尤其是云基础设施提供商试图通过走向堆栈的上游：从大众化计算和存储走向更高级的基础设施服务，以此实现差异化。
修订
截至本文发稿时的共用条款版本是1.0。将来会进行修订和调整，确保共用条款实现目标。我们想听听你们的意见。
我们看到的迄今为止就共用条款所表达的不同观念实际上是理念上的差异。许多批评来自并不属于用软件来赚钱这个行当的开源人士。他们有不同的理念，但这不足为奇，因为他们的工作是成为政治活动家，而不是为公司打造价值。
一些人误以为共用条款阻止人们提供维护、支持或专业服务。这是一种对该条款的误读。一些人声称，共用条款与AGPL有冲突。共用条款旨在与比AGPL更宽松的开源许可证一起使用，因此不必使用AGPL！不过，即便使用AGPL，也很少有使用作者开发的软件产品的人会认为完全无视作者运用共用条款的意向声明是明智的。
保护开源
一些开源利益相关者感到困惑。他们应该站在哪一边？共用条款是新的，我们认为有争论实属正常。支持这个倡议的人是铁杆的开源倡导者，我们的目的就是保护开源、远离事关生存的威胁。我们希望其他人能团结起来、支持共用条款，那样开源公司能赚钱，开源能存活下来，开源开发者能为他们的贡献得到报酬。
关于共用条款 Commons Clause 的更多介绍请点此查看 https://www.oschina.net/translate/commons-clause
作者：贝恩资本风险投资公司的常务董事Salil Deshpande
来源：云头条 原文：https://techcrunch.com/
