为什么呢?开源厂商与云厂商打架,受伤的却是软件厂商和最终用户

 admin   2020-06-20 06:45   465 人阅读  0 条评论

这篇文章之前已经写了大半,打算趁周末的时间把剩余的内容写掉。没想到,周四(12月14日)就爆出了另外一个新闻,Confluent的CEO Jay Kreps宣布更改部分产品协议。

和其他几家公司类似,Confluent只是将部分组件的协议从Apache2.0改成了Confluent自己的社区许可,比如去年8月份发布的流式SQL组件KSQL就是个例子(忍不住想说KSQL去年8月才发布,比Slipstream至少慢了1-2年)。Jay在长长的blog中声情并茂的讲述了创业史,明确强调公司业绩很好,所以不是因为钱的原因,实在是因为这个世界变化太快,云厂商欺人太甚。所以不得不改变协议。但是那些用产品的用户不用担心,你们不受影响。

有兴趣的可以去Confluent官网看原文。比其他几家写的生动多了。

https://www.confluent.io/blog/license-changes-confluent-platform


这已经是今年第四起因为diss云厂商而改变开源产品license的事件了。




我们再回顾下之前的其他几家新闻:


第一家:Redis

8月份,Redis进行了大调整。Redis基于BSD许可开源,但是Redis模块,如Redis Labs负责的部分模块如Redis Search, Redis Graph, ReJSON, ReBloom遵守Apache2.0和Common Clause协议。Redis企业版闭源。

协议地址:

https://redislabs.com/community/licenses/


Common Clause协议写的很明确,完全遵守开源协议,但是唯独就是对软件销售进行了限制。

其中关于为什么不采用AGPL协议的原因,也说得很清楚了,就是因为云厂商!

不管是Commons Clause协议的特点,还是不采用AGPL的原因,都是大写的五个字:“不希望被云厂商用来赚钱”。

甚至Redis Lab的联合创始人兼CEO Yiftach Shoolman说这样做的两个原因之一是限制像AWS这样的云厂商利用Redis来获利。相当石锤了。




第二家 MongoDB

10月17日,面向文档的开源数据库MongoDB宣布,从 GNU  AGPL v3 改成了 SSPL(Server Side Public License )。根据AGPL协议,使用MongoDB的厂商,要么开源其代码,要么购买MongoDB商业版的授权,但很多厂商并未如此,特别是云厂商。MongoDB的CEO Dev Ittycheria在接受采访时点名批评了阿里云和腾讯云。




第三家 Neo4j

11月15日,图数据库厂商Neo4j宣布,从3.5版本开始企业版不再在Github提供开源代码下载。社区版将继续在GPL v3许可下开源。其实这之前已有预兆。早在今年5月份,企业版的许可已经变更为AGPL v3 + Commons Clause双重许可。

另外Philip Rathle强调这次的变化原因之一是避免云提供商只从开源中获益而不为这些项目做贡献,影响了开源项目的健康发展




从这四份声明中可以看到,除了Redis略为克制外,其他三家都是CEO/VP实名批评。可谓是真的很生气了,不吐不快。


而调整License的原因都是因为云厂商只受益(赚钱)没有(经济)贡献(云厂商对开源社区本身还是不断的砸钱砸代码的,只是对产品本身......emmm,所以不能说完全没有贡献,只能说屁股决定脑袋)。所以不好意思,我们要调整License了,就是不希望你们再这样只吃肉,连汤都不分我们一口的行为继续下去。


调整License的同时,四家厂商又再次强调,如果你是用户,那么不要紧。这事跟你没关系。继续放心大胆的用,我们只是跟以云厂商为代表的用我们产品赚钱但不分我们收益的公司算账




顺便说下,3月份的时候ElasticSearch CEO Shay Banon在演讲中宣布了X-pack的事情。

公司声明可以看这里:

https://www.elastic.co/products/x-pack/open

油管上可以看到视频

https://www.youtube.com/watch?v=gR3OhOnCMf8

从License的变化可以看出,所谓的x-pack open source,其实是ES在加强商业化。在网页的Q&A里面,说的就更加直白了:

翻译过来:

问:如果X-pack的代码是开放的,是不是意味着它都是免费的?

答:。X-pack里的一些功能是免费的,如监控...但是另外一些功能是需要付费的,如金卡订阅用户或者白金订阅用户里面包含了这些付费权益。


我们再直白点翻译:有些好东西我们收起来只给那些付钱的用户。至于免费用户,你们就自力更生吧,反正代码都给你们了,还想怎样




回过头来看,这些开源厂商不约而同进行了License转变,大部分原因是因为云厂商。他们也不希望开源厂商和云厂商之间的纷争影响到生态圈里的最终用户,部分开源厂商完全不能容忍自己的产品被其他公司包装后用来卖钱,还有部分开源厂商可以容忍上下游的厂商打包自己的产品,但是前提是和自己的产品不形成竞争


虽然开源厂商一直强调对最终用户不影响,然而是真的不影响了吗?


我们都知道蝴蝶效应的故事。


国内的现状大家心里都很明白。大部分公司是在做应用,做操作系统和数据库的很少,这里面真正做原创的就更少。利用开源产品并提供服务是不少厂商应对简单的需求处理方式。除了部分行业用户既有着充足的预算,也有着充足的技术人员储备,IT部门可以自行利用开源产品进行定制化开发,其他很多用户是没办法完全依赖自己的IT部门从0开始把开源代码开发成自己需要的产品,这是个费时、费力、费钱的活,而且还可能失败且不说能不能招到合适的技术团队,时间成本、开发成本、后续维护成本不见得比购买商业产品来的低。所以这也是商业产品厂商存在的原因。


在之前,License上没有这么多限制,开源厂商也就睁一只眼闭一只眼。没想到云厂商玩的太溜了,开源厂商不得不进行调整。

云厂商时间、金钱、人才储备都没问题,不管通过什么样的方式,总是可以攒一套自己的产品出来规避合规风险(怎么攒?请自行想象)。


那么那些非云的厂商呢?如果之前所有的产品储备都是基于开源,那么License的修改,对他们而言就是:

往前一步是不合规,往后一步是缺钱缺时间缺人手

知识产权带来的风险可能是会导致公司长期的打官司、赔钱、甚至是公司倒闭。比如最近的高通和苹果之间的纷争,限制苹果在国内销售。美国厂商对知识产权的重视程度从来都很高。

往后一步自行开发?如果这么容易的话,我们国家根本就不用强调“掌握核心技术”了。但是对于那些有真材实料的厂商,也许这是个机会

如果这些非云的厂商选择合规,不再出售这类产品,那么前面说到那些技术实力不够强的客户怎么办?购买开源厂商的订阅服务?语言、时差、远距离支持的困难这些小问题都不说了,光是产品没法百分百适应国内用户应用这条,杀N个程序员祭天也没办法解决。


以上内容仅代表个人观点,与任职公司无关。


后续:

凌晨写好文章,把预览发给我的技术宅好朋友咖啡猫。

他:最后结论的两段不够深入

我:没错,你当做我深夜写作写困了。但是你看明白了吗?

他:这个就像开源的openwrt系统,国内厂商拿来以后修改了,但是不开源

我:对。这是一个点

他:需要掌握核心技术

我:既然你能get到,那我就不修改了




关于SSPL

SSPL构建在AGPL之上,但是明确要求任何试图使用该产品的组织,都必须将其使用该服务的软件代码开源。


关于Common Clause

不允许使用者销售基于其开发的软件产品,也不允许为包含有它的产品提供咨询或支持等服务。

本文地址:http://ruanzu.com/post/407.html
版权声明:本文为原创文章,版权归 admin 所有,欢迎分享本文,转载请保留出处!

 发表评论


表情

还没有留言,还不快点抢沙发?