如果红帽软件终将改变,那么我们只能做到,不改变开源的初心
摘要:除了必要的商业产品,红帽软件不生产开源软件,它是开源软件的搬运工,向世界提供了一种构建开源软件的最优组合。红帽变更软件源策没有违背开源精神,符合 GPL 开源许可证要求。人们抱怨的是失去免费获取构建开源软件最优组合的「菜谱」,毕竟「巧妇难为无米之炊」。
6 月 21 日,红帽软件宣布将 CentOS Stream 的源码发布到 git.centos.org,而 Red Hat Enterprise Linux(简称 RHEL)的源代码则面向红帽软件订阅用户开放,订阅用户可以通过 Red Hat Customer Portal 访问,但是无法进行二次分发,红帽软件又变了。
人们的抱怨也来自于这种变化:抱怨红帽软件太过绝情,构建生态时「你好我好大家好」,但是只用了两年的时间,就完成了从操作系统到软件源的全面转变;抱怨红帽软件提供的开源软件最优组合「菜谱」即将消失,「巧妇难为无米之炊」。
我们应该如何看待这种变化?
首先,云计算时代,容器才是最值得关注的基础设施,CentOS 无法为红帽软件继续提供商业价值,无继续维护的必要。这不仅是基础设施载体的变化,而是整个协作方式的变化。红帽软件的 OpenShift 基于开源软件构建,但是面向社区和开发者免费提供的是二进制版本。它还是会使用开源软件、贡献开源软件,但是最终构建的产品将不再是开源软件。
CentOS 更新策略变更的这两年,是红帽软件给使用 CentOS 企业的一个缓冲期,红帽软件希望企业能够使用操作系统迁移工具,将业务从 CentOS 迁移到 RHEL 之上。salesforce 响应了这个号召,完成了 20 万套 CentOS 向 RHEL9 的迁移。这次软件源变更,可以看作红帽软件对使用CentOS 企业的最后通牒。
至于 CentOS 的未来,CentOS 在红帽软件没有未来,它只会被红帽软件废弃。容器时代,红帽软件希望用户的业务都是运行在 RHEL 之上,而不是CentOS 或者兼容 CentOS 的 Linux 之上。
CentOS 更新策略变更后,企业的选择无非就四种:使用 CentOS Stream、寻找兼容的 CentOS 代替品、购买 RHEL、购买其他企业级 Linux 发行版;RHEL 软件源获取策略变更后,企业的选择只有两种:购买 RHEL、购买其他企业级 Linux 发行版。考虑到红帽软件的生态粘性,多数企业应该会选择 RHEL。
这次红帽软件把 RHEL 源码缩小到了订阅用户范围,也就是企业用户。为什么?因为企业的需求更纯粹,它们需要的是一个开源的、稳定的企业级 Linux;需要的是一个软件、硬件生态丰富的企业级 Linux。这几句描述的就是 RHEL。至于RHEL源码是否可以获得,这是非订阅用户考虑的问题。后续的新硬件和软件如何适配?答案是只要 RHEL 的企业用户足够多,市场份额足够大,用户需求足够强烈,RHEL 的生态引力就能够驱使新的硬件和软件来适配 RHEL,而这些硬件和软件背后,还是企业,他们也可以成为 RHEL 的订阅用户,进而可以获得 RHEL 的源码。红帽软件用订阅用户获取源码这个思路,圈出来了一批核心的用户和开发者,这个群体的开发的软件和硬件,与 RHEL 原生适配,符合上文提到的「红帽软件希望用户的所有业务都是运行在 RHEL 之上」的这个目标,这将是红帽软件未来的商业模式。
其次,这种商业模式是否违反了 GPL 开源许可证的要求?答案是没有。这得益于红帽软件精巧的许可协议设计。首先,订阅用户获取源码符合开源软件「允许收取不超过软件成本的价格获取源代码」的要求,所以没有违反。其次,GPL 只规定源码要开放,对于开放的人群大小并没有规定,所以没有违反。那么订阅用户不允许二次分发代码是否违反了 GPL 开源许可证了吗?答案是没有。我看了一下红帽软件企业许可协议中的条款,大体意思是:红帽软件有权按照许可协议规定的相关要求,检查订阅用户是否合理使用 RHEL,如果出现不合规的情况,订阅用户要在15 个工作日内完成整改,否则会进行罚款,如果订阅用户的欠款超过了总欠款的 5%,红帽软件负责审查的费用就该订阅用户支付。这个合理使用指的是,不包含违反相关保密性的协议条款。两者结合一下,如果不合理使用,例如将源码二次发布,那么只需要向红帽软件交罚款就可以了,也是一种另类的「付费获取源码」的方式。
禁止分发源代码是写在许可协议中的,如果你分发了源代码,那你行使了GPL赋予你的权利,但是违反了许可协议的要求。你确实拿到了源码,分发了源码,而红帽软件也确实可以根据许可协议,停止对你提供订阅服务。这时候,你手里的代码,将会毫无价值。
最后,破解上游软件源变更风险最好的方式,就是敢于与 CentOS 不兼容,既要绕过红帽软件这个「捷径」,完全脱离红帽软件的构建的生态引力,社区或企业直接对接发布软件的根社区,又要学习红帽软件编写 spec 文件的经验,社区开发者自行编写 spec 文件,并完成后续的软件包构建,测试、发布、维护等环节,自行找出属于自己的开源软件最优组合「菜谱」。做好这件事儿并不简单,因为 CentOS 的软件包数量超 30000 个,软件包具有非常明显的「长尾效应」,需要开源社区拥有长远的战略眼光、较强的技术实力、众多的人力投入和雄厚的资金支撑。