红帽对 RHEL 下游造成毁灭性打击！停止公开企业版源代码后，红帽回应：没有找到重构 RHEL 的价值

当地时间 6 月 21 日，红帽发布公告称，停止向第三方提供 RHEL 源代码，CentOS Stream 将成为公共 RHEL 相关源代码发布的唯一仓库。红帽的客户和合作伙伴可以付费获得源代码，但无权二次发布这些代码。

“在 CentOS Stream 之前，Red Hat 将 RHEL 的公共资源推送到 git.centos.org 上。当 CentOS 项目转移到 CentOS Stream 上时，即使 CentOS Linux 不再是 RHEL 的下游构建，我们仍然维护这些存储库。CentOS Stream 的参与、投资的工程水平以及我们为客户和合作伙伴解决问题的新优先级，使得现在维护独立、冗余、存储库的效率低下。”红帽核心平台副总裁 Mike McGrath 在公告中表示。

红帽的这一决定将影响 Red Hat Enterprise Linux（RHEL）的所有重建和分支，（例如AlmaLinux、Rocky Linux、EuroLinux 和 Oracle Unbreakable Linux），这些项目都依赖已发布的源代码。在无法访问所使用的源代码的情况下，保持与现有版本的 1:1 二进制兼容性会是很大的挑战。

目前，各种线上论坛的下游发行版用户正在强烈抗议，气势不输几年前红帽宣布取消 CentOS Linux 之时，最常见的字眼包括“背信弃义”、“违反 GPL”等等。“红帽做的事情很糟糕，但微软、IBM 和在后台运作的公司之间一直存在着一场更大的战斗。这是一个丑陋的局面，自由软件和开源被夹在中间。”有网友说道。

为了 Stream？

2020 年底，红帽宣布停更 CentOS 8 后，CentOS Stream 成了 CentOS 的替代品。在 Linux 生态中，一般认为 Fedora 是中上游，CentOS Stream 是中游，RHEL 是下游。

RHEL 是基于 Fedora 某个特定版本拉取分支，逐渐在这个版本上做增强，保证新旧版本之间的兼容性，并保证最终版本的稳定性。CentOS Stream 则与 RHEL 的版本相对应，其 Git 提交记录完全一致，二者通过同样的构建流程、同样的测试用例。但 CentOS Stream 永远只对应 RHEL 最新的稳定版。只有通过全部的测试用例，CentOS Stream 新版本才会发布，这些测试用例与 RHEL 可能重合，也可能不重合。

红帽决定停止向公众提供 RHEL 源代码，这个变化的区别在于：CentOS Stream 又是 RHEL 的上游，又代表着 RHEL 下个版本的发展方向。从这个角度看，红帽相当于把公布 RHEL 源代码调整为滚动发布 RHEL 的 beta 版代码。

而 Alma、Rocky 以及之前的 CentOS Linux 都属于 RHEL 的下游：使用同样的源代码重构而成以保证完美兼容。原本的业务基础，就是无需向红帽支付任何费用即可进行重构，使用相同的驱动程序并实现与 RHEL 应用程序间的完美兼容。

但单纯开放 CentOS Stream 显然做不到这一点：它只是 RHEL 的未来预览版。如果企业希望在 RHEL 上开发产品或驱动程序，又或者想要提前把握 RHEL 的后续发展方向，那 CentOS Stream 倒是基本够用。但如果只想免费运行 RHEL，则开放 CentOS Stream 可以说意义不大，更遑论构建自己的 RHEL 变体了。

有媒体怀疑，红帽很清楚 RHEL 社区的用户其实并不关注 Stream，这也正是此次调整想要达到的效果。

Fedora 会不会受到影响？

Fedora 的用户和贡献者们倒是不必担心，但 Fedora-Devel 邮件列表中也透露出了严重的不满情绪。

Fedora 位于 RHEL 的上游：在 Fedora 中开发和测试的软件会先流入 CentOS Stream，之后再进驻 RHEL。实际上，Fedora 的大部分工作都是由 RHEL 完成的。如果说 CentOS Stream 就是 RHEL 的滚动 beta 版，那么 Fedora 就是 RHEL 的滚动 alpha 版。所以是 RHEL 在技术上依赖于 Fedora，而非 Fedora 依赖于 RHEL。原则上，Fedora 仅仅是在经济层面倚仗 RHEL 的支持。

Fedora 还提供服务器版本，需要免费 RHEL 的红帽用户可以随意使用这些版本。最大的区别就是，Fedora 始终基于较新的代码，所以与当前 RHEL 永远不会完全兼容。另外，Fedora 也不提供稳定的长期支持版本。

下游发行商：乐观但不掩担忧

目前，Alma Linux 和 Rocky Linux 的官方反应都表示谨慎乐观。

“虽然这个决定确实改变了我们用于构建 Rocky Linux 的自动化，但我们已经创建了一个短期的缓解措施，并正在制定长期的策略。对于任何不稳定的 Linux 用户、合作者或合作伙伴来说，不会有任何干扰或改变。”Rocky Linux官方表示。

“我相信开源应该始终免费且完全稳定。它不应该隐藏在付费专区后面，也不应该由一家公司控制。”Rocky Linux 项目的创始人、该项目的主办方 Rocky Enterprise Software Foundation 董事会主席 Gregory Kurtzer 表示。

Alma Linux官方则表示，“短期内，我们将与 RHEL 生态系统的其他成员合作，确保我们继续以众所周知的速度和稳定性提供安全更新。从长远来看，我们将与这些合作伙伴以及我们的社区合作，确保 AlmaLinux 作为企业 Linux 生态系统一部分的最佳前进道路。”

AlmaLinux 用户仍然可以获得该操作系统服务器的安全更新。短期内， AlmaLinux 计划停止 CentOS Stream 更新和 Oracle Linux 更新，以确保继续发布安全补丁。这些更新将经过精心策划，以确保它们与 RHEL 1:1 兼容，同时不违反红帽的许可，并将像所有其他版本一样进行审查和测试。

但是， AlmaLinux 的论坛帖子则弥漫着担忧的情绪：“这对整个红帽生态系统造成破坏。”AlmaLinux 表示，在 AlmaLinux 操作系统的整个生命周期中，其与红帽建立了令人难以置信的合作关系，他们希望这种关系可以继续下去。

“我们并不惊慌，因为我们使用 AlmaLinux，而且你们从多年前就开始认真对待你们的产品（Cloud Linux）。我不怕。”在 AlmaLinux 安抚社区的推文下有支持者如是说道。

早在 2011 年，红帽就调整过源代码包的分发方式，看起来就是专门给重构工作“挖坑”。但当时的举措并不成功，实际上只导致越来越多企业开始拥抱 CentOS。

有媒体在 CentOS Stream 9 发布时就曾断言，红帽犯下的最大错误就是力推 CentOS Linux。此举相当于支持了跟自家付费商业产品竞争的免费方案，属于典型的“资敌”行为。这项计划不仅没能给甲骨文带来多大阻力，反而显著削减了 RHEL 的销售额。

当时，下游发行商也找到了绕过限制的方法，而且规避的思路并不复杂。红帽恐怕也对新生代重构厂商的崛起感到了不安。

虽然 Rocky 和 Alma Linux 背后的机构都属于非营利组织（Rocky 来自由 Greg Kurtzer 创立并运营的公益企业），但有一说一，这两家的表现确实不错。就在上周，NASA 授权在内部使用 Rocky Linux；CERN 和 Fermilab 等科研机构则选择使用 Alma Linux。

红帽倒是认为这些并不是什么大事，似乎都是在为自己的 Stream 市场普及率做贡献。但从实际效果来看，红帽在 CentOS Linux 被取消之后，一刻也没有放松对蓬勃发展的重构生态发起攻击。

难以获得源代码

目前开源之门还没有彻底关闭。预计每当有新的主要版本即将发布时，Stream 都会定期与 RHEL 对齐同步。就是说当 RHEL 11.0 发布时，Stream 将暂时与其保持同步，而下游发行版也能在相应的时间点获取代码副本，并构建起与 RHEL 大版本相兼容的产品。但目前下游生态面临的最大挑战是在各个主要版本之间，他们再无法获得源代码层面的小规模迭代和更新。

有评论人士指出，用户可以注册免费红帽开发者账户，借此合法获取源代码。说得没错，但问题是大家需要签名同意才能获取账户，而许可协议中明确禁止对软件的重新分发。所以，哪怕下游发行版仍能获得软件源代码，实际上也无法拿来使用。虽然原则上可以做出实质性修改，再把修改后的结果共享出去，但 RHEL 兼容发行版能够存在的核心意义，就是避免大幅变更、保留“完美兼容性”。

当然，下游发行商也可以选择“挨骂也要搞”的态度，硬着头皮继续推出自己的版本。而红帽一旦发现，至少也会立即封禁其订阅权限和账户。这必然掀起一场“猫鼠游戏”：下游发行商不断开设新的免费开发者账户，而红帽则通过跟踪和封禁违规者账户的方式予以还击。这显然不是什么可以长期持续的发展模式。至于最差的结果，发行商甚至可能面临起诉并就此消失。

总而言之，获取源代码的途径并不能说没有，只是大部分受到非常严格地限制和管控。

遏制社区发展，转为企业利润？

虽然社区反映强烈，但单从事件本身分析，红帽的行为其实完全符合 GPL 条款，毕竟条款只要求向使用所构建二进制文件的群体提供源代码：换句话说，向付费客户群体提供源代码。关键在于要获取这些二进制文件，客户及免费账户的开发人员必须同意许可协议并遵守合同条款，而合同条款的优先级要高于代码所遵循的 GPL 许可证。

从某种程度来讲，此举可以说是红帽公司 2014 年将 CentOS 收归专有这条逻辑线的延续。此项举措将收窄合法空间，仅留 CentOS Stream 一根“独苗”，其余重构项目将基本没有发展的可能。当然甲骨文除外，其拥有雄厚的资金继续支撑 Oracle Linux，同时也能提供更便宜的企业支持合同、增强的 Btrfs 兼容内核等。

外媒评价道，红帽的这一套组合拳已经打得相当熟练，在逐步干掉大部分克隆产品之后，他们应该会故伎重施、取消自家旗舰产品的官方免费版本。作为配合，红帽会提供免费 beta 版本，并在发布公告上大谈“这是为了鼓励社区参与”等看似积极的话语。但事实上，红帽真正想打击的其实是那波所谓“贪图便宜”的家伙。毕竟开发人员仍可以免费使用 RHEL 进行生产部署，只是最多仅可支持 16 台设备。

如果此举最终导致 Alma 和 Rocky 等下游生态投入数年建立的企业和社区走向消亡，那么相应的市场空间可能会转化为 IBM 的利润，但也意味着公众舆论将对蓝色巨人猛烈开炮。

自 30 年前成立以来，红帽就一直允许下游生态对其操作系统进行克隆和重构，就连早期 Red Hat Linux 也不例外。例如，Mandrake Linux 就是由此起步，向 Red Hat Linux 引入了 KDE 桌面。当时红帽以违反 Qt 许可证为由，一举消灭了这股社区力量。除了 IBM 的股东，其他各方显然都不会认可这样的粗暴行径。

红帽回应

当时时间 6 月 26 日，红帽核心平台副总裁 Mike McGrath针对舆论发文回应称，红帽一直并始终向上游发送代码，遵守产品使用的开源许可证，其中包括 GPL。红帽没有找到重新构建 RHEL 的价值，并且没有义务让重新构建者的工作更加容易。以下为回应全文：

上周末，我花了很多时间思考业界对我上一篇博客的反应。有人称我们是邪恶的；有人称我是被安插进来将红帽变成闭源的 IBM 高管——这还只是其中较“友善”的说法。下面，有一些事情我们想澄清下。

我叫 Mike McGrath，是红帽核心平台工程副总裁。我在红帽工作已有 16 年了，在加入红帽之前，我是 Fedora 项目的志愿者。开源，以及和开源相关的所有事，对我来说非常重要。过去一周，我看到很多人对我们辛勤工作的红帽员工说了很多不友善和不实的话，这些员工和我一样，非常看重我们所做工作的核心价值。

尽管目前有关红帽的言论不一，但我们一直确保我们的辛勤工作成果对非客户也是可获得的。红帽采用并将一直采用开源开发模式。当我们发现一个漏洞或编写一个新功能时，我们会向上游贡献我们的代码。这不仅造福红帽和我们的客户，也让社区中的每个人受益。

我们不是简单地拿来上游软件包并进行重建。在红帽，成千上万的人花费时间编写代码，实现新功能、修复漏洞、集成不同的软件包，然后长期提供支持服务——这些是我们的客户和合作伙伴所需要的。

这意味着我们花费了大量时间和无数个夜晚，将补丁反向移植到距现在已经有 5 到 10 年，甚至更久历史的代码上；无论何时，我们都在同时为 3-4 个主要版本流提供支持，同时对所有版本提供补丁和反向移植。此外，当我们为 RHEL 中的问题开发修复补丁时，我们不仅仅将其应用于 RHEL——首先是应用于上游项目，例如 Fedora、CentOS Stream 或内核项目本身，然后再进行反向移植。维护和支持一个操作系统长达 10 年是一项艰巨的任务——我们所做的工作有着巨大的价值。

我们一直并始终向上游发送我们的代码，遵守我们产品使用的开源许可证，其中包括 GPL。当我说我们遵守适用于我们代码的各种开源许可证时，我说的是事实。有那么多的人对开源软件和 GPL 产生如此多的误解，我感到震惊和失望，特别是行业观察者和那些即使是经验丰富的人，我认为他们应该更清楚事实的真相。细节，包括开源许可证和权利是很重要的，这些东西是红帽帮助形成的，也是红帽需要保护和发展的。

针对最近我们作出的围绕下游源代码的决定引起的愤怒，我感到这些愤怒情绪要么来自于那些不愿为生产红帽企业 Linux 需要付出的时间、精力和资源付费的人，要么来自那些因为自己的利益而想要重新打包它的人。这些对 RHEL 代码的需求是不诚实的。

那些在漫长的时间和夜晚中辛勤工作、相信开源价值观的热情贡献者，我们必须为他们的付出给予回报。将这些贡献者生产的代码仅仅拿来只是简单地重新打包，并进行原样转售，没有增加任何的价值，还让开源软件的生产变得不可持续。红帽提供的价值包括关键的反向移植工作，以及在上游进行开发的未来功能和技术。如果开源软件的生产方式变得不可持续，这些都将停止，对任何人都不利。

我想特别提到重新构建者，他们与那些可能添加新的架构或编译标志的发行版不同（我们完全支持您扩展 Linux 的功能，而不是模仿这些功能）。

不久之前，红帽发现（例如 CentOS）重新构建者的工作具有价值。于是我们将 SRPM 包（源码包）推送到 git.centos.org，让他们可以轻松重新构建；我们甚至为他们去除了品牌标识。最近，我们已经认识到，拥有下游重新构建者没有价值。

曾经普遍认可的观点是，这些免费的重建版本只是为了培养 RHEL 专家，而并非是为了销售。我希望我们能够生活在那个世界，但现实并非如此。相反地，我们发现了一批用户，其中许多来自大型或超大型的 IT 组织，他们希望获得 RHEL 的稳定性、生命周期和硬件生态系统，而无需实际支持维护者、工程师、文档编写者和其他更多角色的 RHEL 的创造者。这些用户也决定不选择其他众多商业 Linux 发行版中的任何一个。

在一个健康的开源生态系统中，竞争和创新是相辅相成的。红帽、SUSE、Canonical、AWS 和微软都创建了与之相关的 Linux 发行版，并进行了品牌推广和生态系统开发工作。这些变体都使用并贡献 Linux 源代码，但没有一个声称与其他发行版“完全兼容”。

最终，我们没有找到重新构建 RHEL 的价值，并且我们没有义务让重新构建者的工作更加容易；这是我们的呼吁。当我们推出 CentOS Stream，大家对它的存在感到困惑。我承认，这个决定改变了长期以来的传统做法，这种改变可能会引起一些困惑。这表现在指责我们“闭源”了，“违背”GPL 协议。有 CentOS Stream 二进制可执行文件；就有对应的源代码库。CentOS Stream 的位于 GitLab 的源代码仓库就是我们构建 RHEL 发布版的地方，对所有人都是公开的。称 RHEL 为“闭源”是绝对不真实且不准确的。CentOS Stream 的更新速度比 RHEL 快，RHEL 虽不一定指向最新代码，但代码就是在那里的。如果你找不到它，那就是个 bug，请告诉我们。

我们还提供免费的红帽开发者订阅和用于开源基础设施的 RHEL for Open Source Infrastructure。开发者订阅为开发人员提供免费的 RHEL，并可在最多 16 个系统上使用，再次强调，这是免费的。个人可以将其用于自己的工作，而 RHEL 的客户则可将其用于员工的工作。RHEL for Open Source Infrastructure 旨在为开源项目（无论是否与红帽有任何关联）提供免费的 RHEL，满足其基础设施和开发需求。

最后，我想对所有开源公司说，无论你们的代码目前是否开源，或者你们是否考虑转向开源模式。从任何角度来看，红帽都是完全开源的，一直采用开源开发模式。我希望许多开源公司能够像我们一样取得成功。你们可以自行决定下游重建是否对你有价值，并让这一过程变得容易还是不容易。

如果是仅仅重新构建代码，而不对现有代码增加价值或进行任何修改，对于所有开源公司来说，这才是真正的威胁。这对开源来说是一个真正的威胁，有可能将开源重新变回到只适用于业余爱好者和黑客的活动。

我们不希望那样，我知道我们的社区成员、客户和合作伙伴也不希望那样。创新发生在上游。在他人的基础上进行建设性的工作正是开源的核心所在。让我们继续推动创新，相互支持，不断向前发展。

参考链接：

https://www.redhat.com/en/blog/furthering-evolution-centos-stream

https://www.theregister.com/2023/06/23/red_hat_centos_move/

https://www.infoq.cn/article/NGt234WtjgPOwITMlXWo、

https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes