オープンソース講座(5)：OSSライセンスのリスク

OSSライセンスのリスク

OSIが承認したOSSライセンスだけでも70種近くあり、それを日本語に翻訳してくれている便利なサイトがOSG-JP（ Open Source Group Japan ）です。
（ こちらから参照できます）

勿論これらのライセンスを全て頭に入れる必要はなく、上記のサイトも必要に応じて字引のように使用すればよいでしょう。

今や、開発スピードひいては事業効率を上げる為にはOSSは必須のアイテムです。
ただ一方で、それを使うためには多かれ少なかれ事業リスクが伴うことが多いというのも事実です。

具体的には

無保証、無補償
営業秘密の漏えい
特許の権利行使の制限（NAP：No Assertion of Patent）
第三者からの特許侵害訴訟
暗号ソフトの違法な輸出

などが挙げられます。

OSSを使うことが事業運営にかかわる限りにおいて、その最終責任者は経営トップとなります。
一方、エンジニアの立場としましては、当該ＯＳＳを使うためにどのようなリスクがあるのかを上司や経営者に分かりやすく説明する必要がありますね。

その為のヒントをご紹介しましょう。

11071517 - finger pointing risk, for risk management concept

図　OSSには経営者自らがリスクマネジメントを

OSSには３タイプある

これらのリスクが最も大きく関係している一つに、コピーレフト(Copy Left)という考え方があります。

これは著作権であるCopy rightをもじったもので、CopyをLeft（残す）、すなわち公開する義務を負うことになります。

公開する「範囲」には、改変したOSS自体（①）、自社が改変した部分（②）、それらとリンクした自社のソフトウエアの全て（③）があります。

但しその「程度」はライセンスによって異なっており、おおよそ以下の3タイプに分類できます（ライセンスの記述は、ライセンス名/ライセンス作成者）

コピーレフト系（①＋②＋③の全てを公開）

GPL ( GNU General Public License) / FSF（Free Software Foundation）
AGPL （GNU Affero General Public License）（GPL3.0) / FSF

準コピーレフト系（①＋②を公開）

LGPL (Lesser General Public License) / FSF
MPL ( Mozilla Public License) / Mozilla Foundation
CDDL (Common Development and Distribution License) / Sun Microsystem

非コピーレフト系（制約なし）

MIT License /MIT （ Massachusetts Institute of Technology ）
修正BSD licenses / University of California, Berkeley
Apache License 2.0 / APL ( Apache Software Foundation )

これらを挙げた理由を以下に簡単に説明しておきます。

コピーレフト

FSF ( Free Software Foundation ）が推進している（著作権帰属先）ライセンスがGPL、LGPL、AGPLの３種類です。

GPLは動的リンク、静的リンクにかかわらずリンク沙汰すべてのモジュールのソースコートを再頒布することが義務づけられております。

LGPLの最初の”L”はLesserの頭文字、つまりGPLを主張しているFSFからするとこのライセンスは妥協の産物で、「あまり出来が良くない」と言いたいのでしょうか。
公開の範囲はGPLほど広くはなく、静的リンクしたものだけでよいというのが通説になっております（FSFはこの判断を肯定してない）。
但し、リバースエンジニアリングを禁止してはならないとしています。

さらにややこしいのがAGPL（Affero General Public License）です。
これまで公開するのは頒布するときに限定していましたので、クラウドサービスのようにサーバーにしか置かれないソフトウエアは対象外となっていました。
それにも網をかけようということでAGPLが生まれ、その条項がGPL V3にも取り込まれています。

準コピーレフト

LGPL以外の準コピーレフトライセンスは自分が改変した部分のみの公開でよいことになっています。

例えばMPL( Mozilla Public License )は、以前紹介したようにNetscape Communicatorのソースコードの公開を踏み切るときにMozilla Foundationが作成したライセンスで改変部分のみのソース公開でよいことになりました（つまり上記の①と②のみの公開でよい）

CDDL(Common Development and Distribution License)はSUN Microsystemsが提供するライセンスで、その内容はMPLと同等ですが、MPLで指摘されている”Exhibit A問題”を解決したものです。

その問題とはExhibit A(*2)の空欄に作者の名前を記入するだけで作者オリジナルのMPLが作成できてしまい、結果的に似て非なるMPLが蔓延してしまうという指摘です。

非コピーレフト

非コピーレフト系の代表格は、MITライセンスと修正BSDライセンスです。

この2つのライセンスはFSFが主張する「フリー」とは違う意味での「自由」、つまり使用する側(ライセンシー）にほとんど縛りがない上、ソースコードも公開する必要はないので、使い勝手の良いライセンスだということですね。

ところで、BSDライセンスの頭に「修正」がついていますが、その理由は以下のとおりです。
当初のBSDライセンスには「宣伝条項」というのがあり、これはGPLライセンスの「再頒布時の平等」（追加条件不可）と互換性がありませんでした。
このことがライセンサーにとって何が問題かというと、例えば最も普及しているOSSの一つであるLinux（GPL）のモジュールとして採用されないことになるからです。

これを避けるため現在では以下の「宣伝条項」を外した3条項(*2)が一般的となっています。

宣伝条項
このソフトウエアの機能に言及するまたは使用するすべての宣伝物には、次の謝辞を表示する必要がある。

これに対して同じ非コピーレフト系ライセンスのApache License 2.0はソース公開する必要はありませんが、後述するNAP条項（特許非係争条項）がある点には注意する必要があります。

GPL違反事件とは

OSSのライセンスはライセンサーの著作物に対する主張を約款としてまとめたものなので、法的には契約と同等の効力があり、ライセンシーはOSSを使用する際にはこの契約を順守する必要があります。
従ってそれを守らなかった場合は契約違反となります。
実際に１０年～１５年前にGPL違反事件が多発しました。
OSSの構成要素の一部にコミュニティがあると説明したが、その中にはライセンス違反をしてないかを専門に調査する部門があり、最も有名な組織の一つがGPL違反をチェックするgpl-violations.orgです。

このようなことが起こらないようライセンスは丁寧にチェックするのが基本ですが、万が一コミュニティから違反の通知が来ましたら、その事実を確認した上で誠意をもって謝罪をし、しかるべき対応をするのが良いとされています。

これは２０年以上前に、エプソンコーア（現、アヴァシス）がGPL違反を指摘された際、その迅速な対応がコミュニティからも認められIPA等で模範事例として教材に取り上げられた経緯があります。

OSSと特許対策

ほとんどのOSSライセンスで特許に対する保護、いわゆるNAP条項（No Assertion of Patent)がありますので、特許を重視している企業、あるいは発注先企業の場合には注意が必要です。

もともと、OSSが「良いソフトウエアはなるべく共有しよう」という考え方に基づいているため「他者使用に制限を加える」ことを目的とする特許とは相容れないなのです。

どのくらいのOSSで特許条項があるかを直感的につかむため、2010年5月にIPAが発行した「OSS ライセンスの⽐較および利⽤動向ならびに係争に関する調査」から抜粋しておきます。

特許条項には主に２つのパターンがありますが、内容的はほとんど差がありません。

【パターン１】

ライセンシーは、配布先に対して、配布するOSS に含まれる⾃⾝の特許に関する特許侵害訴訟
を起こしてはならない。
ライセンサーが差別的な特許契約を締結した際、ライセンシーにも当該特許契約が付与される。

【パターン２】

ライセンサーは、OSS に含まれる（商標を除く）知的財産権をライセンシーに対して無償でライ
センス付与しなければならない。
ライセンシーがライセンサーを特許侵害で訴えた場合、ライセンシーに与えられた権利は失効する。

特許に関するOSSの功罪

これまで説明してきたように、OSSコミュニティが主張しライセンス条項にも書いてあることが多いNAP（特許非係争条項）でさえも「発明者を守る」権利である特許権に関しては万全ではありません。

勿論、このライセンス条項があればOSS利用者からパテントトロールのようなビジネスを排除することは可能となります。
しかし特許のことを気にしなくてよいというわけではありません。
なぜなら、少なくともOSSを使用していない第三者は自由に攻撃ができるからです。

———————付則

(*1)MPLライセンスの”Exhibit A”

参考のためMPLのExhibit Aの翻訳文を以下に示しますが、最新かつ正確な情報はhttps://www.mozilla.org/en-US/MPL/のサイトを参照してください。

以下、日本語翻訳を引用します（出典はこちら)

「本ファイルの内容は Mozilla Public License Version 1.1 (「本ライセンス」) の適用を受けます。本ライセンスに従わない限り本ファイルを使用することはできません。本ライセンスのコピーは http://www.mozilla.org/MPL/から入手できます。

本ライセンスに基づき配布されるソフトウエアは、「現状のまま」で配布されるものであり、明示的か黙示的かを問わず、いかなる種類の保証も行われません。本ライセンス上の権利および制限を定める具体的な文言は、本ライセンスを参照してください。

オリジナルコードは、______________________________________ です。
オリジナルコードの初期開発者は、________________________ です。
______________________ によって作成された部分の著作権表示は次のとおり
です。Copyright (C) _____________________________ All Rights Reserved.
貢献者: ______________________________________

このファイルの内容は、上記に代えて、_____ ライセンス ([______] ライセンス) の条件に従って使用することも可能です。この場合、このファイルの使用には上記の条項ではなく [______] ライセンスの条項が適用されます。このファイルの他者による使用を [______] ライセンスの条件によってのみ許可し、MPL による使用を許可したくない対象者は、上記の条項を削除することでその意思を示し、上記条項を [______] ライセンスで義務付けられている告知およびその他の条項に置き換えてください。対象者が上記の条項を削除しない場合、受領者は MPL または [______] ライセンスのいずれによってもこのファ
イルを使用することができます。」
[注: 本 Exhibit A の告知文は、オリジナルコードのソースコードファイル内にある告知文とは若干異なる可能性があります。対象者は自己の修正コードについてオリジナルコードのソースコード内の告知文ではなく、本 Exhibit A の告知文を使用してください。]

(*2)修正BSDライセンス（３条項ライセンス）
(BSDは”Berkeley Software Distribution” )

下記ライセンスの３．を削除したのが2条項ライセンスだ。
【ライセンス内容】