从Elasticsearch向左转看开源软件的风险

在16号PG大会的演讲中，有人谈到MYSQL与PG的开源协议之间的优劣。实际上以GPL为代表的左派开源协议与BSD/APACHE代表的右派开源协议，左派强调的是强著作权，对原创著作者的尊重，限制开源软件被过度商业化；而右派强调的是开放，允许商业发展为目标的企业更多的吸取开源社区的营养。两派的诉求都有道理，也无所谓谁好谁坏。不过事实上是大多数基金会主导的开源项目选择了BSD/APACHE等弱著作权的开源协议，而大多数商业企业主导的开源项目更喜欢选择GPL/AGPL这类的强著作权的开源协议。

PG大会结束后回家的路上，老白看到了一则新闻，2021年1月15号，开源领域发生了一件十分重要的事件。ElasticSearch的创始人Shay Banon在公司的官网上发布了一则消息。

这条消息的最主要要表达的意思是Elasticsearch和Kibana要修改开源许可协议了，新的开源协议将从右派的apache 2.0许可转向极左的SSPL许可协议。
对于SSPL（Server Side Public License）许可协议，可能国内的大多数朋友还比较陌生，不过对于国内的云服务商来说，肯定是一看到就惊出一身冷汗的。类似的故事在2018年10月发生过一次，当时Mongodb宣布其开源协议从AGPL V3修改为SSPL，让我们的云服务商大为不爽，随后纷纷下架了mongodb云服务。

可能大家都觉得事情还没那么严重，不就是elasitc修改开源协议吗，有啥大惊小怪的？好吧，存在这种观点的朋友似乎还不太了解啥是SSPL开源协议。这个协议刚刚开始出现的时候，很多开源领域的人甚至都不认同这个协议是一个开源的协议。SSPL协议是从AGPL V3衍生出来的。而AGPL V3是从GPL V3衍生出来的。GPL V3本身相对GPL V2而言，就是一个加强著作方保护的协议，不过还是有一些开源软件的控制者觉得GPL V3中的13号条款对软件著作权的保护还不够，让GPL 协议保护下的开源软件更多的被云服务商拿去当成盈利工具了，必须加以限制，于是AGPL V3协议诞生了，提出了一个新的名词“远程网络交互”。这个远程网络交互相关的13号条款规定，哪怕是云服务商用开源软件提供服务，而不是分发其代码以盈利，也需要开源相关的对开源软件修改部分的代码，这个13号条款的加强目的是为了让云服务商在利用开源软件赚钱的同时也更多的贡献给开源社区。不过AGPL V3的这个条款在实际应用中效果不佳，云服务商很容易就用一些无足轻重的代码来获得了免费使用这些开源代码。而SSPL协议认为AGPL在13号条款上的模糊给了云服务商挑战开源协议底线的武器，因此需要更为强化这一条的限制：

为了更好的理解这段文字，利用谷歌翻译把这段文字翻译成了中文：

SSPL协议要求，如果你把开源软件作为云服务提供，那么你有两个方式可选，第一个是购买其商用许可证，第二个是选择把你的相关软件都开源了。这些软件包含了什么呢？“包含但不限于管理软件、用户界面、应用程序界面、自动化软件、监控软件、备份软件、存储软件和托管软件”。OMG，如果把这个软件放在LINUX上提供服务，是不是得把LINUX也改成SSPL开源协议才行啊？

实际上SSPL协议完全关闭了云服务商将其相关软件修改开源的这道门（因为云服务商不可能把那么多东西都开源，否则云服务商如何提供差异化的服务呢？），从而逼迫云服务商购买商用授权，二选一实际上变成了二选唯一。

大多数选择SSPL协议的开源项目都有两种授权模式，一种是SSPL，另外一种肯定是商用授权，这回elastic采取的也是这种方式。而这回Elastic采用的说辞也和2018年MongoDB的说辞类似，就是云服务商近年来疯狂的挑战AGPL协议的底线，作为对吸血鬼的忍无可忍，Elastic忍痛修改开源协议。实际上当年MongoDB的变更开源协议和其IPO有关，实质上也是商业利益在后面推动，这回Elastic也差不多，作为这个领域没有什么对手的开源项目，也是到了收割韭菜的时候了。
从这件事上，我们应该充分看到开源项目的风险。上回mongodb修改开源协议的时候，大家还没当回事，本身选择AGPL协议的mongodb就是左派，左派变成极左派大家是很容易理解的。而这回叛变的不是左派而是极右派的elasitc，居然一个右派也能变成极左派，真的让人想不到。
实际上，以老白这种喜欢腹黑的人来看待SSPL协议，是这样理解的。作为开源软件控制者的企业，其长久目的是通过开源软件来盈利，而不是做公益事业。因此开源软件，如果企业拿去用，那么没问题，因为这些企业不是这个开源软件厂家的竞争对手。而云服务商则不同了，云服务商免费的获得开源软件，通过云服务大把的赚钱，这样就让这些厂家的商用许可的销售受到了极大的影响，因此是必须打击的。

国内也存在大量的开源软件生态的厂商和云服务商，实际上他们也面临着同样的风险。一旦他们的利益与开源软件控制者之间产生巨大的冲突，那么其风险也会急剧提高，这一点不得不引起关注。前些年老白也和一些云服务商有过深度的交流，他们大多数都在鼓吹一个Opensource As A Service这个概念，完全不需要在开源软件上做什么投入，就可以十分轻松的收割韭菜，用开源软件去赢取利润。在这个生态体系中，永远靠开源社区牟利而不投入真的可行吗？似乎要打一个问号了。而还有很多号称国产化自主研发的企业，也是不断的在开源社区吸血，而对开源社区并没有太大的贡献，这样的事情也是没有问题的吗？

另外一个需要我们考虑的问题是，作为企业我们该如何去选择开源软件，从而避免大的许可证风险。连APACHE开源的项目都能变成SSPL协议，这对于利用APACHE开源项目做“自主创新”软件产品的国内企业，意味着APACHE/BSD系列的开源许可协议也存在巨大的风险。如何识别这种风险呢？

实际上也有一个比较简单的方法，大都数单一企业控制的开源软件,不管开源协议是强著作权型的还是弱著作权型的，都存在开源许可证修改的可能性，当这些企业需要割韭菜的时候是没有太大的障碍的。而没有大企业控制的，或者由基金会控制的开源项目，相对风险就小一些。就像老白在16号PG大会上说的那样，虽然PostgreSQL的BSD开源协议会让大企业吸血，但是不论大小企业，起码都能喝到点汤。

这件事也提醒我们的国产软件厂商，不能只靠着开源软件这个金矿去掘金。基础软件，平台软件的研发还是要真正的自主化，如果都是自主研发的，那么开源社区再怎么折腾，我们都不怕了。

来源：白鳝 https://mp.weixin.qq.com/s/f22W3dUNZ-MgTxi6Vc1SWw