Tweet

第4回　GNU系OSSライセンスに関する一考察

　いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。

1つではないOSSライセンスの考え方（おさらい）

　OSSライセンスのセミナーを実施すると、意外なことに「OSSライセンスの考え方は1つに限らないことが分かった」という感想をいただくことがあります。それを踏まえて前回は、これまで主になされてきた「要件」に基づく分類ではなく、「考え方」に基づいて、OSSのライセンスを3つに分類して紹介しました。その内容は以下のとおりです。

　今回は、上記のうち「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つの自由とは以下のとおりです。

1. 使用（実行）の自由
2. （ソースコードの）改変の自由
3. （ソースコードの）再頒布の自由
4. （ソースコード改変点の）公表の自由

これらを分かりやすく理解するために、私は

「デバッグのために必要なソースを得られる状況にするためのもの」

と説明しています。

　プログラマーならば、ソフトウェアを実行するのは当たり前として、実行してみたら不具合が気になった、機能不足が気になった、という経験を何度もしたことがあるでしょう。時には「ソースコードさえ手に入ればデバッグして改造するのに……」と思うかもしれません。

　こんなふうに、実行形式のバイナリコードを受け取っても、ソースコードが手に入らないがために歯がゆい思いをしないために考えられたライセンスがGNU GPLである、と解釈すると、GPLが求めている条件の内容が想像しやすいかと思います。

　デバッグに必要なソースという観点で見ると、FAQに書かれるまでもなく、以下のような要件も推測できると思います。

• 開示（注1）するソースコードの範囲は、.cファイルや.hファイルなどのプログラムコード本体のみならず、配布したバイナリコードを再現するために必要となるmakeファイルやconfigureファイルといった設定ファイルも含まれる
  
  
• デバッグを行うためには、GPLのプログラムを呼び出すプログラム、またはGPLのプログラムから呼び出されるプログラムのソースコードもまた分析する必要がある。このためそうしたソースコードの開示も求める。
  
  そもそもGPLが伝播する範囲は「1つの著作物のまとまり」といえる範囲です。これは「デバッグに必要な1つのプログラムの単位」と一致しますし、そう考えるのが理にかなっているでしょう。
  
  
• デバッグが目的となるのですから、ソースコードを必要とするのは、あくまでも「バイナリコードを受け取り、その実行に際して困っている人」です。
  
  GNU GPLの第3項では、オブジェクトコードないし実行形式で複製または頒布する際の条件として「以下のうちどれか1つを実施しなければならない」と複数の条件が挙げられています。その最初の条件が「a）著作物に、『プログラム』に対応した完全かつ機械で読み取り可能なソースコードを添付する」であり、ソースコードをバイナリとともに頒布することが条件になっているということが自然に受け入れられるかと思います。

第3回へ

1/2

Index 技術者による技術者のためのOSSライセンス入門 　第4回　GNU系OSSライセンスに関する一考察

Page 1 1つではないOSSライセンスの考え方（おさらい） 2種類あるGNU系ライセンス GNU GPLが生まれた経緯 GNU系ライセンスはデバッグのため!? 　 Page 2 GNU LGPLが産まれた経緯 GNUのこだわり GNU系ライセンス対応時の留意点

Linux Square全記事インデックス

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード