GPLの規約が派生ディストリビューションに及ぼす憂慮すべき影響：Magi's View（2/2 ページ）

[Bruce-Byfield，Open Tech Press]

想定される問題とその対策

　ウッドフォード氏は現在、必要な要件を満たすための準備を進めている。「協力するか対決するかのどちらかを選べと言われれば、協力する方がずっと簡単です」というのが同氏の説明だ。「わたしはこの活動で、1円たりとも稼いでいる訳ではないですから。弁護士を雇うなんて無理ですしね。もちろん別に収入はありますが、ギリギリのところで生活してるようなもんです。要求されればそれに従いますよ。あの要請はGPLのライセンスに反している訳でもないみたいですし」。

　ウッドフォード氏の考えによると、FSFは断固として順守させる気構えにあるようだが、同時にMEPISに対する指示にはある程度の配慮も感じられる、とのことだ。「仮にわたしたちが大手の企業であったなら、彼らは違反金の支払いを要求するでしょうね」と同氏は語る。

　すでに恭順の意思は固めているものの、ウッドフォード氏には払拭しきれない懸念が残されている。それと言うのもターナー氏の説明によると、MEPISはオンラインおよびCD/DVDでの配布も行っているため、GPLバージョン2のセクション3bに従う限りではいずれか一方の媒体でソースコードの公開を行えばよいのに対して、バージョン3が適用された暁にはこれらすべての媒体で同じことを行う必要があるというのだ。またウッドフォード氏は、MEPISがUbuntuディストリビューションで使用しているパッケージのみを定期的に自動抽出する方式の実現性についても検討しているとのことだ。

　より重要な問題点としてウッドフォード氏は、「こうした行為は、おそらくオープンソースコミュニティーの生産活動に悪影響を及ぼすのではないでしょうか。喜んでGPL側の取締官になります、という人間は大勢います。そうした人間の中には、これを伝家の宝刀として振り回し、新規のリリース活動すべてに口出しをしてくる輩もでてくるはずです」と指摘している。

　「コミュニティー全体のメリットとなるのは、可能であるならばですが、弱者に対する例外事項を設けることですね」とウッドフォード氏は語る。「しかし、GPLを使用するすべての団体および個人は等しく同じ規則や基準に縛られるという前提の下で構成されている世界で、いったい何ができるというのでしょうか？　こんな状況で、例外を作るなんてできるんでしょうかね？」。

　GPLバージョン3におけるこうした例外事項の可能性についてターナー氏に質問したところ、「そうした意見が提出されれば、もちろん検討にかけるでしょう。しかし、実現する可能性となると……。実はわたしも、同じことをリチャード・ストールマン氏に問い合わせたことがあるのです。そうした要求は厄介なだけだというのが同氏の見解で、ソースコードの方がバイナリよりも小さいはずだ、というものでした」という回答が得られた。

　この点に関してウッドフォード氏の意見は異なっている。「もしわたしがMEPISを手掛けようとした矢先にこの話を聞かされていたなら、さっさと手を引いていたでしょうね。自前のサーバもリポジトリも運用していない人間に、そんなことを要求されても、いらぬ仕事が増えるだけです」。同氏が懸念しているのは、自分と同じく意欲をそがれる人間がほかにもいるのではないかということだ。

　Damn Small Linuxに携わるアンドリュー氏も、ターナーおよびストールマンの両氏に同意しかねている1人で、「FSFが弱小ディストリビューターであろうとも規則の準拠を求めるのは理解できます。そうは言うものの、わたしの経験からして、趣味でやっている人間や小規模な開発者にとっては負担が大きすぎるでしょう。彼らは、大手企業のような資金も組織力とも無縁だけど、自分の手掛けたクールなソフトをほかの人にも使ってもらおうという心意気で動いているのですから」と語っている。

　「非営利のディストリビューターならば、アップストリームディストリビューターに応援を求めて、ソースコードの手配に関する支援を依頼することも可能でしょう」とターナー氏は提案する。「そうした協力体制が確立できれば、先のような問題は起こらないはずですし、非営利のディストリビューターにとっても時間や作業面での節約になるはずです」。

　こうした協力体制が成立する上での最大の問題は、大手のアップストリームディストリビューター側が乗り気薄なことだろう。1つの好例は、先にも取り上げたFedoraである。実際Fedora Boardの議長を務めるマックス・スペバック氏はこう語っている。「Fedora Projectがダウンストリームディストリビューションに対してアップストリームのコードリポジトリを参照することを公式に認可することは、幾つかの理由から二の足を踏んでいます。第1に、コードのフォーキングという問題に対処する必要があるからです。ダウンストリーム側の開発者が何らかの改変を施した場合、そうした変更点は可能な限りアップストリーム側のコードにも反映させる必要が生じてきます。そしてダウンストリーム側の人間がアップストリーム側への反映をする気がないのであれば、フォーキングで生じたソースコードの再配布に関する負担をダウンストリームディストリビューションが負うことになるのは当然の成り行きです」。

　同氏はさらに続けて「第2は、法的な責任負担の問題です」と説明している。「ダウンストリーム側での変更に関する法的責任もアップストリーム側に課されてくるでしょうが、そうした事態はFedora Projectの望むところではありません」。

　「第3は、コストに関する問題です。最もこれは無視し得ない要素ではありますが、わたし個人としては、先の2つほどの重要度があるとは思っていません」。

　ディストリビューションの形態にもよるが、考えられる1つのソリューションは、rPathの提供するrBuilder Onlineを利用することだろう。これはConaryパッケージングシステムのリポジトリを用いて独自のディストリビューションを作成するためのツールで、非商用目的であればフリーで使用できる。Conaryリポジトリの特徴の1つは、独自のバージョン管理システムを用いることでソースおよびバイナリパッケージの双方を管理できることであり、rPathの設立者の1人であるErik Troan氏が言うところの「バイナリとソースに対して恒久的なアクセスができるので、rBuilderを使えば問題が自動的に解消されてしまいます」という状況になる。最もrBuilderを用いてディストリビューションを構築しても、各自が自分のリポジトリの維持をする必要は依然として残されるが、ソースリポジトリを個別に運用する負担からは解放されるはずだ。実際、これはForesight Linuxの採用しているソリューションでもある。ただし、商用ディストリビューションの場合rBuilder Onlineは使用できないし、Conaryについても新興のパッケージングシステムである分だけ、比較的未知の部分があるのも事実だ。

　こうした状況は、規則として定められた条文の前には善意や創造性などは取るに足らない問題と化す世界において、多くの派生ディストリビューションが孤立無援な状態に追いやられていると見なせるだろう。

　ウッドフォード氏に話を戻すと、同氏にとって次回リリースの用意を進めながら余分な追加要件を満たすという作業は、非常に大きな負担となっているのが実状だそうだ。「今は、何とかまともな睡眠が取れそうな状況に復帰しようと、いろいろあくせくしているところです」とウッドフォード氏は語る。「昨日の夜にベッドに潜り込めたのは夜中の1時30分でしたが、横になってからもGPL関連の専門用語が頭の中を駆けめぐっており、後はどうやってソースを入手して配布できるようにするかばかり考えていました」。

Bruce Byfieldのプロフィール：コースデザイナー兼インストラクター。またコンピュータジャーナリストとしても活躍しており、NewsForge、Linux.com、IT Manager's Journalに定期的に寄稿している。

原文へのリンク