本の虫

GNU sed 4.2.2 released, and a rant from the maintainer

GNU sed 4.2.2のリリースに合わせて、メンテナーであるPaolo Bonziniが、GNU sedを含むGNUプロジェクトのメンテナーをやめると発言している。さらに、その理由について書き立てている。

私はGNU sed 4.2.2を喜ばしく発表する。

喜ばしからぬ発表として、私はGNU sed(8年間)とGNU grep(3年)のメンテナーから降りる。私はさらに、Autoconf, Automake, Libtool, gnulib, libsigsegv, Bsionのコミットアクセス権も放棄する。

GNUメンテナーと外部の者に告ぐ。この発表や、Nikos Mavrogiannopoulosの発表、gnutlsの移行は、驚くにあたらない。

gnutls is moving [LWN.net]では、GnuTLSの開発が、GNU傘下から離れた。今後はGNU外で行われることを発表している。それはさておき。

Nikosと同じで、私は自由ソフトウェア財団の思想は支持している。私が1999年にGNUプロジェクトに参加してからの自由ソフトウェア財団のスタッフの協力にも感謝している。しかし、Nikosと同じく、自由ソフトウェア財団とリチャードストールマンのいくつかの決定には不服である。

要点は、以下の三点に集約される。

1) ぶっきらぼうに言うと、GNUプロジェクトがこの業界で広く使われるには、自由ソフトウェア財団の勧告を無視する必要がある。GNUコンパイラーコレクションがCからC++に移行した時、ストールマンが関わっていたはずがないし、GNOMEがgnome-shellの拡張言語としてJavaScriptを選んだときもそうだ。

時に、一人の人間が決定を下すのは、良いことである。例えば、GNUメンテナーのような様々なグループの集合に、C++のコーディング規約を同意させるのは難しい。しかし、ストールマンがよこしてくれるのは、「C++よりCの方が望ましい。何故ならば、C++は汚いからだ」だけだ。この結果、GNUのコーディング規約は長年更新されず、すべて古臭いものと成り下がっている。

これは、プログラミング言語だけに限定される話ではない。libabcのようなものは、本来GNUコミュニティから発生すべきものであったが、そうではなかった。

libabcは、お手本ソフトウェアである。近年、カーネルスペースとユーザースペースの協調動作が重要になってきているが、従来のカーネル開発者は、カーネルコードにおいては有益だが、ユーザーコードにおいては間違っている技法を、そのまま使おうとする。このような間違いを防ぐために、お手本となるような、それ自体は何もしないスケルトンのソフトウェアを提示する目的で、libabcプロジェクトが立ち上がった。それはさておき。

さらに、GNUコーディング規約では、セキュリティに対する言及が一切ない。いまだに、「Unixプログラムには静的テーブルや固定長文字列がよく使われているが、これは制限が多い。動的確保を使え」などと宣っているが、信頼できない入力を扱うときは、その制限が必要なときもあるのだ。

これは実際、相当問題になっている。というのも、自由ソフトウェア財団とリチャードストールマンは、しばしば技術的理由ではなく、政治的理由による意思決定を行い、多くの機能の実装を阻害してきた。

例えば、gccは、コンパイラーの各部の機能、つまり字句解析や意味解析や最適化やコード生成などを十分に独立させず、機能単体に分離して組み込んで使うことを難しくしているし、内部表現を規格化せず、別のソフトウェアで内部表現を生成させてそこから先の最適化やコード生成はgccで行うなどということも難しくしている。

これは、そのように一部の機能を独立させて組み込みやすくしてしまうと、不自由なソフトウェアから違法に使われる恐れがあるという政治的な理由で、あえてそのように作ってある。

また、gccにコンパイル済みヘッダーの機能を付け加えるのも、リチャード・ストールマンの強い反対により、しばらく抑えられていたともいう。

その結果、GCCは現在、後発のLLVMにかなりその従来の独占的地位を脅かされている。

また、GNUによる自由なカーネルであるHurdも、リチャード・ストールマンの、「マイクロカーネルのMachを元にすれば、ほとんどのコードがユーザースペースでデバッグできて簡単じゃね？」という意思決定により、いまだに実用化に至っていない。もし、BSDを元にしていたならば、FreBSdやNetBSDやOpenBSDやDragonFly BSDのように、今頃はともかくも実用になるカーネルが出来上がっていたかもしれないのだ。

2) GNUが自由ソフトウェア財団にしていることは少なく、自由ソフトウェア財団がGNUにしていることも少ない。GNUマニフェストが発表されてより、自由ソフトウェアは大いに成功したため、自由ソフトウェアの配布というのは、GNU由来だけではなくなっている。これは良いことである。しかし、自由ソフトウェア財団は、GNUというブランドの構築に無頓着である。gnash(訳注：自由なソフトウェア実装のFlash Player)のようなプロジェクトは、長年自由ソフトウェア財団の高優先度プロジェクトのリストに載っているにもかかわらず、資金難に悩まされている。リストに乗っている他のプロジェクトは、存在すらしていない。何故ならば、年単位の開発期間がかかるが、開発をしようと思う人間は、自腹で行わなければならないからだ。

多くの業界を自由ソフトウェアが占めるためには十分ではない。また、自由ソフトウェアが、いわゆる「オープンソース」などと呼ばれる、ユーザーの自由を気にかけない勢力と競争して勝ち抜いていくためには、全然十分ではない。

3) プログラムにGNUの名前を冠しても、もはや宣伝にはならない。皆、GNUといえば象のようにのろまであると考え、ガゼルのように素早いとは思わない。これは正しいかもしれないのだ。LLVMのようなプロジェクトは、GNUの意思決定プロセスの遅さを尻目に、すばらしい開発速度を達成しているし、Appleのような企業が、GPLv3の問題を避けるためにプロジェクトを支援しているのであっても、世間からは賞賛されている。

GNUの一部であることは、もはや技術的に指導力を発揮できる象徴ではないのだ。「Unixで貧弱ならば、全然別の優れたもので置き換えればよい」。今日のGNUで、今なおこれが言えるか？

現状の方針の変更を阻害するGNUと、上記3つの理由により、GNUが無益になりつつある。方針の変更が行われない以上、もはやGNUの一部である理由がない。

これ以降、私がコミット権を維持するのは、GCCとGNU Smalltalkに限る。GNU Smalltalkについては、まだはっきりと決めていない。仕事と家庭に追われて、1996年、私を自由なソフトウェアに誘ってくれたプロジェクトから離れ始めている。GNU傘下から引き離したいが、それも多大な開発力を必要とする。意見くれ。

gnutlsの状況については、Linux Weekly Newsでまとめを読むことができる。購読していないのならば、GnuTLS, copyright assignment, and GNU project governance [LWN.net]から読むことができる。LWMもサポートよろしく。

とうとう、言うべきことが言われた感がある。実際、今、GNUプロジェクトに起こっている、技術的に良い傾向のある動きは、すべて自由ソフトウェア財団とリチャードストールマンの意向に反するものである。GCCの開発をC++に移行するとか、GCCでもモジュール化を考えようなどといった動きだ。

この問題を放置すると、GNUのソフトウェアの利用率が下がり、GNUの影響力の低下にもつながる。