第2回 オープンソースライセンス事情を俯瞰する：新入学生／新社会人応援企画第2弾（2/2 ページ）

[ITmedia]

ライブラリなどに用いられるLGPL

　LGPLは「GNU Lesser General Public License」の略称で、GPLよりも若干緩やかな制限を持つライセンスだ。例えば圧縮やファイル操作などといった、基本的な機能を提供するライブラリに適用されるライセンスとなっている。

http://www.gnu.org/copyleft/lesser.ja.html

　GPLとLGPLの違いを理解するには、ソフトウェアが動作する仕組みを少し知っておく必要がある。ここでは例えば、ある人がエディタを作りたいと思った場合を考えてみよう。エディタに必要な機能は主に次のようなものだ。

1. 文章を編集する機能
2. 文章をファイルに保存したり読み込んだりする機能
3. 画面に変更結果を逐一表示する機能

　このとき、1の機能を作るのは当然としても、2や3の機能を作るのは労力が無駄になる感が強い。2と3はエディタの本質的機能とは言いにくく、またどんなソフトウェアでも必要とする機能だからだ。OSのレベルでこういった機能が用意してあれば、多くの開発者にとって便利だろう。実際、このような機能が「ライブラリ」として多数のOSやディストリビューションに含まれている（図2）。

図2　ライブラリ

　便利なライブラリだが、その機能を使用したソフトウェア（この場合はエディタ）のライセンスはどうなるだろうか？　GNUの解釈では、別のソフトウェアの機能を利用することになるので、ライブラリのライセンスに従わなければならないことになる。つまり、GPLのライブラリを利用するソフトウェアは派生物と見なされ（図3）、GPLで配布しなければならない。

図3　GPLにおける派生物の解釈

　LGPLは、この問題を解決する条項が含まれたライブラリだ。LGPLが適用されているソフトウェアでは、動的にリンクする場合に限り、アプリケーションをその「派生物」と見なさないと定義されている。一方でGPLでは、動的／静的に限らず、ライブラリにリンクするソフトウェアが「派生物」と見なされる。動的／静的リンクとLGPLの関係をまとめると図4のようになる（コラム2）。

図4　動的／静的リンクとLGPLの関係

コラム2：Linuxのカーネルモジュール

　GPLが適用されているLinuxカーネルに機能を追加したい場合、通常であればカーネルのソースコードを改造して機能を追加するので、変更した部分はGPLを適用しなければいけないだろう。しかし、Linuxカーネルにはモジュールという機能があり、Linuxカーネルを一切変更せずに、カーネルのAPIを利用して機能を追加できる。

　このようにして作られた機能はGPLを適用すべきかどうかは議論が分かれるところだが、現在では「LinuxのカーネルモジュールではGPLを適用しなくてよい」ことが通例となっている。Linuxの原作者であるLinus Tovalds氏が明言したことが根拠になっているのだ。このように、GPLをめぐる解釈はライセンスの文面だけでなく、それを管理する人や団体の解釈にも強く依存する。そのため、オープンソースを利用する上では、業界での動向を継続的に理解する必要がある。

BSDライセンス

　BSDライセンスは、FreeBSDやNetBSD、OpenBSDなど、いわゆる*BSDが採用しているライセンスだ。GPLに比べると、利用に当たっての制約は非常にゆるい。BSDライセンスの特徴は次のようになる。

1. ソフトウェアの利用、再配布、改変は自由に行えるが、再配布のときに原著作者の著作権表示と条項の掲示が必要
2. ソフトウェアを改変し、配布・販売する場合でも、ソースコードを公開する義務がない（原著作者の著作権表示と条項の掲示は文書で提供）

　特に2の特徴から、ソフトウェア／ハードウェアベンダーは、BSDライセンスのソフトウェアを製品に組み込んで販売したときに、自社が組み込んだ改造部分を公開しなくてすむ。組み込みハードウェアなど、機器の内部構造や機能に価値があるケースで、機器の制御ソフトウェアを公開することには大きなリスクがあるため、旧来の商習慣がまだ強い影響力を持っている組み込み市場で多く用いられている。

　ちなみに、初期のBSDライセンスには、「宣伝条項」と呼ばれる項目があった。これは、ある製品に対してソフトウェアを組み込んでいる、またはその機能を使っている場合、すべての広告媒体に次のような文章を含まなければならないというものだ。

このソフトウェアはカリフォルニア大学バークレイ校、およびその協力者によって開発されました

　この条項はGPLと相性が悪かったため、現在では削除され、「修正BSDライセンス」または「修正済みBSDライセンス」と呼ばれている。

そのほかのライセンス

　そのほかにも、Firefoxが採用しているMPL（The Mozilla Public License）や、WebサーバApacheが採用しているApacheライセンス、サン・マイクロシステムズのオープンソースOS OpenSolarisが採用しているCDDL（Common Development and Distribution License）など、メジャーなものだけでもたくさんある。また、ライセンスの内容についても、非常に簡単なものから複雑なものまでさまざまだ（コラム3）。

複数ライセンスを適用するマルチライセンス

　最近では、ビジネス用途で利用しやすいよう、複数のライセンスを適用するソフトウェアが増えてきた。MySQLはGPLと商用のデュアルライセンスを、Fire

foxはGPL/LGPL/MPLのトリプルライセンスを採用している。ユーザーは与えられた選択肢の中から、自分の使いたいライセンスが適用されているものとして利用すれば良い。

商用での利用はよく内容を吟味して

　再配布を行わないユーザーにとって、ライセンスはそれほど意識する必要はないが、商用利用をする場合は特徴をよく理解して利用するべきだろう。ライセンスの問題は素人には理解しづらく、製品を顧客に納品する場合などに十分なケアが必要だ。

　特に、地方自治体などではオープンソースを推進する動きがある一方で、担当者レベルでの理解が追いつかないのが現状ではないだろうか。電子自治体のアプリケーションが、利用しているオープンソースソフトウェアのライセンスに矛盾しているといった指摘を目にすることも増えている。

　こういった問題には、ハッカー文化が一般のユーザーにとって理解しにくいことも一因にあるだろう。オープンソースコミュニティーの側では、こういった問題に対して「理解がない」と批判するだけでなく、より分かりやすい言葉で歩みよる姿勢を示すことが重要だと思われる。

コラム3：オープンソースライセンスが乱立する原因

　OSIが承認したオープンソースは50種類以上にのぼる。特に企業が公開するソフトウェアなどでは独自ライセンスを作成する傾向が顕著なようだ。では、独自のオープンソースライセンスを作成することに、どのようなメリットがあるのだろうか。

• 開発元から見た独自ライセンスのメリット

　独自ライセンスを利用するメリットは、ソフトウェアに対する支配力放棄を最小限にとどめられることだろう。自社で作成したライセンスであれば、ライセンス自体を変更することが可能になる。例えば、GPLは現在バージョン2だが、ソフトウェア特許に対抗するための条項などを盛り込んだバージョン3が議論されている。

　また、ライセンスが法に基づいて適用されることから、運用上の利点を重視する考え方もある。例えば、日本国内で作成したライセンスを適用すれば、何か問題が起こったときも国内で裁判できるが、海外のライセンスを使用すると不慣れな国での裁判に臨まなければならないケースも考えられる。こういったケースを嫌って、独自のオープンソースライセンスを作るところもあるようだ。

• 開発元から見た独自ライセンスのデメリット

　一方で、独自ライセンスを利用すると、ユーザーから見たしきいが高くなるというデメリットもある。ライセンス契約の完全な把握は一般のユーザーには難しい。また、契約の効力は裁判の判例などで時間をかけて定まっていくため、こなれていないライセンスはユーザーに大きなリスクを強いることになる。結果としてマイナーなライセンスは敬遠されるようになるだろう。開発元として多くのユーザーを得たい場合は、ライセンスを認知してもらうための活動が重要になる。

本記事は、オープンソースマガジン2005年12月号「オープンソースで行こう！」を再構成したものです。