DevOps工具链的「柏林墙」时刻：从Elastic到KubeSphere的闭源铁幕

KubeSphere闭源了!

其实也不奇怪,做了十多年的运维方面工作，最近几年那些曾经让我们这些行业小伙伴引以为傲的开源工具，正在一个接一个地改变游戏规则。从Elasticsearch到Redis，从Terraform到Grafana，这些工具要么修改许可协议，要么干脆走向商业闭源。

聊到Elasticsearch，还记得2021年那个消息传出来时，大家都挺不可置信的。那时候的我心里还有着那份理,也要写出来一个类似的开源项目,结果这个用了好多年的日志分析神器，突然从Apache 2.0改成了SSPL和Elastic License 2.0的双许可模式。

记得他们的解释是，AWS这些云厂商拿他们的开源代码做托管服务赚钱，还不给社区任何回馈. 我开个毛线呢?我这不成傻小子了么.

那AWS是不是这么干的呢?还真是,AWS在自己的云平台就用原装的开源的Elasticsearch提供日志服务,而且价格不菲.

妥妥的就一个大流氓子! 流氓是行为,流氓是动作,流氓是职业.是职业就要有职业操守和职业道德.

AWS是有职业道德的!

很快AWS推出了OpenSearch这个分支项目，基本上就是从Elasticsearch 7.10版本fork出来的. 他开源了. 咱有一说一啊,就这个行为在中国叫chusheng,翻译成英文叫animal 妥妥的big animal

Elastic像个受气的小媳妇,哭的梨花带雨.就好比自己一个寡妇,就这么一个宝贝儿子,被地主拐走了,免费给人家当长工,自己要回来之后,却被同村的大骂没有公德心.自私.

你儿子?那是你儿子么?那是大家的儿子!但是你儿子吃饭,上学的费用啥的你别找我啊.那是你们家的事,但是我们要收庄稼的时候你儿子得来,还得免费帮我干活.

里外受气的Elastic受不了A大地主和同村村民的指责在2024年9月又宣布支持AGPLv3许可

其实就是证明自己其实是好人,只是不想当傻子而已

说完寡妇Elasticsearch,咱们再看看隔壁的Grafana大娘

她就比较聪明。它在2021年从Apache 2.0改为AGPLv3，这个许可证至少还是OSI认可的开源协议。但AGPLv3有个特点，就是如果你修改了代码并以服务形式提供给别人使用，必须把修改的代码也开源出来。对大部分企业内部使用来说影响不大，但如果要做商业化服务就得小心了。

要说最让人意外的，还得是Terraform。HashiCorp在2023年8月突然宣布，Terraform从MPL 2.0改为BSL许可证。

啥是BSL许可证?

它允许你下载、修改、再分发代码，但不能用来提供竞争性的商业服务。听起来似乎对企业内部使用没影响，但谁知道以后会不会有其他限制呢？

不过开源社区的反应很快，Linux基金会支持的OpenTofu项目几乎立刻就出现了。AWS、华为这些大厂也都表态支持OpenTofu。

为什么大流氓、不对是大厂支持?因为他们要用来赚钱!

但也有被开源社区成功反噬的大厂的案例,比如当年Oracle收购MySQL时，MariaDB的出现就是类似的社区响应。

那开源社区就拿大厂一点办法没有么? 还真有,这里就要特别说明的SSPL许可 它代表了当前开源许可证演进的一个重要方向

SSPL是MongoDB在2018年创造的一个许可证模式，后来被Elastic、Graylog等公司采用。它的核心机制是通过第13条款实现的，这一条款规定：如果你将采用SSPL许可的软件作为服务提供给第三方，那么你必须在相同的许可证下提供服务的所有源代码，包括管理接口、用户界面、API、以及运行该服务所需的所有其他软件的源代码。

比如说，如果大流氓想要提供基于Elasticsearch的托管服务，按照SSPL的要求，他们不仅要开源Elasticsearch相关的修改，还要开源整个服务平台的代码——包括负载均衡器、监控系统、计费系统，甚至可能包括数据中心管理软件。 从技术架构角度看，SSPL实际上是通过极端的开源要求来阻止云厂商的商业化使用。它利用了现代云服务的一个特点：任何一个云服务都不是独立存在的，而是整个平台生态的一部分。SSPL巧妙地利用了这种技术依赖关系，让云厂商在法律上无法合规地使用这些软件。

这个是啥意思?就好比你想把天然的水池圈起来当收费的泳池,那好,你家别墅的院墙也得拆了让人随便进.你家卧室也不允许锁门奥.谁都可以在里面睡觉. 要么你就别打这个主意.

一些老牌的配置管理工具比如Chef、Puppet、Ansible目前为止倒是没有掺和哪些破事中,只能说目前为大部分还保持开源，只是在企业版功能上有所区别。 SaltStack被VMware收购后也还算稳定，不过感觉社区活跃度确实有所下降

CI/CD呢?

Jenkins作为老牌开源工具依然坚持MIT许可

GitLab的策略挺聪明的，社区版保持MIT开源，企业版功能闭源。这样既保持了开源形象，又能通过企业版盈利。

最后评价,KubeSphere闭源是好事,是大势所趋.开源是走不远也走不长的. 就一个句话,无利不起早. 但是开源彻底转商业化还有个过程,比如:核心功能开源，高级功能闭源。也可能会有更多项目采用类似SSPL这样的限制性许可证。 支持正版和商业付费的理念,不要看到什么好第一时间就去找什么破解版.剜门盗洞的看盗版.浪费宝贵的时间不说,还磕磕绊绊的,然后感叹这个世界都在处处与你作对. 没必要,放轻松.付费其实就是我们最大的底气.我们花钱了!我骂你咋地?

开源许可说明和举例

老杨时间

这里我先声明一下,日常生活中大家都叫我波哥,跟辈分没关系,主要是岁数大了.就一个代称而已. 我的00后小同事我喊都是带哥的.张哥,李哥的. 但是这个称呼呀,在线下参加一些活动时.金主爸爸也这么叫就显的不太合适. 比如上次某集团策划总监,公司开大会来一句:“今个咱高兴!有请IT运维技术圈的波哥讲两句“ 这个氛围配这个称呼在互联网这行来讲就有点对不齐! 每次遇到这个情况我就想这么接话: “遇到各位是缘分,承蒙厚爱,啥也别说了,都在酒里了.我干了,你们随意!” 所以以后咱们改叫老杨,即市井又低调.还挺亲切,我觉得挺好.

另外最近我还推出了一个运维X档案系列的付费文章, 这些文章老杨使劲了,是真使劲了. 这些文章都是根据一个个鲜活的真实事件还原回来的. 有人会问这些事件记录哪来的? 部分我经历的,部分我换来的.极少部分我顺来的. 从业10多年,亲自设计和处理多少项目我自己都数不清了.不过每个大事件我都有记录的习惯.不是爱记录,就是单纯的记性不好,我的一个设计文档最大的能有13000字左右. 那剩下那部分呢? 当年我还是个技术狂热爱好者,单身没对象,这是重点. 没事周末就跟一帮同行搞线下技术沙龙,五湖四海,哪的都有.大家都自己的得意之作的案例上去显摆.

郭德纲讲的那段西游记有印象么?一样一样的. 一场我就能收集几份,每周一场,每场必到.从硬件到网络,从架构设计、流程和岗位职责的理解到机房建设啥都有.全方位学习

极少那部分呢?还记得郭德纲那个西游记么?那几个蟠桃被偷了.差不多那意思吧.毕竟谁也挡不住一个爱学的小伙子渴望上进的心是吧,知识么,对吧,强行交换过来.

这些东西到什么时候都不过时.因为每一个事件不光是命令,更多的是思路和方法. 人真正的成长是思维的成长,是用过一件又一件事锻炼思维的. 技术、生活、做人都是相通的. 不会做,做错了其实都不是事,但是老是想错了.或者根本没想法.这就有点麻烦了. 每篇文章我都尽量还原所有细节.毕竟我记得全. 尽量让读者能把自己带入进去,跟着我一起想.这样,让你有最深的印象.而不是读完看完就拉到了. 感兴趣的可以订阅购买一篇试试.也就一杯咖啡的钱,买不了吃亏买不了上当.但是哪怕有一丁点的收获,在未来的某个点用上了,那这价值就不可估量了. 比如你深入研究之后转化一下,去面试的时候人家说你处理过什么问题呀?你就把这个故事给他讲一遍.要是镇不住面试官你回来找我. 把老杨的经历拿走,变成你的,即少走弯路也结善缘! 老杨这么大岁数了还在学习和成长,也在不断的调整自己.一起努力吧! 即写给你们,也写给自己.

运维X档案系列文章:

从告警到CTO：一个P0故障的11小时生死时速

老杨的另一号