GNU系OSSライセンスに関する一考察：企業技術者のためのOSSライセンス入門（4）（2/2 ページ）
この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。（編集部）
GNU LGPLが産まれた経緯
LGPLは、v2.1では「Lesser GPL」と表記します。ところがv2.0では「Library GPL」という名称でした。
名称が変更になったのにはいくつか理由があります。「ライブラリ形式のフリーソフトウェアは無条件に、GPLではなくLGPLを採用するものだ」という誤解を与えないようにすることが1つです。もう1つは、ソフトウェアによっては、本来ならばライセンスをGPLにしたいけれど、戦略的に譲歩して一段劣等（Lesser）な「フリー」とすることがあります。そうした際に、あくまでも「仕方なく」LGPLにしているのだというニュアンスを明確に表すためです。
この辺りの詳しい説明は、「あなたの次のライブラリにはライブラリGPLを適用するべきでない理由」をご覧ください。
では、なぜ、わざわざ劣等なGPL（＝LGPL）というライセンスを作成したのでしょうか。Linuxもなかった当時は、商用UNIX上でフリーソフトウェアを普及させる必要があったからだそうです。この目的を達成するには、厳密なGPLの適用を求めるよりも一部妥協する方が妥当であるという戦略に基づき、自由という意味では一段劣った（＝Lesser）LGPLというライセンスを作ったわけです。
自由にデバッグを行うためには、LGPLのプログラム本体だけではなく、それを呼び出すプログラム、またはLGPLのプログラムから呼び出されるプログラムのソースコードもまた分析する必要があります。しかし、それらすべてについてソースコードの開示を求めていては、敬遠される可能性があります。周りがGNU以外のプログラムばかりのときにはなおさらです。
そのため、利用プログラムのソース開示までは求めないが、デバッグのためのリバースエンジニアリングだけは許可することを求めるのがLGPLのライセンスである、と推察すると理解しやすいかと思います（注2）。
6. 上記各節の例外として、あなたは「『ライブラリ』を利用する著作物」を『ライブラリ』と結合またはリンクして、『ライブラリ』の一部を含む著作物を作成し、その著作物をあなたが選んだ条件の下で頒布することもできる。ただしその場合、あなたの条件は顧客自身の利用のための著作物の改変を許可し、またそのような改変をデバッグするためのリバースエンジニアリングを許可していなければならない。
注2：GPLと異なり、LGPLでは明示的に「デバッグのため」と明記しています。
GNUのこだわり
1985年、GNU projectが提唱してきたソフトウェアの自由を守るために、FSF（Free Software Foundation）という法人が設立されました。GNU系ライセンスは、ソフトウェアの自由を守り、拡大していくこのような活動、つまり「フリーソフトウェア運動」を推進するための手段という意味を含んでいるのです。
そのため、彼らは「OSS、オープンソースソフトウェア」とはいわず、「フリーソフトウェア」と呼ぶことにこだわりがあります。
フリーソフトウェア運動という立場では、ソフトウェアの自由を阻害する要因も取り除かねばなりません。そのため、実行の自由や再頒布の自由を阻害するソフトウェア特許に反対する立場を早くから取っていることは有名です。
2007年6月にリリースされたGPL version3も、その基本的な考え方は変わりません。さらに、再頒布の自由を阻害し、コミュニティの分断を狙うソフトウェア特許や、改変したものを実行する自由を阻害するハードウェアのチェック機構によって、ソフトウェアの自由が阻害されないように条文を明確化しました。
このようにGNU系ライセンスは、ソフトウェアの自由を第一の目的としていると認識しておく必要があります。まとまった読み物として、「Think GNU — プロジェクト GNU 日記とソフトウェアの憂鬱」（ビレッジセンター出版、1993年）という書籍があり、Copyleft書籍としてフリーで読むこともできました。しかし2008年末に残念ながら出版社が解散となり、現在ではWebサイトもなくなり書籍が入手困難になっています（編集部注）。
しかし、ここまでさまざまなリンクを紹介したように、GNU関連のドキュメントはインターネット上にも数多く存在します。八田真行氏をはじめとする多くの方のご尽力により日本語訳も少なくないので、一度目を通されるとよいでしょう。
編集部注：インターネット上で検索すると、まだ本文の入手が可能なFTPサイトがあります。
GNU系ライセンス対応時の留意点
GNU系ライセンスに分類されるGPLとLGPLのライセンスの扱いについては、第2回の図2で紹介しました。その概要は以下のとおりです。
- ともに、プログラム自身のソースコードを開示する
- GPLの場合、結合著作物と見なされる利用プログラムもソースコードを開示する
- LGPLの場合、結合著作物と見なされる利用プログラムのリバースエンジニアリングを許可する
実際にこれらのライセンスを適用する場合の注意点を具体的に示してみましょう。
ソースコードの開示は「バイナリを再現できる形」で
今回は、ソースコードを開示する目的を、「デバッグのために必要なソースを得られる状況にするためのもの」と推察して説明してきました。ですから、頒布時にプログラム本体の.cファイルや.hファイルに加え、configureやmakeを実行できるソースコードツリーも含めtar.gzやzipで固めた形で配布されていたように、再頒布の際にも、入手したtar.gzの形のまま再頒布するのが自然です。
この形で配布する場合、「COPYINGファイル」や「LICENSEファイル」という形でルートディレクトリにライセンス文が格納されることになります。つまり、前回紹介したアカデミック系ライセンスの対応方法を包含したものでもあります。
ライセンス文（ファイル）は「ソースコードとともに」
自作のプログラムをGPLで新たに頒布する場合、ルートディレクトリにライセンス文のファイルを格納し忘れないようにしましょう。
中にはこの点を誤解している開発者もいらっしゃるようです。というのも、GPLライセンス文書の最後には「あなたはこのプログラムとともに、GNU一般公衆利用許諾契約書の複製物を一部受け取ったはずです。もし受け取っていなければ、フリーソフトウェア財団まで請求してください（あて先は the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA）」とあるためか、特に小さなプログラムでライセンス文を格納していないケースを見掛けます。また、GNUのサイトを記しているだけという間違った対応をしているプログラムも見掛けます。
GPLの条文を見直してみると、再頒布の条件として「この契約書および一切の保証の不在に触れた告知すべてをそのまま残し、そしてこの契約書の複製物を『プログラム』のいかなる受領者にも『プログラム』と共に頒布する限り」と書いてあります。つまり、初めからライセンス文が同梱されていることを前提として書かれているのです。同梱していないものは「そのまま残せ」ません。
ライセンス条文は、GNUサイトをポイントするだけなどと横着せずに、条文と矛盾しないように、きちんとソースコードとともに頒布しましょう。
また最近は、GNUサイトをポイントしたものの中には、プログラムはGPLv2で頒布したにもかかわらず、ポイント先はGPLv3になっているという矛盾を見ることがあります。著作物は頒布した時点でライセンスが決まるものです。たとえライセンス条文がバージョンアップしても、頒布済みの著作物のライセンスが勝手にバージョンアップする関係にはありません。
ソースコードはバイナリとともに
もう1つバージョンの不一致が起きやすいのが、頒布済みバイナリと開示するソースコードのバージョンの不一致です。
デバッグのためにソースコードを開示するという観点からすれば、頒布済みのバイナリが再現できなければ、たとえ最新のソースコードが開示されていても意味がありません。
その理由から私は、GPLプログラムのバイナリコードの頒布の際のソースコードの開示方法として、GPL第3項にある「b）入手先を知らせる方法」よりも、「a）添付（同梱）する方法」をお勧めしています。
a）著作物に、『プログラム』に対応した完全かつ機械で読み取り可能なソースコードを添付する。ただし、ソースコードは上記第1節および2節の条件に従いソフトウェアの交換で習慣的に使われる媒体で頒布しなければならない。あるいは、
b) 著作物に、いかなる第三者に対しても、『プログラム』に対応した完全かつ機械で読み取り可能なソースコードを、頒布に要する物理的コストを上回らない程度の手数料と引き換えに提供する旨述べた少なくとも3年間は有効な書面になった申し出を添える。ただし、ソースコードは上記第1節および2節の条件に従いソフトウェアの交換で習慣的に使われる媒 体で頒布しなければならない。
以上でGNU系ライセンスの説明を終えます。中には少々勝手な思い込みが含まれているところがあるかもしれません。実際にこれらのライセンスを利用する際にはぜひ、リンク先のGNUプロジェクトの文章を読んで、その考え方を理解したうえで利用いただければ幸いです。
次回は、OSI系OSSライセンスの考え方について推察してみたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.