Woodford氏はMEPISディストリビューションの設立者であるが、おそらく現在の同氏の心を占めている思いは、最新リリースの仕上げに専念したい、という願いであろう。License(GPL)に違反している、というものであった。Woodford氏はこの督促に従う気ではあるのだが、同時に懸念しているのはこうした要求が及ぼす影響であり、他のディストリビューションをベースに二次的に構築されたディストリビューション、特に1人か2人程度のメンバが余暇を利用して運営されているようなケースはどうなるのか、というものである。ソースコードの公開という規約は、GPLバージョン2のセクション3に規定されている。このセクションの記載に従うと、GPLコードを配布する場合は「ソフトウェアの交換で習慣的に使われる媒体」を使用してソースコードを最大3年間公開する義務を負うことになる。実際問題として、ここに書かれている媒体とは、CDかDVD、あるいはダウンロード用のサーバが該当するのが普通だ。GPLのセクション6によると、こうしたコードを配布する者は自動的にセクション3の義務を負うことになる。ちなみに草案段階にあるGPLバージョン3のセクション10では、こうした義務はより明確に規定されており、“ダウンストリームユーザ”(Woodford氏のように、“アップストリームディストリビュータ”である他のプロジェクトの成果を流用する者)を特定した上で、先のような義務が課されることが明示されている。Turner氏は、「その辺は、非常に明確であると私どもは考えています」と語る。「公開されるソースコードの二次的使用の許可に関する問題の1つに、アップストリームディストリビュータにソースコードの継続的な公開を要求する規約が存在しないことがあります。公開を停止されたソースコードは、その後の入手が完全に不可能になってしまいますからね。それと、もっと一般的に起こっているのは、アップストリームディストリビュータがソースコードをアップグレードする際に、結果としてダウンストリームディストリビュータとの同期が取れなくなることに無頓着だということです。そのためユーザがバグフィックスをする場合には、手元にあるバイナリと正確に対応するソースコードを自力で探し出さなければなりません」。現状でWoodford氏の手がけたMEPISの再構成カーネルに関するソースコードは、Debianのソースパッケージとして公開されている。同氏の犯した過ちは、何らかの場所でソースコードが入手可能な状態にさえなっていれば、新たな改訂を施さない限り自分自身でソースコードを提供する必要はないはずだと理解していた事に起因するようである。同氏は他の配布元とコンタクトしたことはないが、このように理解していた人間は自分1人ではないはずだと考えている。「私を含めておそらく10,000人くらいが、自分たちはアップストリームディストリビューションのオンライン公開についての免責条項が適用されているはずだと思いこんでいたでしょうね」、とWoodford氏は語る。「DistroWatchに登録されている500のディストリビューションのうち、今現在でおそらく450くらいはこの問題に引っかかっていると思いますよ」。免責条項とは法律用語の1つで、この場合は善意に基づく違反行為であるため、本来課されるべき責任が免除されることを意味する。問題の規約に対するコミュニティの受け止め方Woodford氏の発言は、基本的には正しいのであろうが、その一方で誇張されすぎている面もあるようだ。Knopper氏は、自前のソースコードのリポジトリを用意しており、要求され次第ソースコードを提供するための準備は整っていると語っている。Hughes氏も、「これまでもCentOSのディストリビューションでは、変更前後のものも含めて、すべてのパッケージのソースを公開しております。今回のGPLの件に関して言えば、以前よりCentOSはFSFと同じ考えに基づいて活動してきました」としている。PCLinuxOSのメンテナを務めるTexstar氏も、「GPLの規約は知っていたので、すべてのソースコードをDVDで入手できるようにしてありますし、フリーサーバからのダウンロードもできるようになっています」と語っている。言うものの、大多数のディストリビューションおよびそのディストリビュータは、こうした要件が自分たちに課されていることを自覚していないようである。Andrews氏はこう語る。「もっとも、今では既に対応済みです。FSFもちょくちょく電子メールで、そうするよう通知してきますし」。同様にLinuxCD.orgというディストリビュータもソースコードの公開を実施しているが、それは具体的に要求されたFedoraに関するものだけであり、その他のものについてこうした措置は執っていない。予想に違わず、現状で規約に準拠していないディストリビューションは、この件に関する態度をはっきりさせる気はないようである。DistroWatchのトップ100の中からランダムに2ダース分の中小ディストリビューションを選択して、そのWebページを探索してみたところ、ソースコードのダウンロード用リポジトリを用意していたところは数件でしかなく、要求されれば提供するとしていたところは0件であった。規約を遵守している者が極めて少数であるという現状は、これらのメンテナたちは自分たちが規約に違反していることに気づいても、それを公にしたくはないという意識があることを伺わせ、ある意味非常に大きな問題かもしれない。規模の小さいところにとっては、こうした要求に応えるよりも、本来の作業に集中したいというのが本当のところかもしれないが。いう訳で、先のWoodford氏の掲げた数字は不正確なものであるにしても、ディストリビューションの大多数はGPLに定められた要件そのものを知らない、という同氏の主張はどうやら核心をついているようである。想定される問題とその対策Woodford氏は現在、必要な要件を満たすための準備を進めている。「協力するか対決するかのどちらかを選べと言われれば、協力する方がずっと簡単です」というのが同氏の説明だ。「私はこの活動で、1円たりとも稼いでいる訳ではないですから。弁護士を雇うなんて無理ですしね。別に収入はありますが、ギリギリのところで生活してるようなもんです。要求されればそれに従いますよ。あの要請はGPLのライセンスに反している訳でもないみたいですし」。Woodford氏の考えによると、FSFは断固として遵守させる気構えにあるようだが、同時にMEPISに対する指示にはある程度の配慮も感じられる、とのことだ。「仮に私たちが大手の企業であったなら、彼らは違反金の支払いを要求するでしょうね」と同氏は語る。恭順の意志は固めているものの、Woodford氏には払拭しきれない懸念が残されている。それと言うのもTurner氏の説明によると、MEPISはオンラインおよびCD/DVDでの配布も行っているため、GPLバージョン2のセクション3bに従う限りではいずれか一方の媒体でソースコードの公開を行えばよいのに対して、バージョン3が適用された暁にはこれらすべての媒体で同じ事を行う必要があるというのだ。Woodford氏は、MEPISがUbuntuディストリビューションで使用しているパッケージのみを定期的に自動抽出する方式の実現性についても検討しているとのことだ。重要な問題点としてWoodford氏は、「こうした行為は、おそらくオープンソースコミュニティの生産活動に悪影響を及ぼすのではないでしょうか。喜んでGPL側の取締官になります、という人間は大勢います。した人間の中には、これを伝家の宝刀として振り回し、新規のリリース活動すべてに口出しをしてくる輩もでてくるはずです」と指摘している。「コミュニティ全体のメリットとなるのは、可能であるならばですが、弱者に対する例外事項を設けることですね」とWoodford氏は語る。こんな状況で、例外を作るなんてできるんでしょうかね?」。GPLバージョン3におけるこうした例外事項の可能性についてTurner氏に質問したところ、「そうした意見が提出されれば、もちろん検討にかけるでしょう。実現する可能性となると......。Stallman氏に問い合わせたことがあるのです。した要求は厄介なだけだというのが同氏の見解で、ソースコードの方がバイナリよりも小さいはずだ、というものでした」という回答が得られた。この点に関してWoodford氏の意見は異なっている。「もし私がMEPISを手がけようとした矢先にこの話を聞かされていたなら、さっさと手を引いていたでしょうね。自前のサーバもリポジトリも運用していない人間に、そんなことを要求されても、いらぬ仕事が増えるだけです」。同氏が懸念しているのは、自分と同じく意欲をそがれる人間が他にもいるのではないかということだ。Linuxに携わるAndrews氏も、TurnerおよびStallmanの両氏に同意しかねている1人で、「FSFが弱小ディストリビュータであろうとも規則の準拠を求めるのは理解できます。言うものの、私の経験からして、趣味でやっている人間や小規模な開発者にとっては負担が大きすぎるでしょう。彼らは、大手企業のような資金も組織力とも無縁だけど、自分の手がけたクールなソフトを他の人にも使ってもらおうという心意気で動いているのですから」と語っている。「非営利のディストリビュータならば、アップストリームディストリビュータに応援を求めて、ソースコードの手配に関する支援を依頼することも可能でしょう」とTurner氏は提案する。「そうした協力体制が確立できれば、先のような問題は起こらないはずですし、非営利のディストリビュータにとっても時間や作業面での節約になるはずです」。した協力体制が成立する上での最大の問題は、大手のアップストリームディストリビュータ側が乗り気薄なことだろう。1つの好例は、先にも取り上げたFedoraである。Spevack氏はこう語っている。Projectがダウンストリームディストリビューションに対してアップストリームのコードリポジトリを参照することを公式に認可することは、いくつかの理由から二の足を踏んでいます。第1に、コードのフォーキングという問題に対処する必要があるからです。ダウンストリーム側の開発者が何らかの改変を施した場合、そうした変更点は可能な限りアップストリーム側のコードにも反映させる必要が生じてきます。ダウンストリーム側の人間がアップストリーム側への反映をする気がないのであれば、フォーキングで生じたソースコードの再配布に関する負担をダウンストリームディストリビューションが負うことになるのは当然の成り行きです」。Spevack氏はさらに続けて「第2は、法的な責任負担の問題です」と説明している。Projectの望むところではありません」。「第3は、コストに関する問題です。これは無視し得ない要素ではありますが、私個人としては、先の2つほどの重要度があるとは思っていません」。Onlineを利用することだろう。これはConaryパッケージングシステムのリポジトリを用いて独自のディストリビューションを作成するためのツールで、非商用目的であればフリーで使用できる。Troan氏が言うところの「バイナリとソースに対して恒久的なアクセスができるので、rBuilderを使えば問題が自動的に解消されてしまいます」という状況になる。rBuilderを用いてディストリビューションを構築しても、各自が自分のリポジトリの維持をする必要は依然として残されるが、ソースリポジトリを個別に運用する負担からは解放されるはずだ。Linuxの採用しているソリューションでもある。Onlineは使用できないし、Conaryについても新興のパッケージングシステムである分だけ、比較的未知の部分があるのも事実だ。した状況は、規則として定められた条文の前には善意や創造性などは取るに足らない問題と化す世界において、多くの派生ディストリビューションが孤立無援な状態に追いやられていると見なせるだろう。Woodford氏に話を戻すと、同氏にとって次回リリースの用意を進めながら余分な追加要件を満たすという作業は、非常に大きな負担となっているのが実状だそうだ。「今は、何とかまともな睡眠が取れそうな状況に復帰しようと、色々あくせくしているところです」とWoodford氏は語る。「昨日の夜にベッドに潜り込めたのは夜中の1時30分でしたが、横になってからもGPL関連の専門用語が頭の中を駆けめぐっており、後はどうやってソースを入手して配布できるようにするかばかり考えていました」。Byfieldは、コースデザイナ兼インストラクタ。Journalに定期的に寄稿している。