Red Hat 改变内核源码打包方式

Linux就该这么学

0. 前言

Red Hat 在2010年11月份发布了RHEL 6,像以往发布的主版本一样,这个积 Red Hat 3年心血之作带来的 RHEL 6 包括了许多重要改动,这些技术上的改进无疑将巩固 Red Hat 在企业级操作系统市场的领先地位。然而在众多的技术改进之外,一个不易察觉却影响深远的改动却一直未被注意到,直到被 LWN 的编辑 Jonathan Corbet 提了出来,才引起人们的注意,并引发了一场轩然大波。这个改动之处就是 Red Hat 对 Kernel 源代码包的打包方式,个中缘由还得从头说起。

1. 成功的商业模式

众所周知,Red Hat 是利用开源软件从事商业化操作最成功的公司,有数据显示 Red Hat 极有可能在2011年成为首个年盈利达到 Billion Dollar 级别的开源软件公司。Red Hat 的商业模式并不复杂,由于开源软件源代码开放的本质,Red Hat 的收入主要来自于提供开源软件的服务,这也意味着,任何其它有技术实力的公司也可以这么做,比如长期如影随行的对手 Novell。

为了能够在这样的竞争中获胜,Red Hat 投入了大量的人力(包括收购公司)来参与主要开源软件项目的开发,像 Linux Kernel, X.org, Gnome, GCC 都有相当一部分代码来自于 Red Hat 的贡献。Red Hat 这样做,一方面是为了自己的商业利益,另一方面却也惠及了整个开源社区,因此形成了一个双赢的局面,而且这样做也正符合了开源软件运动的初衷。Linux 能够在过去的几年里,一步步的将那些老牌的 UNIX 对手远远的甩在了后面,这里面应该有 Red Hat 的一份功劳。

2. 亦步亦趋的克隆者

付出总会有回报,Red Hat 在这些开源软件项目上的付出得到的是市场对 Red Hat 发行版 RHEL 的肯定。RHEL 的高性能,高稳定性,高可用性使得 RHEL 成为企业级服务器市场最成功的操作系统。当然 RHEL 的价格也不菲,RHEL 6 的 subscription 费用根据签订的合约版本不同而有所不同,从最便宜的桌面版的39欧元到包含所有附加服务的服务器版本的几千欧元之间不等。

不菲的价格使得那些不愿负担这个费用的用户开始从另一个角度来想办法使用 RHEL。根据 GPL, 所有 Red Hat 修改或使用的开源软件必须开放源代码,因此开源社区里诞生了一些通过重新编译 RHEL 提供的源代码而生成的发行版,这其中使用最广泛的是 CentOS 与 Scientific Linux, 这些发行版统称 RHEL 的克隆版本。

按常理来说,类似 CentOS 这样的发行版应该是RHEL的大忌,毕竟它们的出现使得 RHEL 的存在颇为尴尬,当你有一个免费的选择时,你会花钱买一个相同的东西吗?但实际上 Red Hat 与 CentOS 社区的关系并不像想像的那样剑拔弩张,CentOS 社区的许多开发人员都与 Red Hat 有着非常良好的关系。因为本质上 CentOS 的存在并没有真正威胁到 Red Hat,CentOS 只是一个将 RHEL 源代码重新编译的社区发行版,而不是一个靠提供服务盈利的公司。此外从某种意义上来说,Red Hat 也乐见 CentOS 的存在,因为不是所有用户都愿意或有能力去购买 Red Hat 的 subscription,而 CentOS 的存在可以帮助 Red Hat 吸引这批用户,而这些 CentOS 的用户实际上是潜在的 Red Hat 用户,因为他们已经熟悉了 RHEL。

3. 不光彩的搅局者

事情本可以朝着这种比较理想的状态发展下去,但 Red Hat 商业上的成功以及 RHEL 开放的源代码很快吸引了某个觊觎已久的厂商加入到了 CentOS 的行列,没错,这个厂商就是在开源社区里臭名昭著的 Oracle。Oracle 本来与 Red Hat 是合作伙伴,RHEL也是 Oracle 数据库最早支持的 Linux 发行版。但 Oracle 很快就舍弃了 RHEL(也舍弃了从 Sun 收购过来的 OpenSolaris),然后像 CentOS 那样重新编译 RHEL 推出了自己的 Oracle Linux,因为这么做对于 Oracle 来说,成本很低,同时效率却很高。

当然 Oracle 所做的不像 CentOS 那么简单,CentOS 为了保持与 RHEL 100% 的二进制兼容,只是将 RHEL 的商标以及 logo 等去掉,并不去做其它改动。Oracle 的做法则是仍然使用 RHEL 做他的发行版的基础,然后将 RHEL 的 Kernel 做了一些修复并重命名为 Unbreakable Enterprise Kernel,同时还添加了 Oracle 自己的 OCSF2 文件系统支持。为此 Oracle 曾宣布他推出的 Oracle Linux 5 比相应的 RHEL 5 要快。更要命的是 Oracle 也推出了自己的服务,而且他的服务不光支持 Oralce Linux,也支持 RHEL。至少对于那些使用 Oracle 数据库的 RHEL 客户来说,卸掉 RHEL 转而投向 Oracle 似乎是很自然的选择。

4. 无奈的下策

Oracle 这么做已经不单单是克隆了,而是实实在在的威胁到了 Red Hat。实际上 Oracle 的做法除了龌龊,不道德之外,并没有违反 GPL 的约定,毕竟 Oracle 也开放了他的源码。但在商业利益面前,Red Hat 必须要采取行动。Red Hat 的想法就是在保证满足 GPL 的要求下,使得 Oracle 以及其它厂商无法轻易的利用他开放的源码。而在这些开源项目中,Kernel 又是重中之重。估计Red Hat 就是在这样的情境下,将 Kernel Source 的打包方式从原来的一个上游 tar 包 + N 个patch,变成了现在的一个大 tar 包。

Red Hat 的做法经过 LWN 披露后,立即引起了轩然大波。大部分的开发人员对此表示失望,Jonathan Corbet 也认为这是 Red Hat 犯的一个错误。在经过短暂的沉默之后,Red Hat 的 CTO 对此作出了公开回应。他表示 Red Hat 这么做是为了残酷的竞争,从整体上来说,Red Hat 依然以上游的原生 Kernel 优先,RHEL 相关的 Kernel patch 必须先经过上游的 Kernel tree,然后才能进入 RHEL,所以对 Kernel 社区来说,并没有多大损失。

5. 不同的结果

Red Hat 这么做,首先针对的是那些抢夺他客户的厂商,主要是 Oracle,也包括 Novell。在 RHEL 6 发布3个月后,Oracle Linux 6 也发布了,这一次,Oracle 的 Unbreakable Enterprise Kernel 没有再基于 RHEL 的Kernel,而是基于了2.6.32-stable(现在叫 long-term 了),当然 Oracle Linux 的其它部分仍然是重新编译的 RHEL,并且仍然提供了重新编译的 RHEL Kernel 作为给用户的一个选择。很难说 Red Hat 这么做给 Oracle 带来了多大影响,Oracle 的商业策略依然在支持使用 RHEL 的客户,也许不再基于 RHEL Kernel 的 Unbreakable Enterprise Kernel 将使得 Oracle Linux 在面对 RHEL 时不再有竞争力,也许 Oracle 在支持 RHEL 用户时更加困难?

很多用户曾担心 Red Hat 的改变将给 CentOS,Scientific Linux 等克隆版本的开发增加困难。但事实上,这个影响并不大,毕竟他们只是重新编译,涉及不到对 Kernel 的开发。Scientific Linux 在 Oracle Linux 6 发布之后不久,也发布了相应的6.0版本。而 CentOS 虽然还没推出相应的 CentOS 6,但 CentOS 的 Leader 已经明确表示这个改动对 CentOS 影响不大,即使是对 RHEL Kernel 有改动的 CentOS Plus Kernel 影响也不大。

关心 Red Hat 这个改动的还有其它发行版的开发人员。比如 Debian 的 Kernel 维护人员 Maximilian Attems 就曾经直言不讳的批评过 Red Hat 的改动。通常来说,每个发行版的开发周期都不一样,不同的发行版会按照自己的开发周期,选择当时最合适的一个 Kernel 版本作为发行版的 Kernel Base。不过与RHEL同时期的几个 long-term 发行版(Debian 6.0, openSUSE 11, Ubuntu 10.04)都不约而同的选择了 2.6.32 作为基础版本(这也是原生的 2.6.32-stable 版本存在的意义),因此这几个发行版的相互协作就显得很有意义。虽然不同的发行版会有自己感兴趣的基于 2.6.32-stable 的 patch,但因为这几个版本(包括 Oracle 的 UEK)的 Kernel Source 都有开放的 git tree 可以查询,因此互相之间实际上形成了一种资源共享,这也是一种理想的开发状态,但 RHEL 的做法则完全违背了 GPL 的初衷,因为从他的 Kernel Source 里,很难找出那些适合 2.6.32-stable 的 patch。虽然 Red Hat 宣称他所有的 Kernel 开发都以上游的 Linus 的 Kernel tree 为先,但他却把自己与其它的发行版划了一条界限,当然这样做从商业利益上来说也无可厚非,毕竟 Debian, Ubuntu LTS 等发行版也是 RHEL 的竞争对手。

对于普通用户来说,比如使用 CentOS 的 Kernel 开发者,他们无法再通过阅读 RHEL 的一个个 patch 来研究 RHEL 的 Kernel 到底做了哪些改变,当然这部分用户毕竟是很少的,但同样不容小觑。购买了 subscription 的 RHEL 用户据说可以通过某个 WEB 界面能够查阅到 RHEL 内部开发使用的 git tree,因此对这些 RHEL 用户的影响现在还不得而知。

6. 深远的影响

Red Hat 这么做应该是满足 GPL 约定的,因为源代码仍然是开放的,但仍然有相当一部分用户认为 Red Hat 违反了 GPL,争论的焦点在于 GPL 里的这么一句话:”The source code for a work means the preferred form of the work for making modifications to it.”你很难界定 Red Hat 发布的源码就不是 preferred form,因为 GPL 并没有规定什么是 preferred form,也许未来的 GPL 版本将重点阐述这样的模糊概念。此外由于 RHEL 的用户可以通过某种方式查看到类似之前那样的 patch,因此 Red Hat 在他的服务条款里也施加了一定的限制,即不允许用户将通过 subscrption 得到的权益使用于第三方,如果 Oracle 通过购买 RHEL 的 subscription 变相得到了分离的 tar 包加 patch,然后再用于自己的 UEK,那 Oracle 的做法侵权吗?Red Hat 的服务条款是不允许的,但 GPL 并不允许任何他保护的作品施加任何限制。也许 Oracle 可以试着诉讼 Red Hat,毕竟他喜欢这么干。

更深刻的影响则是 Red Hat 这种趋利的做法会不会有更多的企业或组织效仿,比如 Ubuntu 之于 Debian,如果是的话,那开源软件在商业利益与社区协作之间将面临一次分裂,也许会变得对立,而这无疑将给开源软件的发展蒙上一层阴影。

本文由 CentOS中文站 - 专注Linux技术 作者:centos 发表,其版权均为 CentOS中文站 - 专注Linux技术 所有,文章内容系作者个人观点,不代表 CentOS中文站 - 专注Linux技术 对观点赞同或支持。如需转载,请注明文章来源。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注