OSSライセンス順守の第一歩：企業技術者のためのOSSライセンス入門（6）（1/2 ページ）
この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。（編集部）
いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。
順守の第一歩は「違いを意識すること」
間が空いてしまいましたが、過去3回にわたって「考え方に基づいて3つに分類してみる」と題し、私なりの考え方でOSSライセンスを（1）アカデミック系、（2）GNU系、（3）OSI系の3つに分類し、解説してきました。
しかし、これはあくまで概略でしかありません。その背景にある考え方はOSSの著作権者それぞれに違います。企業製のプログラムのライセンスも千差万別なのですから、それも当たり前ですよね。その1つ1つの違いを意識することが「OSSライセンスを順守する」第一歩です。
さて、ライセンスを順守するためには、「『ライセンス条文の違い』を意識することは『当たり前』だ」と認識している方ならば、著作権侵害にまで至るおそれはあまりないと考えて大丈夫でしょう。
でも中には、従来の商用パッケージプログラムの感覚で「ライセンス＝お金で買うもの」という認識を持っている人もいます。中には「お金を払っているのだから、順守しなければならないことはちゃんと提示しろ」という具合に対処してきた人もいるように思います。つまり、自らライセンス条文を熟読して順守するという習慣がないのです。
そういう観点で見ると、GPLv3が「曖昧（あいまい）さの排除」を目的に、厳密を期して大幅に書き換えられたことも善し悪しです。用語の定義から始まり、国際規約か何かのごとく記述された結果、第4回の「GNU系の考え方」で述べた、ライセンス本来の趣旨が分かりにくくなったような気がします。ライセンス条文を熟読して順守するという目で見ると、ハードルが高くなってしまったように思えます。
OSSライセンス順守の手順
とはいえ、担当者に、あるいは企業にOSSライセンスを順守しようという姿勢があれば、ソースコードの開示要求に対していっさい反応を返さず、ついにはコミュニティによる提訴にまで至るような事態になることは少ないと思います。
提訴されないまでも、ライセンス違反・著作権侵害をしないためには、どのような手順が必要でしょうか。当たり前ですが、基本的には第三者の著作権を侵害しないよう、「ライセンスをよく読んで順守すればよいだけ」です。しかし、OSSライセンスを読み慣れていない方も多いでしょうから、もう少し具体的に手順を示してみましょう。
（1）利用するOSSのライセンス条文を探す
- 中には、バージョンによって異なるライセンスを採用しているOSSもあります。利用するOSSのバージョンを意識してライセンスを確認します
- Webサイトのライセンス表記の中には、バージョンまで記載していないものがあります。該当OSSのソースコード（tarボール）を確認するのが確実です
（2）ライセンスの内容が分かりにくかったら、4タイプの分類のうちどれに当てはまるかを確認してみる
- ライセンス条文は、漫然と読んでも理解しにくい場合があります。そんなときは、4タイプのうちどれに当てはまるかを考えながら、ポイントを確認するといいでしょう
（3）ライセンス順守がビジネス的に困難ならば、ほかのOSSを探し（1）に戻る。または自社開発などに切り替える
- 自社のプログラム構成と製品形態によって、「ソースコードを開示できない」などの条件が科せられる場合は、必然的に利用できるOSSのライセンスが絞られます
（4）エンドユーザーが頒布物を受け取ったときに、ライセンスが順守されている状態を保つ
- プログラム構造だけでは、ライセンスを順守できているかどうかは分かりません。ソースコード開示が必要なOSSを利用した製品を提供している場合を考えましょう。その製品を受け取った人にとって、例えばGPLならば、ソースコードが添付されていることを確認できる状態にあるか（or）、または書面でその入手方法が提示されていなければなりません。
■順守できていない製品化の例1：
開発部門は、開示するソースコードもそろえて出荷製品を準備していた。しかし取りまとめ部門がソースコードの開示準備をせず、添付も告知の文書の添付もしていなかった
■順守できていない製品化の例2：
開発部門は、LGPLのOSSを利用し、リバースエンジニアリングされても問題のない構成で出荷製品を準備していた。しかし取りまとめ部門が、従来のまま「リバースエンジニアリング禁止」という文言の入ったソフトウェア使用許諾書を添付して出荷していた
自社製品での利用時に考慮すべき4タイプの違い
第2回の最後に述べたように、OSSに限らず、ライセンス順守を心掛けるならば、最終的にはプログラムごとの個別条件を確認しなければなりません。
しかし、製品というのは当初の計画どおりに出来上がるものではありません。事前に、どの程度までライセンスを順守できそうかを検討、判断して、製品化検討のフェイズで何らかのOSSを選択したとしても、出荷前の最終段階になって状況が変わるかもしれません。この段階でライセンス順守に「対応できない」ことが判明して頭を抱える可能性もあります。
そこで、下記のように「自社で対応できる対処方法の範囲」を基に、利用できるOSSライセンスタイプの範囲を選択するという方法もあります。このやり方ならば、「土壇場になってライセンス違反になってしまう」というリスクを減らすことができるのではないでしょうか。
これは、自ら開発する場合だけでなく、外部に発注する場合にも「開発に際してどの範囲のOSSを利用していいのか」を指示する指標として利用できるでしょう。
例えば、自社開発物件がGPLタイプのOSSの結合著作物に当たるかどうかの検討が煩わしいと考えるならば、「プロジェクトとしてはGPLのOSSを利用しない」といった方針を打ち立て、運用を簡素化することも考えられます。
コラム■BusyBoxに関するライセンス違反の訴訟が大量に!?
第1回の記事で「米国のSoftware Freedom Law Center（SFLC）が活発に訴訟を起こしています」と紹介したことを覚えておいででしょうか？ SFLCは、2008年12月に有名ネットワーク機器メーカーを提訴した後、1年ほどおとなしくしていましたが、2009年12月になって再びBusyBoxに関して14社を提訴しました。
この事実からも、当たり前の話であるはずの「ライセンス順守」が、多くの企業で順守できていなかったことがうかがえますね。
Copyright © ITmedia, Inc. All Rights Reserved.