OSI系OSSライセンスに関する一考察：企業技術者のためのOSSライセンス入門（5）（2/2 ページ）
LinuxカーネルはGPLでもOSI系？
LinuxカーネルのライセンスはGNU GPLv2ですが、その運用方法としては、GNU系の「自由が第一義」というより、OSI系の「コミュニティによる共同作業がうまく回ることが第一義」というものに受け取れます。
この辺りのライセンスと考え方のねじれが、OSSの理解を複雑にしたり、議論の種になったりします。
例えば、GNU GPLのversion 3（以下、v3）は、v2と比べ、意図している内容にほとんど変更はありません。どの国の著作権法においても誤解を招かないよう用語を新しく選択するなどし、v2に存在していた用語のあいまいさなどをできるだけ排除しようと試み、書き直されたものと見ても、大きな違いはないでしょう。
さて、「自由が第一義」と考えるRichard M. Stallman氏やGNUに考えの近い人たちにとっては、用語がより明確に定義されたGPLv3を採用し、またほかの開発者にも広く採用してほしいと考えるのは当然です。
一方、GPLv2を採用していても、「コミュニティによる共同作業がうまく回ることが第一義」と考える者にとっては、内容が変わらないならば、わざわざライセンスを変更して共同作業に支障を来す必然性はないと考えるのも容易に想像できます。ましてや、v2のプログラムとv3のプログラムが混在したものは1つのプログラムとして頒布できないというライセンス間の衝突（後述の注7参照）が発生し、移行に当たっては各コミュティとも苦労しているようです。
Sambaプロジェクトでは、そういう苦労をしてまでもすぐにGPLv3に移行しました。一方Linuxカーネルのように（注5）、そこまでして移行する理由を見いだせないとし、移行する理由が見つかるまでGPLv3へ移行したがらないプロジェクトが存在するのも理解できるでしょう。
注5：ある記事によると、Linus Torvalds氏は「OpenSolarisがGPLv3に移行するなら、十分な理由になり得る」と発言したそうですが、2年以上経ったいまなお、そのようなことにはなっていないようです。
そういう状況から、Linuxカーネルは、ライセンスとしてはGPLでも、考え方としてはOSI系に近いのではないかと推察できます。
OSI系ライセンスの特徴
「自由を第一義」とするGNU系に対し、「コミュニティによる共同作業がうまく回ることが第一義」としたOSI系のライセンスとして、以下のようなものが作成されました（注6）。
- MPL（Mozilla Public License）：ネットスケープがNetscape NavigatorをNPL（Netscape Public License）でオープンソース化しましたが、それを引き継いだMozillaが現在採用しているライセンス
- CPL（Common Public License）：IBMがEclipseをオープンソース化する際に作り出したライセンス
- EPL（Eclipse Public License）：CPLから派生した、Eclipseの現在のライセンス
注6：前項のようなスタンスから、Linuxカーネル公開時点にOSI系ライセンスが存在していれば、Linus Torvalds氏もこちらを採用していたかもしれないと勝手に想像しています。
このようにOSI系ライセンスは、企業、または企業に近い開発コミュニティが策定したライセンスが多いことが特徴になっています。時系列的にこの順番で作成されたため、2009年春にSymbian Foundationを設立し、オープンソース化された「Symbian OS」も、Eclipseとは直接の関係がなくても、より新しいライセンスであるEPLが選択されたものと思われます。
一時期、OSSへのコミットメントを示すために、多くの企業が自社名を冠したOSI系ライセンスを作成し、この結果、無駄に多くのライセンスが開発されました。ですが現在は、増え過ぎたライセンスの弊害が認識されるようになり、少しずつですが統合され、廃止されるライセンスも出てきました。
これらOSI系のライセンスの特徴は、以下のように考えると理解しやすいかと思います。
- Linuxのように、ソースコードを共有・相互交換し、改善のための共同作業を進めていくには、改変したプログラムも含めてソースコードの開示が必要だ。
- ただし、企業製ソフトウェアとの共存が可能なように、利用プログラム（プラグインなどを含む）に対するソースコード開示やリバースエンジニアリングは求めない。
- また、特許報復条項と一般に呼ばれる条件がある。特許侵害訴訟を起こした場合は、再頒布の権利を失うというもの（注7）。
注7：この条件が、GPLv2が禁止するいわゆる「付加条項」と見なされ、OSI系ライセンスおよびこの条項を採用したApache License 2.0は、GPLv2と両立しませんでした。しかし、GPLv3では特許報復条項が採用されたため、GPLv3は、少なくともApache License 2.0と両立することができます。逆に、GPLv3のプログラムは、GPLv2のプログラムと両立しなくなってしまった（1つのプログラムとして頒布できない）という問題があります。
特に、2つ目の特徴は、例えばWebブラウザがアドビシステムズの「Acrobat Reader」や「Flash」などの企業製ソフトウェアのプラグインと共存しなければ実用上使用に耐えなくなってしまうことを考えると、容易に想像がつく落としどころかと思います。
図4 企業製の非OSSのプラグインと共存できるMPLライセンスOSI系ライセンス利用時のちょっとした注意点
OSI系ライセンスの多くは、まるで企業の法務部門がかかわって作成されたかのような条文構成になっており、用語の定義から始まります。実は、私がコンサルティングを行った中で、その用語の定義が落とし穴になった事例がありましたので、ここで参考までに紹介しましょう。
コンサルで見つかった開発企業Aの「誤解」
【OSSの利用形態】
- 開発企業Aは、CPLのOSSを利用したプログラムを開発し、顧客企業Bに納品する
- 顧客企業Bは、そのプログラムを組み込んだ製品を店頭で一般ユーザーCに販売する
【企業AのCPLの誤解釈】
- 「3. 要件」に「iv）プログラムのソースコードを当該コントリビュータから入手できることをうたう」とある
- 「1. 定義」に「コントリビューション」とは、
a）初期のコードなど
b）i）プログラムへの変更
ii）プログラムへの追加
とある
ここで納品先の顧客企業Bは、「開発も改造もしないため『コントリビュータ』ではなく、従って、企業Bは一般ユーザーCにソースを開示する（入手できることをうたう）必要はない」と誤解したのです。
【誤解を招いた要素】
この誤解を招いた落とし穴は、ライセンス条文にある「コントリビューション」と「コントリビュータ」の定義です。
一般的に考えれば、「コントリビュータ」とは「コントリビューション」の作成者であると思います。MPLにおける定義はそのとおりでも、CPLやEPLでの定義は違うために、開発者が早とちりしたようです。その違いを以下のようにまとめてみましたので、参考にしてください。
|
||||||||||||||||
| 表2 コントリビューションとコントリビュータの定義 |
もちろん、ライセンス本文を、たとえ参考の日本語訳でもきちんと読んでいさえすれば、このような誤解をするはずがありません（また、本連載の第1回や第2回でも読んでいれば、そのような勘違いもしないはずです）。これも、第1回の最後で注意した「理系的な答えを求めては対応を誤る」例の1つでしょう。思い当たる方は、注意してくださいね。
以上、アカデミック系、GNU系、OSI系と3回にわたり、各ライセンスの考え方の一端を紹介しました。
注8：第2回で紹介した4つのOSSライセンス・タイプと区別するため、ここでは「〜系」という分け方をしましたが、「GNU系」と書くと「GPLやLGPLに近いけれど、GPLでもLGPLでもない別の何かに受け取れてしまうような気がする」というコメントをいただきました。確かにそういう用法もあるのですが、ここでは「GNUとそれにつながる考え方」（のライセンス）の意味で使わせていただきました。
さて、次回は再びライセンスの要件に着眼点を戻して、各ライセンスを順守するためのツールや取り組み方法について紹介したいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。