Controversy surrounds Red Hat's "obfuscated" source code release
元ネタ
Red Hat defends changes to kernel source distribution
続報
Red Hat Enterprise Linux(RHEL)はサブスクリプション方式で提供されていて、バイナリパッケージの配布はサブスクリプション契約者のみに行われていますが、ソースパッケージ(SRPM)は誰でも入手可能です。
このソースパッケージを元に(商標関連のものを取り除く作業とかを経て)バイナリパッケージをリビルドし、コミュニティベースのCentOSとかScientific Linuxとして配布されています。
OracleはOracle Linuxというものを販売しており、これは基本的にはRHELのリビルド品ですが、カーネルだけはOracle Unbreakable Enterprise Kernelという独自のものになっています。
ソースパッケージ(SRPM)は、基本的にupstreamのtarボールとビルドに必要な情報が書かれたspecファイルと、必要に応じて差分をパッチで提供しています。どのパッチを当てるかはspecファイルに書かれているわけです。
debパッケージとはちょっと違いますが、まぁ考え方はだいたい似たようなものです。
RHELのソースパッケージも原則として同じなのですが、RHEL 6.0のカーネルのソースパッケージだけは、パッチを適用した状態で配布されるようになったのです。
これはどういうことかといいますと、CentOSやScientific Linuxのように原則としてただバイナリパッケージをビルドしているだけであればどのような方法でソースが提供されても一緒なわけですが、Oracleのように独自に手を入れている場合、とても困ることになるわけです。
というのも、OracleはRHELのカーネルに対する差分という方法でしか独自の機能を盛り込むことができないわけですが、これができなくなるということですね。
RHELのカーネルと同じ機能プラス自分たちの付加機能であればまだいいのかもしれませんが(それでも困難ですが)、削りたい部分も当然あるでしょう。パッチが提供されていると当てないだけなので簡単に削れるのですが、全て当たっている状態だとこれができません。
ようするに、Oracleはカーネルの管理コストが大幅に跳ね上がるか、あるいは管理不能になるわけです。
もちろんカーネルのGPL2というライセンスを侵害することはありません。
私もカーネルのソースパッケージをダウンロードして実際に確認してみましたが、パッチはlinux-kernel-test.patchという空のファイルが用意されているだけでした。
あとはこれを支持するかどうかですが、私はもちろん支持します。
Oracleが好き嫌いとかそういうことではなく、フリーライドはよくないよね、ということでですが。
少なくとも私はこんな作戦をいくら考えても思いつかないので、ただひたすら感心したというか、Red Hatを敵に回すと怖いなーと思いました。
追記:
Commitment to Open
明言はしていませんが、競合相手(=Oracle)潰しであることを認めていますね。
あと、Oracle Linux 6はもうすでにリリースされているので、カーネルの問題は解決しているのでしょう。とはいえ、安定性(というか信頼性)は下がっているはずなので、Red Hatはそこを突いて商談するんでしょうね。
元ネタ
Red Hat defends changes to kernel source distribution
続報
Red Hat Enterprise Linux(RHEL)はサブスクリプション方式で提供されていて、バイナリパッケージの配布はサブスクリプション契約者のみに行われていますが、ソースパッケージ(SRPM)は誰でも入手可能です。
このソースパッケージを元に(商標関連のものを取り除く作業とかを経て)バイナリパッケージをリビルドし、コミュニティベースのCentOSとかScientific Linuxとして配布されています。
OracleはOracle Linuxというものを販売しており、これは基本的にはRHELのリビルド品ですが、カーネルだけはOracle Unbreakable Enterprise Kernelという独自のものになっています。
ソースパッケージ(SRPM)は、基本的にupstreamのtarボールとビルドに必要な情報が書かれたspecファイルと、必要に応じて差分をパッチで提供しています。どのパッチを当てるかはspecファイルに書かれているわけです。
debパッケージとはちょっと違いますが、まぁ考え方はだいたい似たようなものです。
RHELのソースパッケージも原則として同じなのですが、RHEL 6.0のカーネルのソースパッケージだけは、パッチを適用した状態で配布されるようになったのです。
これはどういうことかといいますと、CentOSやScientific Linuxのように原則としてただバイナリパッケージをビルドしているだけであればどのような方法でソースが提供されても一緒なわけですが、Oracleのように独自に手を入れている場合、とても困ることになるわけです。
というのも、OracleはRHELのカーネルに対する差分という方法でしか独自の機能を盛り込むことができないわけですが、これができなくなるということですね。
RHELのカーネルと同じ機能プラス自分たちの付加機能であればまだいいのかもしれませんが(それでも困難ですが)、削りたい部分も当然あるでしょう。パッチが提供されていると当てないだけなので簡単に削れるのですが、全て当たっている状態だとこれができません。
ようするに、Oracleはカーネルの管理コストが大幅に跳ね上がるか、あるいは管理不能になるわけです。
もちろんカーネルのGPL2というライセンスを侵害することはありません。
私もカーネルのソースパッケージをダウンロードして実際に確認してみましたが、パッチはlinux-kernel-test.patchという空のファイルが用意されているだけでした。
あとはこれを支持するかどうかですが、私はもちろん支持します。
Oracleが好き嫌いとかそういうことではなく、フリーライドはよくないよね、ということでですが。
少なくとも私はこんな作戦をいくら考えても思いつかないので、ただひたすら感心したというか、Red Hatを敵に回すと怖いなーと思いました。
追記:
Commitment to Open
明言はしていませんが、競合相手(=Oracle)潰しであることを認めていますね。
あと、Oracle Linux 6はもうすでにリリースされているので、カーネルの問題は解決しているのでしょう。とはいえ、安定性(というか信頼性)は下がっているはずなので、Red Hatはそこを突いて商談するんでしょうね。
※コメント投稿者のブログIDはブログ作成者のみに通知されます