GNU系OSSライセンスに関する一考察：企業技術者のためのOSSライセンス入門（4）（1/2 ページ）
この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。（編集部）
いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。
1つではないOSSライセンスの考え方（おさらい）
OSSライセンスのセミナーを実施すると、意外なことに「OSSライセンスの考え方は1つに限らないことが分かった」という感想をいただくことがあります。それを踏まえて前回は、これまで主になされてきた「要件」に基づく分類ではなく、「考え方」に基づいて、OSSのライセンスを3つに分類して紹介しました。その内容は以下のとおりです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
今回は、上記のうち「GNU系ライセンス」の考え方について紹介します。これは表1では「互恵のLicense」とも分類されます。ソースコードの開示を条件に、著作物を受け取った受領者にもまた、第三者に著作物を頒布（譲渡）する権利を与えるというものです。つまり、ソースを受け取ったら、自らもソースを与えるという「互恵の関係」を求めるライセンスです。Copyleft（コピーレフト）とも表現されます。
2種類あるGNU系ライセンス
GNU系のOSSライセンスのうち主なものには、以下の2つがあります。
- GNU General Public License（GPL）：
コンパイラの「GCC」、エディタの「Emacs」のほか「Linuxカーネル」などで採用されているライセンスです。 - GNU Lesser General Public License（LGPL）：
標準Cライブラリの「glibc」、オフィススイートの「OpenOffice.org」などで採用されているライセンスです。
このうち、GCC、Emacs、glibcはGNU project（http://www.gnu.org/index.ja.html）が開発したものです。LinuxカーネルおよびOpenOffice.orgはその後に開発され、これらのGNU系ライセンスを採用しました。
このようにGNU系ライセンスは、もともとGNU projectが開発したフリーソフトウェア（OSS）を、同projectが望む形で扱ってほしいと考えために作り出されたライセンスなのです。
GNU GPLが生まれた経緯
1980年代前半、Richard M. Stallman氏がMIT AI研究所に在籍していました。当時、MIT製のX11が商用製品に組み込まれ、バイナリコードのみが配布されるという状況を見て、苦々しく思ったそうです。
もともとX11はMITで開発され、使用許諾条件付きでフリーソフトウェアとしてリリースされましたが、すぐに多くのコンピュータ関連企業によって採用されました。彼らはXを自分たちの独占的なUNIXシステムにバイナリ形式で組み込み、同じく非開示契約によって覆ってしまったのです。これらのXのコピーは、UNIXと同様、もはやフリーソフトウェアではなくなりました。
また、それまでソースコードを共有してお互いに助け合っていた開発者たちが次々に企業に取り込まれたため、コミュニティが成り立たなくなってしまいました（「The GNU Project」の「プログラムはどのユーザーにもフリーなの？」参照）。
そこで、もう一度、ソフトウェア共有コミュニティを作るために、前回紹介した「ソフトウェアの4つの自由（フリー）」を実現するフリーソフトウェアの開発を始めたことがGNU projectの始まりだそうです。
このソフトウェアの自由を守るために、つまり、フリーソフトウェアがプロプライエタリな商用プログラムに取り込まれてしまわないために生み出したのがGPLというライセンスといえます。
GNU系ライセンスはデバッグのため!?
繰り返しますが、ソフトウェアの4つの自由とは以下のとおりです。
- 使用（実行）の自由
- （ソースコードの）改変の自由
- （ソースコードの）再頒布の自由
- （ソースコード改変点の）公表の自由
これらを分かりやすく理解するために、私は
「デバッグのために必要なソースを得られる状況にするためのもの」
と説明しています。
プログラマーならば、ソフトウェアを実行するのは当たり前として、実行してみたら不具合が気になった、機能不足が気になった、という経験を何度もしたことがあるでしょう。時には「ソースコードさえ手に入ればデバッグして改造するのに……」と思うかもしれません。
こんなふうに、実行形式のバイナリコードを受け取っても、ソースコードが手に入らないがために歯がゆい思いをしないために考えられたライセンスがGNU GPLである、と解釈すると、GPLが求めている条件の内容が想像しやすいかと思います。
デバッグに必要なソースという観点で見ると、FAQに書かれるまでもなく、以下のような要件も推測できると思います。
- 開示（注1）するソースコードの範囲は、.cファイルや.hファイルなどのプログラムコード本体のみならず、配布したバイナリコードを再現するために必要となるmakeファイルやconfigureファイルといった設定ファイルも含まれる。
- デバッグを行うためには、GPLのプログラムを呼び出すプログラム、またはGPLのプログラムから呼び出されるプログラムのソースコードもまた分析する必要がある。このためそうしたソースコードの開示も求める。
- そもそもGPLが伝播する範囲は「1つの著作物のまとまり」といえる範囲です。これは「デバッグに必要な1つのプログラムの単位」と一致しますし、そう考えるのが理にかなっているでしょう。
- デバッグが目的となるのですから、ソースコードを必要とするのは、あくまでも「バイナリコードを受け取り、その実行に際して困っている人」です。
- GNU GPLの第3項では、オブジェクトコードないし実行形式で複製または頒布する際の条件として「以下のうちどれか1つを実施しなければならない」と複数の条件が挙げられています。その最初の条件が「a）著作物に、『プログラム』に対応した完全かつ機械で読み取り可能なソースコードを添付する」であり、ソースコードをバイナリとともに頒布することが条件になっているということが自然に受け入れられるかと思います。
注1：私は「ソースの公開」ではなく「ソースの開示」という表現を用いることにしています。GNU GPLの第3項を読むと分かるように、条文上は、ソースを広くWebなどで公開することまでは直接求めていないからです。しかし、バイナリの入手者がソースの開示を受け、それを二次的にWebなどに公開することを禁止することはできません。
Copyright © ITmedia, Inc. All Rights Reserved.