目次


オープンソースで行こう!: 第2回 オープンソースライセンス事情を俯瞰する

Comments

連載第1回で解説したように、フリーソフトやプロプライエタリなソフトウェアから「オープンソース」を区別しているのがライセンスになります。ライセンスの中にも、Linuxが使っているGPL(GNU General Public License)や、Apacheに適用されているApache Licenseなどがあり、文字どおり山ほどある状況です。しかし、いったいなぜライセンスがこんなに増えているのでしょうか? 今回は、当世オープンソースライセンス事情を見てみましょう。

オープンソースの定義

オープンソースは概念なので、「オープンソースライセンス」というものはありません。実際のソフトウェアに適用されているのは、GPL(LinuxやGNOME*など)やBSDライセンス(BSDなど。詳細は後述)といった、法に準拠する体裁を整えた契約です。このような契約はGPL・BSDライセンス以外にもたくさんあり、OSI(Open Source Initiative)という団体で承認されたものだけが「オープンソース」を名乗って良いことになっています。

OSIによるオープンソースの定義(日本語)

オープンソースの定義は前記Webサイトで詳細に規定されていますが、要約すると表1のようになります*

表1. オープンソースの定義(要約)

主なライセンス

前述したオープンソースの定義を満たしたソフトウェアがOSIに承認されれば、正式に「オープンソースソフトウェア」を名乗ることができます。2007年2月現在、50種類を超えるライセンスが承認されています。この中でも代表的なものの特徴と、利用に当たっての注意点を見ていきます。

GNUの定めるGPL

代表的なのは、なんといってもGPLでしょう。Linuxカーネルをはじめ、コンパイラやコマンド類などたくさんのソフトウェアがGPLを採用しています。GPLは、連載第1回で紹介したFSFが管理しているライセンスで、次のような特徴があります。

  1. ソフトウェアを利用した時点でGPLに従うことを承諾したと見なす(契約書へのサインや申請といった手続きがない)
  2. GPLが適用されているソフトウェアは、GPLの条項に反しない限り、複製、頒布、改変を自由に行える
  3. ソフトウェアを複製、あるいは改変し頒布する場合、頒布するソフトウェアもオリジナルと同じライセンスで配布すること
  4. ソフトウェアのバイナリを第三者に提供した場合、第三者はソースコードを要求できる

GPLで注意が必要なのが3と4の項目です。特にGPLのソフトウェアをビジネス用途などで第三者に販売・提供する場合、その第三者からソースコードの開示要求があればそれに応じなければなりません(図1、コラム1)。

図1. ソースコードの開示要求
図1. ソースコードの開示要求
図1. ソースコードの開示要求

コラム1:ソースコードはどういったときに公開しなければならない?

誤解されがちなポイントですが、オープンソースのソフトウェアは第三者に再配布しない限りソースコード公開の義務はありません。そのため、

  • オープンソースソフトウェアを改造して自分一人で使っている
  • 企業においてオープンソースソフトウェアを改造し、自社内でのみ利用している

といったケースではソースコードを公開する義務がないのです。

また、改造したソフトウェアの実行ファイル(バイナリ)を第三者に配布・販売したケースにおいても、ソースコードを要求できるのは直接配布・販売を受けた者に限られています。オープンソースソフトウェアを利用した製品を販売しているA社があったとして、必ずしもA社はソースコードを(Webサイトなど)公衆からアクセスできる場所に用意しなければならないわけではありません。

これが問題になるケースでよく見かけるのは、Linuxを搭載したハードウェア(ルーターなどのネットワーク機器、および最近ではHDDレコーダー、携帯型音楽プレーヤーなど)を販売する場合です。Linuxカーネルを改変していた場合、改変部分に割いた人的コストや知的財産は公有のものにしなければなりません。

そういったコストをどの程度大きなものと見積もるかは意見の分かれるところですが、そもそもGPLのソフトウェアを利用することで、コスト削減など大きなメリットも享受しているはずです。このあたりは、コストとメリットのトレードオフを計算に入れることが重要になります。

なお、コストとメリットを計算する際、考慮に入れてほしいのがGPL以外のライセンスです。Linuxを使う代わりに、もっと制限のゆるい(そして多くの場合同等の機能を提供する)BSDを利用することもできます*。オープンソースのライセンスの中でも、GPLは特に制限が厳しいので、ビジネスでの利用に当たっては注意が必要になるでしょう。

ライブラリなどに用いられる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. ライブラリ
図2. ライブラリ
図2. ライブラリ

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

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

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

図4. 動的/静的リンクとLGPLの関係
図4. 動的/静的リンクとLGPLの関係
図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 License、サン・マイクロシステムズのオープンソースOS OpenSolarisが採用しているCDDL(Common Development and Distribution License)など、メジャーなものだけでもたくさん存在します。また、ライセンスの内容についても、非常に簡単なものから複雑なものまでさまざまです(コラム3)。

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

最近では、ビジネス用途で利用しやすいよう、複数のライセンスを適用するソフトウェアが増えてきました。MySQLはGPLと商用のデュアルライセンスを、FirefoxはGPL/LGPL/MPLのトリプルライセンスを採用しています。ユーザーは与えられた選択肢の中から、自分の使いたいライセンスが適用されているものとして利用すれば問題ありません。

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

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

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

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

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

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

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

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

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

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

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

このページで出てきた専門用語

GNOME

GNU Network Object Model Environmentの略で、GUIのデスクトップ環境を実現するライブラリ(統合環境)の1つ。Window間の操作を統一し、ユーザーには使い勝手を、開発者には容易に高機能アプリケーションを作れる環境を提供します。

要約すると表1のようになります

なお、商用利用などライセンスが問題になりそうなケースでは、オリジナルのライセンス文書を確認してください。

パッチ

ソースコードを一部分だけ取り出したもの。ソースコードを修正した場合、古いコードと新しいコードを元に、ツールを用いて差分情報だけを機械的に抽出、この差分情報をパッチと呼びます。

BSDを利用することもできる

Linuxを利用する場合でも、カーネルを直接改造するのではなく「カーネルモジュール」として開発することでライセンスの問題が避けられるケースがあります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=249425
ArticleTitle=オープンソースで行こう!: 第2回 オープンソースライセンス事情を俯瞰する
publish-date=05112007