OSSライセンスが求める条件とは？：企業技術者のためのOSSライセンス入門（2）（2/2 ページ）
この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。（編集部）
OSSライセンスを4つに分類してみる
70以上の種類が存在するOSSライセンスは、OSIのOSDありきで作成されたわけではありません。中には、各著作権者が自由気ままに記述したライセンス条文もあり、その全貌（ぼう）を理解しようとすると絶望的な気分になることもあります。
しかし、いろいろな人がこれらを何とか分類しようと試みています。
前回の冒頭で紹介した「Black Duck Protex」のコード検査で使用するナレッジベースでは、大きく以下の2種類の属性に分けて登録されています。
この「互恵の」ライセンス、「寛容な」ライセンスという見方は、商用のプロプライエタリなプログラムでOSSのプログラムが検出された際に、「寛容なライセンスでソースコードの配布を強要されないか」、それとも「互恵のライセンスだから返礼としてソースコードを配布しなければならないか」という点に注目して分類しているようです。
一方、前出の「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」資料の「1.1.2 オープンソース・ライセンスの分類」では、「OSSの本質であるソースコード公開条件および伝播性の強さに着目」して、GPL・MPL・BSDの3つの類型に分類しています。
私はそれをベースに、GPLの中からLGPLをさらに切り出して、4つのタイプに分類して説明しようと思います。
これは、以下のフローチャートに合わせてOSSライセンスを分類するものです（図1）。
4つのタイプの制約の強度によって、表に書き直してみると以下のようになります（図2）。
ただし、この分類に出てくる条件だけが各タイプのOSSライセンスの要件ではありません。ほかにもいろいろな要件、特に禁止事項が複数あったりしますが、この分類では省略していることに注意してください。
順守が求められる主な3種類の要件
4つに分類するときのフローチャートからも分かるように、この分類は、OSSライセンスの要件の中で、企業の製品開発者が主に気にしなければならない「3つの要求事項」をキーに分類しています。それは以下のとおりです。
なお、誤解する方が少なくないので繰り返しになりますが、これは各OSSライセンスタイプのOSSライセンスの順守事項の必要条件にすぎず、決して十分条件ではないことに注意してください。
例えば、上の2では「リバースエンジニアリングを許可しなければならないOSSライセンスは『LGPLタイプ』と分類する」と説明しているのです。決して、「LGPLは、静的リンク(注1)のとき*だけ*、リバースエンジニアリングを許可すればよい」と解釈しないでください。ライブラリを静的リンクした場合に加えて、動的リンクした利用プログラムも結合著作物と見なされる場合は、リバースエンジニアリングを許可しなければなりません。
注1：プログラム実行時に必要に応じてライブラリを呼び出す「動的リンク」に対し、あらかじめライブラリを実行コードに含める方式
最後はOSSごとにチェックが必要
今回はさまざまなOSSライセンスを、企業の製品開発者の立場から気になる3つの要件に基づいて、4つのタイプに分類してみました。
これは、企業の製品開発者にとってOSSライセンスの理解の助けになるのではないかと試みたものですが、この分類をもってライセンスを正確に理解することはできません。繰り返しになりますが、ライセンスを正しく理解するには「ライセンス条文自身を読むこと」が必要になります。
ライセンス条文＞ライセンスの分類の説明
ということです。当たり前のことですが、今回の分類の説明よりライセンス条文の記述が優先されます。
さらに、例えばMySQLというOSSデータベースのライセンスは、GPL以外に商用ライセンスでも提供されています。これは、利用者が用途に従ってライセンスを選択する「デュアルライセンス」と呼ばれるものです。またMySQLでGPLを選択した場合は、結合したほかのOSSにGPLが伝播しない旨の例外が設定されています。
このように利用条件を順守するためには、ライセンス条文のみならず、OSSが提供されているサイトを訪れて、以下のことを確認する必要があります。
- ライセンス条文以前に選択肢が存在していないか。選択肢が存在すれば、どの選択肢を選択して利用しているのか
- ライセンス条文を適用するに当たっての例外が存在しないか
このことから分かるように、もし個々のOSSで定めている条件があれば、ライセンス条文よりもそちらが優先されると考えてください。
OSSごとの条件＞ライセンス条文＞ライセンスの分類の説明
もちろん、代表的なライセンス条文を作成しているコミュニティのプロジェクトでは、そのようなOSSごとの条件は歓迎していません。
また、ライセンスを設定する著作権者・開発者からすれば、ライセンス条件を決めるのは著作権者の権利として自由に設定可能ですから、どのようなライセンスを設定することも可能です。しかし最近では以下のような理由で、既存の、しかもメジャーなOSSライセンスを自分の著作物に対して適用するケースがあります。
- 同様のほかのプログラムと、ライセンス間の齟齬（そご）、矛盾が発生して、一緒に頒布できなくならないように
- ライセンスの種類を増やして、利用者を混乱させないように
そのような努力が行われている一方で、一部のOSSでは個別の条件が現存していることを認識しておかなければなりません。
関連記事：
まつもとゆきひろのハッカーズライフ：第13回 プロジェクトの障害（ITmedia）
http://www.itmedia.co.jp/enterprise/articles/0803/26/news002.html
さて、今回はOSSライセンスの要件に着目してお話ししましたが、次回は、それらの要件が出てきた背景の理解を助けるお話をしてみたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.