ソースコードの公開という規約は、GPLバージョン2のセクション3に規定されている。このセクションの記載に従うと、GPLコードを配布する場合は「ソフトウェアの交換で習慣的に使われる媒体」を使用してソースコードを最大3年間公開する義務を負うことになる。実際問題として、ここに書かれている媒体とは、CDかDVD、あるいはダウンロード用のサーバが該当するのが普通だ。またGPLのセクション6によると、こうしたコードを配布する者は自動的にセクション3の義務を負うことになる。ちなみに草案段階にあるGPLバージョン3のセクション10では、こうした義務はより明確に規定されており、“ダウンストリームユーザ”（Woodford氏のように、“アップストリームディストリビュータ”である他のプロジェクトの成果を流用する者）を特定した上で、先のような義務が課されることが明示されている。
FSFでGPLコンプライアンスエンジニアを務めるDavid Turner氏は、「その辺は、非常に明確であると私どもは考えています」と語る。「公開されるソースコードの二次的使用の許可に関する問題の1つに、アップストリームディストリビュータにソースコードの継続的な公開を要求する規約が存在しないことがあります。公開を停止されたソースコードは、その後の入手が完全に不可能になってしまいますからね。それと、もっと一般的に起こっているのは、アップストリームディストリビュータがソースコードをアップグレードする際に、結果としてダウンストリームディストリビュータとの同期が取れなくなることに無頓着だということです。そのためユーザがバグフィックスをする場合には、手元にあるバイナリと正確に対応するソースコードを自力で探し出さなければなりません」。
現状でWoodford氏の手がけたMEPISの再構成カーネルに関するソースコードは、Debianのソースパッケージとして公開されている。同氏の犯した過ちは、何らかの場所でソースコードが入手可能な状態にさえなっていれば、新たな改訂を施さない限り自分自身でソースコードを提供する必要はないはずだと理解していた事に起因するようである。同氏は他の配布元とコンタクトしたことはないが、このように理解していた人間は自分1人ではないはずだと考えている。「私を含めておそらく10,000人くらいが、自分たちはアップストリームディストリビューションのオンライン公開についての免責条項が適用されているはずだと思いこんでいたでしょうね」、とWoodford氏は語る。「DistroWatchに登録されている500のディストリビューションのうち、今現在でおそらく450くらいはこの問題に引っかかっていると思いますよ」。
免責条項とは法律用語の1つで、この場合は善意に基づく違反行為であるため、本来課されるべき責任が免除されることを意味する。
問題の規約に対するコミュニティの受け止め方
Woodford氏の発言は、基本的には正しいのであろうが、その一方で誇張されすぎている面もあるようだ。例えば、よく知られたKnoppix live CDの開発者であるKlaus Knopper氏は、自前のソースコードのリポジトリを用意しており、要求され次第ソースコードを提供するための準備は整っていると語っている。またCentOSを代表するJohnny Hughes氏も、「これまでもCentOSのディストリビューションでは、変更前後のものも含めて、すべてのパッケージのソースを公開しております。今回のGPLの件に関して言えば、以前よりCentOSはFSFと同じ考えに基づいて活動してきました」としている。同じくPCLinuxOSのメンテナを務めるTexstar氏も、「GPLの規約は知っていたので、すべてのソースコードをDVDで入手できるようにしてありますし、フリーサーバからのダウンロードもできるようになっています」と語っている。
とは言うものの、大多数のディストリビューションおよびそのディストリビュータは、こうした要件が自分たちに課されていることを自覚していないようである。「FSFからの通知が届くまで、自分たちが改変していないバイナリのソースコードまで公開する義務があるなんて、思いもしませんでした」と、Damn Small Linuxのメンテナを務めるJohn 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を使用するすべての団体および個人は等しく同じ規則や基準に縛られるという前提の下で構成されている世界で、一体何ができるというのでしょうか？ こんな状況で、例外を作るなんてできるんでしょうかね？」。
GPLバージョン3におけるこうした例外事項の可能性についてTurner氏に質問したところ、「そうした意見が提出されれば、もちろん検討にかけるでしょう。しかし、実現する可能性となると……。実は私も、同じ事をRichard Stallman氏に問い合わせたことがあるのです。そうした要求は厄介なだけだというのが同氏の見解で、ソースコードの方がバイナリよりも小さいはずだ、というものでした」という回答が得られた。
この点に関してWoodford氏の意見は異なっている。「もし私がMEPISを手がけようとした矢先にこの話を聞かされていたなら、さっさと手を引いていたでしょうね。自前のサーバもリポジトリも運用していない人間に、そんなことを要求されても、いらぬ仕事が増えるだけです」。同氏が懸念しているのは、自分と同じく意欲をそがれる人間が他にもいるのではないかということだ。
Damn Small Linuxに携わるAndrews氏も、TurnerおよびStallmanの両氏に同意しかねている1人で、「FSFが弱小ディストリビュータであろうとも規則の準拠を求めるのは理解できます。そうは言うものの、私の経験からして、趣味でやっている人間や小規模な開発者にとっては負担が大きすぎるでしょう。彼らは、大手企業のような資金も組織力とも無縁だけど、自分の手がけたクールなソフトを他の人にも使ってもらおうという心意気で動いているのですから」と語っている。
「非営利のディストリビュータならば、アップストリームディストリビュータに応援を求めて、ソースコードの手配に関する支援を依頼することも可能でしょう」とTurner氏は提案する。「そうした協力体制が確立できれば、先のような問題は起こらないはずですし、非営利のディストリビュータにとっても時間や作業面での節約になるはずです」。
こうした協力体制が成立する上での最大の問題は、大手のアップストリームディストリビュータ側が乗り気薄なことだろう。1つの好例は、先にも取り上げたFedoraである。実際Fedora Boardの議長を務めるMax Spevack氏はこう語っている。「Fedora Projectがダウンストリームディストリビューションに対してアップストリームのコードリポジトリを参照することを公式に認可することは、いくつかの理由から二の足を踏んでいます。第1に、コードのフォーキングという問題に対処する必要があるからです。ダウンストリーム側の開発者が何らかの改変を施した場合、そうした変更点は可能な限りアップストリーム側のコードにも反映させる必要が生じてきます。そしてダウンストリーム側の人間がアップストリーム側への反映をする気がないのであれば、フォーキングで生じたソースコードの再配布に関する負担をダウンストリームディストリビューションが負うことになるのは当然の成り行きです」。
Spevack氏はさらに続けて「第2は、法的な責任負担の問題です」と説明している。「ダウンストリーム側での変更に関する法的責任もアップストリーム側に課されてくるでしょうが、そうした事態はFedora Projectの望むところではありません」。
「第3は、コストに関する問題です。もっともこれは無視し得ない要素ではありますが、私個人としては、先の2つほどの重要度があるとは思っていません」。
ディストリビューションの形態にもよるが、考えられる1つのソリューションは、rPathの提供するrBuilder Onlineを利用することだろう。これはConaryパッケージングシステムのリポジトリを用いて独自のディストリビューションを作成するためのツールで、非商用目的であればフリーで使用できる。Conaryリポジトリの特長の1つは、独自のバージョン管理システムを用いることでソースおよびバイナリパッケージの双方を管理できることであり、rPathの設立者の1人であるErik Troan氏が言うところの「バイナリとソースに対して恒久的なアクセスができるので、rBuilderを使えば問題が自動的に解消されてしまいます」という状況になる。もっともrBuilderを用いてディストリビューションを構築しても、各自が自分のリポジトリの維持をする必要は依然として残されるが、ソースリポジトリを個別に運用する負担からは解放されるはずだ。実際、これはForesight Linuxの採用しているソリューションでもある。ただし、商用ディストリビューションの場合rBuilder Onlineは使用できないし、Conaryについても新興のパッケージングシステムである分だけ、比較的未知の部分があるのも事実だ。
こうした状況は、規則として定められた条文の前には善意や創造性などは取るに足らない問題と化す世界において、多くの派生ディストリビューションが孤立無援な状態に追いやられていると見なせるだろう。
Woodford氏に話を戻すと、同氏にとって次回リリースの用意を進めながら余分な追加要件を満たすという作業は、非常に大きな負担となっているのが実状だそうだ。「今は、何とかまともな睡眠が取れそうな状況に復帰しようと、色々あくせくしているところです」とWoodford氏は語る。「昨日の夜にベッドに潜り込めたのは夜中の1時30分でしたが、横になってからもGPL関連の専門用語が頭の中を駆けめぐっており、後はどうやってソースを入手して配布できるようにするかばかり考えていました」。
Bruce Byfieldは、コースデザイナ兼インストラクタ。またコンピュータジャーナリストとしても活躍しており、NewsForge、Linux.com、IT Manager's Journalに定期的に寄稿している。