SFLCの「GPL準拠のための実践ガイド」の中身
このガイドの導入部は、GPL実施の経緯について述べており、フリーソフトウェア財団（Free Software Foundation）のコンプライアンス・ラボやHarald Welte氏のgpl-violations.orgによる取り組み、そしてこの2年で拡大したSLFCの役割を中心に紹介している。ほとんどの違反は「当事者どうしの協力的な意思疎通によって」解決されている、とガイドは強調している。その理由の一端には、（ガイドにそう書いてあるわけではないが）訴訟費用の負担を避けたいという当事者組織の思惑がありそうだが、このことは、大事なのはライセンスの遵守であって損害賠償金ではないことをはっきりと示している。
こうした背景説明のあと、ガイドの内容は、違反を回避するためのベストプラクティスへと移る。最もよくある違反は、オリジナルまたは改良版のGPLコンポーネントやLGPLコンポーネントを含むオペレーティングシステムに起因したものだという。そうした違反を防ぐためにガイドが各プロジェクトに強く勧めているのは、FOSSの利用状況の把握、そしてどんなソースがどのバイナリのビルドに利用されているかの入念な監視である。またガイドは、「ビルドグル（build guru）」への依存を避けるように、とも提言している。そうした隅々までプロジェクトを把握している1、2名の人物に頼りすぎていると、彼らがプロジェクトを去るときに知識までもが失われるからだ。
続いてガイドは、GPL（およびLGPL）に伴うソースコード提供の義務を果たす何種類かの方法について述べている。このセクションは、GPLのバージョン2（GPLv2）とバージョン3（GPLv3）における許容事項の明らかな違いに注目しているほか、ソースコード提供の申し出だけを行うことの利点と欠点を提示している。途中、よく見受けられる間違った仮定もいくつか挙げられている。たとえば、顧客だけがソースコード提供の申し出を受けられるとか、ピアツーピアでソースを入手できれば非ピアツーピアソフトウェアの要件を満たす、といった考え方だ。おそらく最大の問題は、こうした申し出は多くの場合は組織が行っているにもかかわらず、だれかから要求されないとソースコード提供の手順を用意しようとしないことだろう。そして、要求が届いてから慌てて対処する破目になる。
ガイドのそれ以降の部分は、違反への対処のしかたを説明している。法的問題への発展を避けるため、違反の指摘を受けたプロジェクトは、詳しい回答を行う期日だけでもよいので、速やかに返答すべきである。また、GPLに違反した状態ではその違反に関連するソフトウェアを頒布できないことが明記され、そうなった場合に頒布の権利を回復する方法や（GPLv3における自動的な回復の規定など）、権利の回復前に著作権保有者が要求できる一般的な条件についても書かれている。ガイドの終盤には、LGPL特有の検討事項が記されているほか、たとえ下請け業者が違反してもプロジェクトの責任になるという注意事項の指摘がある。
完成版とは呼べないドラフト
ガイドのトピックは、たとえすぐにはGPL違反に関わる可能性がなくてもFOSSの法的問題に関心を持っている人であれば、興味深く読めるものが広い範囲から選ばれている。ただし、それ以外の人（特に、おそらくこのガイドの内容を最も知る必要のある人）にとっては、不必要に読みづらいものになっている。
理由の1つは、おそらく弁護士、または法律問題に日常的に携わっている人物が書いたためか、仰々しい表現が多いことにある。確かに、わかりやすい表現の模範といえる一節もあるが、読者を二人称で呼んだり簡潔で味気のない文が続いたりするので、どちらにしても多くの人は読む気力を失ってしまう。また、受動態が多用され、堅苦しい言い回しがあちこちに見られる（「～がなければ」に“without”ではなく“absent”を、「利用する」に“take advantage of”ではなく“avail”を用いるなど）。
さらに困るのは、読者はすでにこのテーマをよく知っている、という前提で書かれていることだ。そもそも最初の一文が、このガイドはGPLおよび「関連ライセンス」に関する、となっているのだが、その関連ライセンスが何を指しているのかの説明がない（実際には、LGPLだけが該当し、GNUのAffero一般公衆利用許諾契約諸［AGPL：Affero General Public License］も例外事項付きのどんなGPL系ライセンスも対象外のようだ）。「コピーレフト」や「派生著作物」の説明もなければ、フリーライセンスの厳密な目的はおろか、GPL自体の変遷についての解説もない。
このガイドには構成上の問題もある。ひどく格式張ったエグゼクティブサマリから始まっているうえに、結局どこに複雑な問題があるのかを深掘りするための文献が1つも示されていない。
しかし、構成上の問題が最も顕著に現れているのは、GPLv2およびGPLv3の下でのソースコードの頒布とその各種オプションについて述べた4番目のセクションだろう。このセクションの最初で、いつでも条項を参照できるように読者に双方のライセンスを用意するように勧めておきながら、それらへのリンクが見当たらないのだ。それにしても、これほど多くの条項が参照されていれば、このガイドを本来読むべき人々がうんざりして途中で投げ出すことは容易に想像できる。重要な条項をきちんと引用しておけば、ガイドそのものは長くなったとしても、論理の整合性はかなり高くなっていただろう。
読んだあとに何が残ったか、という点でも疑問を抱くに違いない。執筆者がこのガイドを短くまとめようとした努力は認めるが、多くのトピックは（確かに段落としては短いが）中途半端のままで終わっている。たとえば、ほとんどの違反は不慮のものだ、という意味のこと書かれているのだが、だからどうだというのだろうか。また、このガイドにはAGPLとの関連性があるのだろうか。それとも、昨年11月にリリースされたAGPLは公開から日が浅いので解説の対象外なのだろうか。また、このガイドはよくある状況にしか言及していないが、それ以外にはどんな状況があり、そうした珍しい状況が起こったときにはどうすればいいのだろうか。
「GPL準拠のための実践ガイド」は、CTO（最高技術責任者）やマネージャの啓発用としては価値があるかもしれないが、今のままだと最後まで読んでくれる人はあまりいないように思える。SFLCには、あと1、2回（欲をいえば、各トピックをある程度理解した編集者が）推敲を重ねてから公開してもらいたかった。そうすれば、企業やFOSSコミュニティの求める、わかりやすい英語で書かれた参考資料になっていただろう。現状のガイドを最後まで読んでくれる人は、おそらく最もその必要がない人に違いない。
Bruce Byfieldは、Linux.comに定期的に寄稿しているコンピュータ分野のジャーナリスト。
