AlmaLinux、ソースコードの公開方針を変更したレッドハットとの関係に暗雲
今回は「AlmaLinux、ソースコードの公開方針を変更したレッドハットとの関係に暗雲」についてご紹介します。
関連ワード （CIO／経営等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
Red Hatが「Red Hat Enterprise Linux」（RHEL）のソースコードの配付対象を顧客のみにすると発表したことで、RHELのソースコードが簡単には入手できなくなり、「AlmaLinux」や「Oracle Linux」、「Rocky Linux」などのRHELクローンのディストリビューション作成工程は大きな影響を受けることになった。これに対し、Oracle LinuxやRocky Linuxは争う姿勢を見せているが、AlmaLinuxは穏健な手段を選択した。しかしその方針は、期待されていたほどどうまくいっていない。
AlmaLinuxは、RHELとのソースコードの互換性を100％保証することを放棄した。その代わり、AlmaLinuxの開発者は、アプリケーションバイナリインターフェイス（ABI）レベルでの互換性を確保することを選んだ。ほとんどの場合、実用的な目的にはこれで十分だ。
AlmaLinuxの理事会は、「コミュニティのニーズに応えるため、可能な限り、今後もRHELとのABIレベルでの互換性があり、RHEL上で動作するソフトウェアがAlmaLinux上でも同じように動作するような、エンタープライズ水準のLinuxディストリビューションを長期的に生産することを目指す」ことを全会一致で決議した。
AlmaLinuxの理事長であるbenny Vasquez氏は、「ここで言うABIの互換性は、RHEL（またはRHELクローン）上で動作するようにビルドされたアプリケーションがAlmaLinux上で問題なく動作することを保証することを意味する。想定が変わったため、私たちがリリースするものすべてが、RHELで得られるソースコードとまったく同じであることを保証する必要はなくなる」と述べている。
これを実現するために、AlmaLinuxは「CentOS Stream」のソースコードを使用する。さらにVasquez氏は、「私たちは、創業以来そうしてきたように、FedoraやCentOS Streamのアップストリームや、より大きなEnterprise Linuxのエコシステムへのコントリビューションを続けるつもりであり、コミュニティーにも同じことをするよう呼びかける」とした。
Red Hat側は公式には何も述べていない。しかし筆者が同社の関係者らから聞いたところによると、それはまさしく「RHELライクなディストリビューションが採用するべきだとわれわれが示唆してきているアプローチ、すなわちCentOS Streamでより広範なコミュニティーと連携していくこと」だという。
では、何が問題なのだろうか。KnownHostの最高技術責任者（CTO）であり、AlmaLinuxにおけるインフラチームのリーダーでもあるJonathan Wright氏は最近、CentOS Streamの「iperf3」に存在するメモリーオーバーフローの問題（CVE-2023-38403）のフィックスをプッシュした。iperf3は人気の高い、オープンソースのネットワークパフォーマンステストツールだ。このセキュリティ脆弱性は重要に分類されるものだが、重大というほどではない。それでも、放置しておき、最終的にサーバーをクラッシュさせるために用いられるよりも、対処しておいた方がはるかに良いはずだ。
筆者や他の人々もこの見解に同意している。しかしRed Hatのある上級ソフトウェアエンジニアが、「貢献に感謝する。現時点ではRHELでこの問題に対処する計画はなく、顧客からのフィードバックに基づく評価待ちとしてとどめておく」という答えを返してきたのだ。
その結果、やり取りは紛糾することになった。
GitLabでのやり取りは次のように続いた。
AlmaLinux：「顧客からの要求はCVEに対処する上で本当に必要なのか？」
RedHat：「Red Hatは自らが『Critical』（重大）と『Important』（高）と定義したセキュリティ問題に対処することに責任を持つ。『Low』（低）や『Moderate』（中）のセキュリティ脆弱性は、顧客やその他の企業から対応する必要があるという要求があった際に対処する」
AlmaLinux：「その点については理解できるが、既に作業が完了しており、あとはマージするだけの状態となっているフィックスを拒否するのはなぜなのか？」
この時点で、Red Hatのコアプラットフォーム、すなわちRHELのバイスプレジデントであるMike McGrath氏が割って入り、「われわれはおそらく、『サブミットした場合、どのようなことが予想されるか』というドキュメントを作成しておく必要があるのだろう。開発されたコードの受領は、Red Hatがそのコードに関して実行する作業の第1段階でしかない。われわれは、デグレードが発生していないかや、品質保証（QA）といった作業を確実にこなさなければならない。（中略）まとめると、あなたの貢献については感謝している。そして、Fedora側で問題が発生していないようなので、どこかの時点でRHELに取り込まれることになるだろう」と説明した。
この発言を機にやり取りはさらに険悪なものになった。
あるユーザーは「顧客からの要求が必要だというのか？ならば、これが顧客の要求だ。『修正してほしい、さもなくばRHELを2度と使わない』」と記している。また別のユーザーは、Red Hatが「Almaはもうフィックスをアップストリームにプッシュしないため、われわれは商売に専念する！」「あなたたちのフィックスは要らないよ、Alma！」と書いているのも同然だと記している。
その後McGrath氏は、Redditで「AlmaLinuxに善意を示す絶好のチャンスだったところで、しくじってしまった」と述べた。
結局、Red Hatの製品セキュリティチームは、このCVEを再評価して深刻度を「重要」に引き上げ、問題のパッチをマージした。
これで当面の問題は解決したわけだ。とはいえ、このやりとりはしこりを残した。Wright氏は「私にとって今回最悪だったのは、PR（プルリクエスト）を送ったのは時間の無駄だったと感じたことだ」と述べているが、これは、オープンソースコミュニティーの開発者からは絶対に聞きたくない反応だろう。
しかしVasquez氏は、今後について前向きに捉えている。同氏はあるインタビューで、「これは全員にとって未知の領域であり、関係者にはものごとを改善しようという意思が見えた。私たちの本当のゴール（エコシステムを全員にとってよいものにしていくこと）に立ち返れば、今回のやりとりは全員にとって学びの機会になったと言えるだろう。Red Hatにはすでに、SIG（CentOS Stream Special Interest Groups）から出てきたものを受け入れるプロセスや手順があるが、SIG以外からのPRの受け入れに関しても改善されることを期待している」と語った。
果たしてどうなるだろうか。