BitKeeperとLinux――蜜月の終わり

 Linus Torvaldsを始めとするLinuxカーネルの開発者たちがパッチを当てるのに使っているソース管理ツールは、BitKeeperだ。そのBitKeeperが、再び論争の渦中に立っている。傍目には、プロプライエタリなBitKeeperとフリーソフトウェアを代表するLinuxプロジェクトがその出自の違いを克服することができず、今、破局を迎えようとしているかのように見える。しかし、実際の経緯はどうなのか、避けえないことだったのか。NewsForgeは、この論争の主要登場人物であるLarry McVoyとLinus Torvaldsと(Tridgeこと)Andrew Tridgellの3人に尋ねた。

 BitKeeperの立て役者Larry McVoyは、Torvaldsを始めとするLinux開発者たちに、ソースコードの管理をBitKeeperから別のツールに移行するよう求め、3か月の猶予を与えた。NewsForgeは、こうした形でTorvaldsとの関係を終わらせることになった理由をMcVoyに尋ねた。同氏は次のように説明している。

 2月23日のことです。Torvaldsから、Tridgeがライセンスに反してBKをリバースエンジニアリングし、BKツリーの内容を調べていると聞かされたのです。当然のことですが、私たちは驚き、TorvaldsとTridge、それにOSDLのCEOであるStuart Cohenを加えて話し合いを始めました。しかし、結果は物別れでした。Tridgeはフリーソフトウェアを強く信奉しており、フリーではないソフトウェアを使っている者は不義者だと考えています。

 TorvaldsはTridgeを説得しようと大変な努力をしてくれましたし、私もTorvaldsもこの問題に長い時間を費やしました。そして、Torvaldsは私の立場を十分に理解し、その要点を次のように上手にまとめてくれました。

 McVoyは、代替のフリーソフトウェアを書くことには完全に同意する。McVoyは私にそう言い、私はその言葉を信ずる。McVoyは強い道徳的信念を持っていると思うからである。

 McVoyが同意しかねるのは、McVoyが作ったものを単にリバースエンジニアリングしてフリーバージョンを書くことである。

 McVoyの立場は、極めて明確で道義的なものだ。「私と競うのはかまわない。しかし、私の仕事にただ乗りすべきではない。問題は自分で解くべきであり、公明正大に競うべきだ。私の答えを見て競争してはならない」

 そして、それはBKライセンスの要点である。曰わく、「虎の威を借りるな、ただ乗りさん」。それに異を唱える言葉を、私は持たない。

 しかし、Tridgeは、このようには考えないようです。

 同時に、OSDLの首脳陣とも話し合いました。これには私よりも冷静な人物を狩り出して、営業担当副社長が任に当たりました。彼は企業レベルの契約のすべてで交渉に当たってきましたから(落としどころを見つけるのが上手)、かなり穏当な人物だいうことがご理解いただけるでしょう。しかし、OSDLのCEOとはうまくいきませんでした。Cohenの立場は、これは自分たちの問題ではなく、オープンソースの世界では、ままあることだというものでした。OSDLからは、Tridgeはリバースエンジニアリングを中断しており、問題の解決に向けた努力が続いている限り再開しないという言質を取りました。不安定な休戦状態にあると私たちは考えていましたが、実際にはTridgeは作業を続けていたのです。

 私たちは八方ふさがりでした。OSDLは腰を上げず、その言葉は信用できません。しかも、Tridgeが自作のコードを公開するだろうという確信がありました。それには2つの問題があります。

 a) 改悪。BKは複雑なシステムです。BKデータベースには、10,000以上の中間的なLinuxが含まれています。それが流出してしまったら、そのすべてを人手で修復するのは不可能です。過去そういう事態になったことが一度だけあります。あるユーザーがChangeSetファイルをいじったのです。その復旧には、3万5000ドルとカスタム・リリースが必要でした。

 もしTridgeのツールが出回れば、当社のコードとTridgeのコードの両方をサポートしなければならなくなりますが、それは不可能です。

 b) 知的財産の喪失。当社が傍観しTridgeに対して何の手も打たなければ、リバースエンジニアリングを黙認したことになります。

 社内では、対策の検討が続いていました。一つの方法は、BKを2つのバージョンに分けることでした。公開するものと商用のものとに分けるのです。しばらくはこの方法を採っていましたが、うまくいきませんでした。将来の互換性を確保するため、フリーバージョンを全くサポートなしで済ませることができなかったのです。フリーバージョンと商用バージョン間の互換性を維持しようとすれば、開発をやめるほかはありません。それは誰もが損をします。つまり、この問題を解決するには、資源を投入し続ける必要があったのです。しかし、当社は、すでに、フリーバージョンのために年間約50万ドルを投入しています。今後も増えていくのを放置するわけにはいきません。

 そこで、当社はフリーバージョンのBKをやめる検討を始めました。フリーバージョンのコストがBitMoverの利益を食い潰すという結論に至ったとき、Torvaldsは供給の停止を強く勧めてくれました。

 OSDLの首脳陣には当社の考えを随時報告してきましたが、関心はないようでした。これは当社の問題であり当社が解決すべきであるというのが、OSDLの立場でした。当社がフリーバージョンの中止へと梶を切るまで、そういう姿勢だったのです。OSDLが動き出したのはごく最近のことです。共同で対処するといっても関与の程度が少なすぎますし、あまりにも遅すぎます。

 Torvaldsとの交渉は先週末にまとまり、TorvaldsはBKからの移行に着手しました。倫理観の非常に強い人物ですから、当社がひどい仕打ちを受けており、その片棒を担ぎたくないと考えたのです。それで、BKから移行することにしたのです。その後2日間かけてこの問題の扱い方を話し合いました。公表の仕方、移行の方法、計画の進め方などです。一部については、今も具体策を検討しています。こうした移行としては最大限スムーズに作業が進むようにすることが当社の願いです。

Torvaldsの見解

 McVoyからの返信を受け(McVoyは、同じ電子メールをccでTorvaldsにも送っている。2人の間で交わされた言葉を誤って引用しないように、文脈を外して引用しないようにするためである)、NewsForgeはTorvaldsに3つの質問をした。

 NewsForge:BitKeeperの代替は決まりましたか。

 Torvalds:まだ、見当もつきません。今は、自作のスクリプトやツールを使って凌いでいます。オープンソースのソースコード管理(SCM)を扱っているいろいろな人たちに話を聞いているところです。実は、情報を広く集めようと思って、この問題に関心のある人たちにできるだけ多く接触しようとしているんです。

 NewsForge:短期的または長期的に見て、ご自身の仕事の負担は?

 Torvalds:短期的には、パッチをマージしなければなりません。今現在は、-mmツリーを従来通りに機能させる必要があります。皆さんが開発を進められるようにね。一方、特にBKを使ってきた人たちにとっては、作業のペースが落ちたり、しばらく休んだり、代替品を探したりすることになるでしょう。

 BKを使い続ける人もいるでしょうね。BKがなくなるわけではありませんし、今でも最良のSCMです。私(そして一部の仲間たち)にとってはマージが厄介になるというだけのことです。ですから、BKの変更をパッチでエクスポートすることになります。しかし、この件がなくても、以前からそうした形で大部分の仕事をしていた人たち(BKのマージ機能だけを使っていた人たち)もいました。

 つまり、短期的には確かに減速するでしょうが、大きな問題はないでしょう。一番心配なのは、開発者が不透明な先行きに不満を抱くことです。ですから、早く結論を出そうとしているのですが、その一方で、拙速も避けたいのです。

 (皮肉なことだが、大方のユーザーやディストリビューションは、しばらくの間、開発が少しばかり減速しても全く気にならないようだ。ユーザーが共通して心配しているのは、2.6がスムーズに機能しているお陰で2.6.xが非常に速いペースで続いてきたということの方だ。そのために、慌てたり喜んだりの人がいるに違いない)

 長期的な影響については、今はまだ見守る必要があります。中期的には、機能の劣るツールで我慢せざるを得ない状況にあります。おそらく、古株の開発者(私もその一人)は新しいツールの使い方を教える必要があるでしょう。

 しかし、SCM間で構文の違いが多々あるからということではありません。新しい仕事の仕方と新しい制約(そして、おそらくは、かつてあった制約からの解放も)に適応するいうことです。BKも独自の開発モデルを前提に作られていますから、やはりそれなりの制約がありました。どのSCMツールにも何らかの「世界観」があり、それに慣れるには時間がかかるということです。

 NewsForge:この別離は不可避だったのでしょうか。それとも、避けられるものだったのでしょうか。

 Torvalds:いずれ別離は避けられなかったと皆さんは考えているでしょうね。しかし、オープンソースのSCMは広がらない、広がるにはいずれ切り替えねばならなくなるような明白な理由が必要だとは皆さんも考えていないでしょう。

 しかし、1年か2年後であれば、もっとずっと痛みは少なかったろうとは思います。それが、唯一残念な点です。この3年間は非常に生産的でしたし、私たちはSCMの機能について学びましたが、私たちもSCMの持つべき機能について多くの人たちに教えました。ですから、BKを使ったのは時間の無駄だったというのは、明らかに偏った意見です。BKは役に立ったのです。

Tridgeの立場

 今回の出来事で悪役を演じたのは、間違いなくTridgeである。そのTridgeに意見を求めたが、Tridgeは次のように答えるしかなかった。

 いずれ、もっと詳しく説明できる時期が来るでしょう。しかし、今は、次のように言うことしかできません。

 - 2月の下旬に、私はBitKeeperと相互運用性のあるツールを作りました。その目的は、ほかのソースコード管理ツールにエクスポートすること、そしてコミュニティに使いやすいツールを提供することにありました。

 - このツールを作る際、BitKeeperは全く使っていません。ですから、BitKeeperのライセンスには決して抵触していません。このツールの開発は、道義的にも法的にも、全く問題はありません。

終わりに

 蜜月は終わったにもかかわらず、McVoyとTorvaldsは、互いの誠実さと専門家としての誇りに対する敬意とを失っていないように思われる。Torvaldsは今もBitKeeperを高く評価し、自身のプロジェクトにとって最良のツールであると考えている。この破局は避けえたのか、避けえなかったのか。どちらにしても、プロプライエタリ・ソフトウェアとフリーソフトウェアのこの蜜月が不幸な結末に終わるのを見るのは少々悲しい。さざ波が立ったからというだけでなく、今後のパッチの扱い方が未だに確定していないという点でも。