OSSライセンス順守の第一歩：企業技術者のためのOSSライセンス入門（6）（2/2 ページ）

» 2010年02月18日 00時00分公開

問題は「意図しない」流用

　前述のような手順は、初めからライセンス条文を尊重する人にとっては、いちいちいわれなくても守って当たり前という行為にすぎません。

　しかし、そのようなリテラシー教育が徹底されていない場合もあります。この辺に関する意識の低い会社で開発したプログラムを製品に統合するケースもあるでしょう。

図2　意図しない流用のリスク

　といっても、GPLなどのOSSを開発したコミュニティ側も、ライセンス違反があったからといっていきなり提訴することはありません。まずは、ライセンスを順守するようにソースコードの開示を求めてきます。そのとき、要望に気が付いて誠実に対応すれば、逆にコミュニティからその姿勢を賞賛された企業さえあります。

　問題なのは、「自社製品ではOSSを利用していない」と思い込んでいる場合です。そして、ソースコードの開示を求められたときに適切な知識を持たず、フリーズしてコミュニティからの要望に無反応になってしまうことです。こうして対応が後手後手に回った結果、しびれを切らして提訴された、というケースが多いようです。

OSSライセンス順守のための支援ツール

　2003年ごろ、UNIX／Linux関連で訴訟が起こったことを契機に、自社開発製品がOSSライセンスに違反しないようサポートするツールがいくつか出てきました。

　その多くは、ソースコードを基に、どんなOSSを利用しているのかを特定する（検索する）ためのものです。どれも、データベースの中に比較データを持ち、それとアプリケーションの内容を比較することで、含まれているOSSを検出します。

　ですからこうした支援ツールでは、比較の基となるDBの情報が常に更新されることが重要です。ましてや、比較データのDBがなければ、たとえ検索を行うツールのプログラムだけあっても使い物にはならないことに注意が必要です。

　そのようなOSSライセンス順守のための支援ツールは、一例として、以下のように分類できます。

ツール	比較データ（DB）（方式）	長所	短所
（1）	ファイル名（findコマンド型）	・比較データが少なくて済む	・ファイル名は簡単に変更できてしまう
（2）	キーワード（grepコマンド型）	・ライセンス名が明記されているOSSには妥当な検索ができる	・ヒットすべきキーワードの選択が難しい・著作権表示などを改竄（かいざん）されるとヒットしない
（3）	ソースコード（パターンマッチング型）	・著作物そのものを比較するので一致すれば確度は高い	・関数名、変数名を変更されて流用された場合にヒットしない可能性が高まる・OSSのソースコードはほかのOSSにも利用されている可能性が高く、多くのOSSでヒットするため、流用OSSを特定しにくい
（4）	ソースコード（曖昧マッチング型）	・著作物そのものを比較し、確度を％で表す。このため、悪意ある改竄（かいざん）をされても、ある程度検出可能	・OSSのソースコードはほかのOSSにも利用されている可能性が高く、より多くのOSSでヒットするため、流用OSSを特定しにくい

表2　OSSライセンス順守ツールの種類

　OSSの簡易名検索方法として、findコマンドのようにファイル名を検索するツール（1）や、ソースコード中の著作権表示などのキーワードをgrepコマンドのように検索するツール（2）などがあります。これらは、自社開発時に利用しているOSSがどんなものか確認するのに役立ちます。しかし、ファイル名やキーワードは比較的容易に変更できますから、意図的に名前を変更されてしまった納品物などでの検査には役立ちません。

　他人の著作物の自分の著作物かのように詐称する者がいた場合、著作物そのものであるソースコードのマッチングを行うツール（3）が必要になります。

　さらに悪質なものならば、関数名や変数名まで置換するかもしれません。そういう悪質な詐称に対処するためには、ソースコードのマッチングを曖昧（あいまい）に、つまり許容範囲を持ったマッチングを実施するツール（4）が必要になります。

　製品によって異なりますが、多くの場合、ツール（3）（4）はツール（1）（2）の機能を含んでいます。「開発物件のライセンスを調べるため」か、それとも「意図していない流用（詐称）がなされていないか調べるため」か、目的によって使い分けることが可能です。

ツールはあくまで道具に過ぎない、コミュニティに参加しよう！

　もう1つ注意しなければならないことがあります。これらの支援ツールは、あくまで検索ツールにすぎないということです。「これを掛ければOSSライセンス違反がたちどころに判定できる」などということはありません。OSSライセンス違反とは、あくまでプログラムを頒布（譲渡）する際の状況（順守のための記載、ソース開示などの状況）によって判断されるべきものであり、プログラムの構造だけで判断できるものではありません。

　それでも、何十万、何百万と存在するOSSからの流用を人手でチェックすることは不可能でしょう。ツールを用いて検索し、ヒットしたものだけを確認すれば、調査の手間が何千分の1、何万分の1に省けることになります。

図3　ツールの効用

　ツールのみでOSSライセンス違反が判定できるケースを考えるとすれば、すべて自社開発し、すべてプロプライエタリなライセンスとする製品を対象にツール（4）を掛け、1つもOSSが検出されない、というような極めて限定的な場合に限られるでしょう（それでも、論理的に絶対ということではありません。しかし現実的には、それ以上の検査は無理でしょう）。

図4　すべて自社開発したつもりの製品にツールをかけると……

　しかし、OSSが検出された場合は、ツールを過信してはいけません。自らライセンス条文をよく確認し、著作権者の意図に沿わない扱いをしないようにしましょう。

　しばしば、OSSを使うときには「give and take」などといって、コミュニティへの貢献が推奨されます。コミュニティの中に入り、利用するOSSをよりよく知ることによって、プログラムの機能の理解だけでなく、扱い方についての理解も進むことが期待できます。知らずに使うことがリスキーなのは、どんなことでも同じですよね。自由に使用できるOSSだからといってリスクが少ないわけではありません。

　また、コミュニティに参加して開発者の顔が見えてくれば、自然に、ライセンスを無視した扱い方はできなくなるものでしょう。そういうリスクヘッジの意味でも有意義と考えて、コミュニティへ参加して活動していただきたいと思います。

　さて、6回にわたり連載してきた「企業技術者のためのOSSライセンス入門」は、今回が最終回となります。長い間つたない文章にお付き合いいただき、ありがとうございます。また、励ましのコメントをいただいた読者の皆さんには深く感謝いたします。

　機会がありましたら、またこうした記事を書きたいと思います。ありがとうございました。

「企業技術者のためのOSSライセンス入門」バックナンバー