LinuxカーネルのIRQをめぐる大論争
最近、Linuxカーネルメーリングリスト（Linux Kernel Mailing List：LKML）では、デバイスそのものにIRQをオフにする制御を許可するかどうかについて、議論が盛り上がっている。クローズドソースのドライバをもっと容易にカーネルとやりとりできるようにしたいと考える人々は、この機能の実現を望んでいる。だがTorvalds氏は、断固としてこれに反対している。バイナリblob対GPLという図式の再来となるわけだが、両者の対立点は1つではない。この論争は、一部の人々にとっては技術的なものだが、他の人々にとっては思想的なものだ。そのため議論は、オープンソース/フリーソフトウェアのコミュニティにまで及んでいる。
SUSEのベテラン・カーネルハッカーであるGreg Kroah-Hartman氏が、あるパッチをカーネルのバージョン2.6.19に投稿したことで、論争に火が点いた。Torvalds氏が、このパッチを自らのカーネルに採用することを拒んだのだ。ただしこのパッチは、ここしばらくの間、Andrew Morton氏のカーネルツリーに入ったままになっている。
Torvalds氏は拒否の理由を次のように説明している。
どうか削除してもらいたい。IRQの問題は決してユーザ空間に解決させてはならないのだ！
非常に簡単なことだ。IRQハンドラは完全にカーネル空間内に存在しなければならない。ユーザ空間を巻き込むなど、もってのほかである。
Linus（Torvalds氏）はその後の電子メールで展開した意見のなかで、次のように述べている。「こうしたことが行われることに不当に反対するわけではないが（すでにUSBデバイスではそれを許している）、そのためには、ドライバのオープンソース化を回避する方法を探している忌まわしい一部のベンダーではなく‘我々’の役に立つ、という確かな理由が存在しなければならない」
Torvalds氏がパッチを拒否し、そうした現実世界の実例を求めたことを踏まえて、Kroah-Hartman氏はLKML宛てに次のようなメッセージを送っている。
このところ、非常に多くの人々の関心を集めているのが、ユーザ空間の入出力ドライバのコアで、ある種のハードウェアを操作するコードをユーザ空間の各種ドライバに書けるようにするものです。このUIOコアは現在動作していて、-mmリリースに含まれています。LKMLに最後にパッチが投稿されたときから書き直しが行われているため、かなりシンプルなコアになっています。また、必要な文書がすべて含まれているほか、ドライバのサンプルと、それらのドライバをテストするユーザ空間のプログラムのサンプルが2点ずつ用意されています。
しかし、このコアをカーネルツリーに入れるには、それを利用する「本物の」ドライバの開発が必要になります。したがって、このコアのカーネルツリーへのマージを求める誰もにとって、今こそが一歩踏み出してこうしたドライバインタフェースを必要とするハードウェア用にパッチを投稿するタイミングです。
そうしたドライバが登場しなければ、このインタフェースがカーネルツリーに受け入れられるチャンスは極めて小さくなるでしょう。
これ以降、この論争はバイナリblob対GPLという、より大きな問題に発展してしまった。その後、LKMLで起こった議論には、1年後には一切のバイナリblobの存在を許さない旨の通達を出すことによって、そうしたバイナリをカーネルからすべて除去しようという提案が含まれていた。1年あれば、バイナリblobの開発者もGPLに従うデバイスドライバを開発できるだろうという考えだ。そうしたblobの例が、クローズドソースのドライバとしてよく知られているNvidiaドライバである。これはNvidiaの3Dグラフィックカードの機能を最大限にLinuxユーザに提供するものだ。
Alan Cox氏が議論において述べたように、Torvalds氏の判断がすべてではない。Torvalds氏の意見にはおそらく他の誰よりも重みがあるだろうが、その内容はまたしてもFSFの考えとはかけ離れたものになっている。Torvalds氏は、次のような文面を書き、自分自身のカーネルツリーではなく、まずは主要な商用ディストリビューションを擁する企業独自のカーネルツリーにそうした変更を加えるよう、要求したのだ。
2006年12月13日 水曜日、GregKHさんは書きました: >
> Linuxカーネルへの非GPLドライバの組み込みはカーネルのライセンス
> および著作権に違反する、と感じているカーネル開発者は膨大な数に
> のぼります。そのため、GPLに準拠していないモジュールの問題に取り
> 組む者全員に1年の猶予を伝える通知が与えられたのです。
ところで私は、この措置には配慮が足りないと真剣に思っている。
その結果は、それこそ我々がまさに回避しようとしていた問題、はっきり言ってしまえば、実際にはまったく何の役にも絶たないどころかコードをユーザ空間に移してしまう愚かな「いかさま」ドライバの問題に陥るだけだろう。
その趣旨は何だったのだろうか。
我々がライセンスほどにはテクノロジに関心がないことを示すことによって、人々を遠ざけることがねらいだったのだろうか。
単にそのように言うことで、我々が派生成果物の限界を越えられると考えていることを示すことだったのだろうか。
滑稽なのは、どちらかと言うとこうした動きを強く支持する傾向のある人々が、全米レコード協会（RIAA）は所有する音楽著作権に関して人々のすることに口出しできるべきではなく、また、明らかに著作権法で認められた権利に技術的な制限を課しているという理由でデジタルミレニアム著作権法（DMCA）は悪法だ、と言っているのとまさしく同じ人々であることだ。
これを偽善と言わずして何と言うのだろうか。
つまり、他人が行えば悪いことでも自分たちがやれば問題ない、というわけだ。なぜかたいして驚いてはいないのだが、それでもあなた方がこの問題に対して裏表のある態度をとっていることに私は悲しみを覚える。
実を言うと、私がこの件は強制すべきでないと考える理由は、非常に簡単だ。著作権法については、明らかにグレーゾーンにある「派生成果物」の問題をあなた方が受け入れれば、あっさりと良い方向に向かうからだ。この問題はあいまいで、白黒がはっきりつけられるものではない。だが、グレーであることは悪いことではない。故意に白黒をはっきりさせる技術的対策をとるのは確かに悪いことだ。RIAAが行うにせよ他の誰かが行うにせよ、良くないことに変わりはない。
あるモジュールがほぼ間違いなく派生成果物ではない場合、我々は断じて、その作者は我々の世界観に従わねばならない、などと言うべきではない。
我々は「技術的な価値」に対する判断を行なうべきなのだ。この点は、それ以外の部分では明確に押し進められている。
図らずも私は、自分が愛用しているどんなデバイスであれ、そこに入っている自らのDVDや音楽の視聴を妨げるような技術的手段は取るべきではない、と信じている。公正使用にほかならないからだ。だが、この点でも反対の方向に進んでいる。著作権に関する我々のルールを、我々の成果物から派生したものではないコードに押しつけようとしたり、技術的手段を行使して、人々が自らのやり方でさまざまな要素を結合するのを回避しようとしたりするべきではないのだ。
ただし、我々のコードをよそに持っていくのなら、我々のルールに従ってもらう必要がある。だが、RIAAの音楽をただ聞いているからといって、RIAAのルールに従って行動する必要はないはずだ。同様に、我々のシステムを利用しているという理由だけで、誰かに対して我々のルールに従った行動を強制することがあってはならない。
「コピー」と「使用」との間には大きな違いがある。この点は、対象が音楽でもコードでもまったく同じだ。他人の音楽は再配布できないが（その人に著作権があるため）、著作権を持つ人々は、その作品が個人によってどのように使用されるかについて制限を課すべきではない（それはその個人の生活に関する問題である）。
コードにも同じことが言える。著作権は、使用についてではなく配布について定めたものだ。よって、コードの使われ方は制限すべきでない。
もちろん、誰も私の言うことを聞かないだろうし、誰もが自分の意見に固執していることは了解している。
つまり、私が提案したいのは、この件をあなたの組織の顧問弁護士に相談してはどうか、ということだ。また、そのパッチを最初にマージすることをあなたの組織が納得しない限り、自分としてはそのパッチをマージするつもりはない。
いずれにせよ、あなた方は私のスタンスをご存知のはずだ。他のカーネル開発者たちと結託したうえでの意見に論争を挑む気はないが、間違っても私がこのパッチを最初にマージすることはないし、私のカーネルツリーにこのパッチを含めることもないだろう。
したがって、まずはUbuntuや（Open）SuSE、RHEL、Fedoraのカーネルツリーにマージしてもらうとよい。そうすれば、他のツリーに悪影響を与える形で私のカーネルツリーが使われることはない。ただし、その場合は他の方面から働きかけるのが適切だろう。
このパッチには配慮が足らない、と私は思っている。だから、あなたの政治的な問題を前に進めるのなら、どうか私以外の誰かを使ってもらいたい。
Linus
ここまでご覧になった読者の皆さんは、常にカーネル開発者が検討すべき唯一のことはコードを正しいものにすることなのだ、と思われたのではないだろうか。
