Tweet

最終回　OSSライセンス順守の第一歩

　いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（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のライセンス条文を探す

• 中には、バージョンによって異なるライセンスを採用しているOSSもあります。利用するOSSのバージョンを意識してライセンスを確認します
• Webサイトのライセンス表記の中には、バージョンまで記載していないものがあります。該当OSSのソースコード（tarボール）を確認するのが確実です

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

• ライセンス条文は、漫然と読んでも理解しにくい場合があります。そんなときは、4タイプのうちどれに当てはまるかを考えながら、ポイントを確認するといいでしょう

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

• 自社のプログラム構成と製品形態によって、「ソースコードを開示できない」などの条件が科せられる場合は、必然的に利用できるOSSのライセンスが絞られます

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

• プログラム構造だけでは、ライセンスを順守できているかどうかは分かりません。ソースコード開示が必要なOSSを利用した製品を提供している場合を考えましょう。その製品を受け取った人にとって、例えばGPLならば、ソースコードが添付されていることを確認できる状態にあるか（or）、または書面でその入手方法が提示されていなければなりません

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

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

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

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

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

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

第5回へ

1/2

Index 技術者による技術者のためのOSSライセンス入門 　最終回　OSSライセンス順守の第一歩

Page 1 順守の第一歩は「違いを意識すること」 OSSライセンス順守の手順 自社製品での利用時に考慮すべき4タイプの違い コラム　BusyBoxに関するライセンス違反の訴訟が大量に!? 　 Page 2 問題は「意図しない」流用 OSSライセンス順守のための支援ツール ツールはあくまで道具に過ぎない、コミュニティに参加しよう！

Linux Square全記事インデックス

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード