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

　いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。

順守の第一歩は「違いを意識すること」

　間が空いてしまいましたが、過去3回にわたって「考え方に基づいて3つに分類してみる」と題し、私なりの考え方でOSSライセンスを（1）アカデミック系、（2）GNU系、（3）OSI系の3つに分類し、解説してきました。

　しかし、これはあくまで概略でしかありません。その背景にある考え方はOSSの著作権者それぞれに違います。企業製のプログラムのライセンスも千差万別なのですから、それも当たり前ですよね。その1つ1つの違いを意識することが「OSSライセンスを順守する」第一歩です。

　さて、ライセンスを順守するためには、「『ライセンス条文の違い』を意識することは『当たり前』だ」と認識している方ならば、著作権侵害にまで至るおそれはあまりないと考えて大丈夫でしょう。

　でも中には、従来の商用パッケージプログラムの感覚で「ライセンス＝お金で買うもの」という認識を持っている人もいます。中には「お金を払っているのだから、順守しなければならないことはちゃんと提示しろ」という具合に対処してきた人もいるように思います。つまり、自らライセンス条文を熟読して順守するという習慣がないのです。

図1　ライセンスは読んで当たり前!?

　そういう観点で見ると、GPLv3が「曖昧（あいまい）さの排除」を目的に、厳密を期して大幅に書き換えられたことも善し悪しです。用語の定義から始まり、国際規約か何かのごとく記述された結果、第4回の「GNU系の考え方」で述べた、ライセンス本来の趣旨が分かりにくくなったような気がします。ライセンス条文を熟読して順守するという目で見ると、ハードルが高くなってしまったように思えます。

OSSライセンス順守の手順

　とはいえ、担当者に、あるいは企業にOSSライセンスを順守しようという姿勢があれば、ソースコードの開示要求に対していっさい反応を返さず、ついにはコミュニティによる提訴にまで至るような事態になることは少ないと思います。

　提訴されないまでも、ライセンス違反・著作権侵害をしないためには、どのような手順が必要でしょうか。当たり前ですが、基本的には第三者の著作権を侵害しないよう、「ライセンスをよく読んで順守すればよいだけ」です。しかし、OSSライセンスを読み慣れていない方も多いでしょうから、もう少し具体的に手順を示してみましょう。

（1）利用するOSSのライセンス条文を探す

（2）ライセンスの内容が分かりにくかったら、4タイプの分類のうちどれに当てはまるかを確認してみる

（3）ライセンス順守がビジネス的に困難ならば、ほかのOSSを探し（1）に戻る。または自社開発などに切り替える

（4）エンドユーザーが頒布物を受け取ったときに、ライセンスが順守されている状態を保つ

自社製品での利用時に考慮すべき4タイプの違い

　第2回の最後に述べたように、OSSに限らず、ライセンス順守を心掛けるならば、最終的にはプログラムごとの個別条件を確認しなければなりません。

　しかし、製品というのは当初の計画どおりに出来上がるものではありません。事前に、どの程度までライセンスを順守できそうかを検討、判断して、製品化検討のフェイズで何らかのOSSを選択したとしても、出荷前の最終段階になって状況が変わるかもしれません。この段階でライセンス順守に「対応できない」ことが判明して頭を抱える可能性もあります。

　そこで、下記のように「自社で対応できる対処方法の範囲」を基に、利用できるOSSライセンスタイプの範囲を選択するという方法もあります。このやり方ならば、「土壇場になってライセンス違反になってしまう」というリスクを減らすことができるのではないでしょうか。

　これは、自ら開発する場合だけでなく、外部に発注する場合にも「開発に際してどの範囲のOSSを利用していいのか」を指示する指標として利用できるでしょう。

　例えば、自社開発物件がGPLタイプのOSSの結合著作物に当たるかどうかの検討が煩わしいと考えるならば、「プロジェクトとしてはGPLのOSSを利用しない」といった方針を打ち立て、運用を簡素化することも考えられます。