オープンソースを使おう(9)　OSSライセンスのリスク | 生産性向上を実現するパートナー ベーネテック

中堅・中小から大企業の高収益体質の実現に向けて事業開拓、事業承継、生産性向上、人財育成など経営者のパートナーとして全力支援

ベーネテック

生産性向上を実現する経営パートナー

ベーネテックFacebookページ

TEL:03-6403-3236TEL:03-6403-3236

無料相談はこちら

※無料相談は2時間・一社初回のみ

オープンソースを使おう(9)　OSSライセンスのリスク

OSSライセンスのリスク

OSSに関する経営トップの心得

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

もしあなたが開発者でなければ70種類のライセンスを全て頭に入れる必要はなく、上記のサイトも必要に応じて字引のように使用すればよいだろう。

ただし、もし「そんなことは開発マターだ。全て開発リーダや開発部長に任せておけばよい」とお思いの方がいたらその考えは改めたほうが良いだろう。　なぜなら、経営スピードを上げる為に今やOSSは必須のアイテムだが、それを使うためには多かれ少なかれ必ず事業リスクが伴う。

具体的には

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

などである。

そしてその最終責任者は経営トップである貴方なのだ。

それでは経営トップとしてどの程度把握しておけばよいのだろうか？
これまでの経験と個人的な偏見を許してもらえるなら、最低限以下のライセンスを頭に入れることをお勧めしている。

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が推進者（著作権帰属先）のライセンスがGPL、AGPL、LGPLの３種類ある。

GPLは動的リンク、静的リンクにかかわらずリンク沙汰すべてのモジュールのソースコートを再頒布する必要がある。

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

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

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

MPLは以前紹介したようにNetscape Communicatorのソースコードの公開を踏み切るときにMozilla Foudationが作成したライセンスで改変部分のみのソース公開でよいことになっている。つまり上記の①と②のみの公開でよい。

CDDLは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 ライセンスの⽐較および利⽤動向ならびに係争に関する調査」から抜粋しておく。IPAのOSS調査レポート（ライセンス比較表）

特許条項には主に２つのパターンがあるが、内容的はほとんど差がない。

【パターン１】

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

【パターン２】

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

特許に関するOSSの功罪

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

NAPの効果

図　NAPの効果は限定的だ

———————付則

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

以下の内容はここから引用した。

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

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

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

貢献者: ______________________________________

このファイルの内容は、上記に代えて、_____ ライセンス ([______] ライセンス) の条件に従って使用することも可能です。この場合、このファイルの使
用には上記の条項ではなく [______] ライセンスの条項が適用されます。このファイルの他者による使用を [______] ライセンスの条件によってのみ許可
し、MPL による使用を許可したくない対象者は、上記の条項を削除することでその意思を示し、上記条項を [______] ライセンスで義務付けられている告知
およびその他の条項に置き換えてください。対象者が上記の条項を削除しない場合、受領者は MPL または [______] ライセンスのいずれによってもこのファ
イルを使用することができます。」

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

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

  1. ソースコード形式、バイナリ形式を問わず、下記著作権表示、本条件書および2.の責任限定規定を必ず含める
  2. 本ソフトウェアは無保証である。自己責任で使用する。
  3. 著作権者の名前を、広告や宣伝に勝手に使用しない。

【著作権表示例】

  • プログラム名
  • Copyright（Ⓒ） 制作年　著作権者 All rights reserved.

 

2016年9月6日

« »

[fbcomments]

関連記事一覧