导读 | 红帽上周宣布了限制源代码访问性的政策,称其企业发行版 RHEL (Red Hat Enterprise Linux) 相关源码仅通过 CentOS Stream 公开,付费客户和合作伙伴可通过 Red Hat Customer Portal 访问到源代码。 |
红帽上周宣布了限制源代码访问性的政策,称其企业发行版 RHEL (Red Hat Enterprise Linux) 相关源码仅通过 CentOS Stream 公开,付费客户和合作伙伴可通过 Red Hat Customer Portal 访问到源代码。
此举引发了巨大争议,红帽甚至被指责 “背叛” 开源。
近日,红帽副总裁 Mike McGrath 通过官方博客做出回应,表示该公司恪守对开源的承诺。他表示,RHEL 是基于 CentOS Stream,而 CentOS Stream 的 gitlab 库是公开的,称 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,满足其基础设施和开发需求。
最后,我想对所有开源公司说,无论你们的代码目前是否开源,或者你们是否考虑转向开源模式。从任何角度来看,红帽都是完全开源的,一直采用开源开发模式。我希望许多开源公司能够像我们一样取得成功。你们可以自行决定下游重建是否对你有价值,并让这一过程变得容易还是不容易。
如果是仅仅重新构建代码,而不对现有代码增加价值或进行任何修改,对于所有开源公司来说,这才是真正的威胁。这对开源来说是一个真正的威胁,有可能将开源重新变回到只适用于业余爱好者和黑客的活动。
我们不希望那样,我知道我们的社区成员、客户和合作伙伴也不希望那样。创新发生在上游。在他人的基础上进行建设性的工作正是开源的核心所在。让我们继续推动创新,相互支持,不断向前发展。