「ライセンスどおりにしたのに違反？」「バージョンアップでライセンスが変わった！？」：解決！ OSSコンプライアンス（4）
OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。4回目は、「ライセンスどおりにしたのに違反？」「バージョンアップでライセンスが変わった！？」という2つのエピソードと解決策を紹介する。
本連載では、オープンソースソフトウェア（OSS）の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。
今回も前回に引き続き、ソフトウェア開発企業X社の新人開発者である新城くんが経験したOSSコンプライアンス問題とその解決策を解説していきます。思わぬ落とし穴や難しい問題に直面しながらOSSコンプライアンスに対応していく新城くんのエピソードを通して、皆さんも理解を深めていってください。
なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。
■今回の登場人物
新城くん 日本のソフトウェア開発企業X社の新人開発者。OSSは今回のプロジェクトで初めて利用する。
佳美先輩 X社の先輩エンジニアで、新城くんの指導担当。OSSを活用した開発の経験が豊富。
佐藤さん X社の営業。OSSについてはあまり詳しくなく、インターネットからソースコードを無料でダウンロードできるソフトウェアといった認識。
鈴木さん X社のセキュリティエンジニア。セキュリティ対応部門であるPSIRT（Product Security Incident Response Team）の担当。
エピソード5 ライセンスどおりにしたのに違反？
佳美先輩と確認したとおり、製品のドキュメントにOSSの情報とソースコードの提供に関する内容を記載し、MITライセンスとGPL v2のライセンス全文を添付することにした新城くん。
無事に出荷作業が終わり、プロジェクトが一段落した矢先に、営業の佐藤さんから急ぎの電話がかかってきた。どうやら、顧客からOSSのライセンスに違反しているという指摘を受けたらしいが……。
お疲れさまです。お客さまから、ライセンス違反だという連絡を受けてびっくりしています。どういうことですか？
当社が製品で使用しているOSSのライセンスに対する違反があるというご指摘ですね。具体的にどういう内容かうかがっていますか？
先週、このお客さまから連絡があって、ソースコードを貰えるはずだから送ってくれって言われたんです。でも、ソースコードなんて秘密情報でしょう。そういう対応はしておりません、って丁寧に回答したんですよ。そしたら今日になって、ライセンスに違反しているって……。
新城くん、先日会話した通り、OSSのソースコード提供に関するお知らせのドキュメントは入れたよね？
はい、もちろんです。製品マニュアルにきちんと記載しています。
え？ OSSのソースコードを提供することになってたんですか？ そんなの、聞いてないよ！ ちゃんと説明しておいてくれないと。急いでソースコードを提供するから準備してください。
解説：ライセンス順守のために気を付けるべきこと
故意ではなかったとしても、OSSライセンスの求める条件を順守しないと、それはライセンス違反ということになります。過去には、OSSの著作権者が不適切な配布を行った企業を訴え、賠償金の支払いや製品の販売停止を求めた事例もあり、このようなライセンス違反は、企業にとって無視することのできない大きなビジネスリスクです。
ライセンス違反を起こさないためには、製品やサービスで使用しているOSSを漏れなく把握すること、それらのOSSに適用されるライセンスを把握し、内容を正確に理解すること、ライセンスで定められた条件を確実に順守すること、などが必要です。
さらに重要なこととして、「関係者への周知」があります。OSSに関する問い合わせやソースコード提供希望の連絡には、顧客（OSSを使用した製品の受領者やサービスの利用者）と接する営業担当者やサポート担当者などが対応することが多いです。こうした人々がOSS活用に伴うライセンスの条件について理解していないと、間違った対応や回答をしてしまい、結果としてライセンス違反となるリスクがあります。
このため、OSSライセンスに関する知識は、エンジニアだけでなく、営業や調達の担当者、サポートやコールセンターの担当者などにも必要です。OpenChainが作成して配布している「オープンソースソフトウェアライセンス遵守に関する一般公衆ガイド」（注1）は、OSS活用に関係する全ての人が必要な知識を学習するためのリーフレットです。ぜひ参考にしてください。
注1： オープンソースソフトウェアライセンス遵守に関する一般公衆ガイド
https://github.com/OpenChain-Project/Curriculum/raw/master/supplier-leaflet/supplier-leaflet-1.0-ja.pdf
過去のライセンス違反事例
海外では、ライセンス違反に関する複数の訴訟やトラブル事例がニュース（注2）になっています。その結果、ライセンスを順守するだけでなく、著作権者への損害賠償の支払いや、ライセンスを順守するための社内体制の整備を求められたケースがあります。
日本国内では、今のところ（2022年3月31日時点）訴訟になった事例はありませんが、製品等のライセンス違反を個人が見つけてインターネットに投稿し、その後、開発元が謝罪してライセンスを順守したという事例が幾つかあります。
ライセンス違反の例としては、以下のようなケースがあります。
1.ライセンスにて、OSSのバイナリーを配布する場合にソースコードも提供する条件があったが、ソースコードを提供しなかった。（特に、GPLでの事例が多い）
2.ライセンスにて、OSSを配布する際にライセンス文書を添付する条件があったが、添付していなかった。
3.ライセンスにて、OSSを配布する際に著作権表示を記載する条件があったが、記載していなかった。あるいは著作権表示を配布者の名前に変更してしまった。
上記の原因として、ライセンスに対する理解が不足していたというケースの他、ソフトウェアの開発を外部へ委託したところ、委託先からの納品物にOSSが含まれていたことを認識できなかったといったケースがありました。外部へ委託する際は、委託先がOSSのライセンスに関して理解しているか、納品物にOSSを含む場合はその情報を通知してもらう運用になっているかを確認することをお勧めします。
注２：トラブル事例
オープンソース擁護団体、GPL違反でデジタル家電メーカーを提訴
https://www.itmedia.co.jp/news/articles/0709/22/news019.html
FSF、GPL違反で米Ciscoを提訴
https://www.itmedia.co.jp/enterprise/articles/0812/12/news071.html
「USB版Windows 7」作成ツールにGPLコード Microsoftが謝罪
https://www.itmedia.co.jp/news/articles/0911/16/news026.html
米Tesla、オープンソースライセンスに従いソースコードを公開
https://www.zaikei.co.jp/article/20180525/443904.html
エピソード6 バージョンアップでライセンスが変わった！？
製品のリリースからしばらくたったある日、セキュリティ担当の鈴木さんから至急の連絡を受けた新城くん。どうやら、OSSに脆弱（ぜいじゃく）性が発見されたため、対応の要否を確認したいとのこと。佳美先輩と一緒に詳しい話を聞くことにした。
お疲れさまです。PSIRT部門を担当している鈴木と申します。実は昨日、OSSに新しい脆弱性が発見されたという情報を入手したので、当社の製品に影響がないかを確認しています。こちらのプロジェクトで利用しているOSSは、これに該当しますか？
あ、このOSSですね。確かに使っています。バージョンも、これを使っています。
詳細は後ほどこちらでも確認しますが、影響を受ける可能性が高いので、対応が必要だと思います。
承知しました。本OSSは、既にOSS開発コミュニティーから脆弱性を修正したバージョンがリリースされているので、新バージョンへのバージョンアップが可能か、早急に検討してください。
情報ありがとうございます。新城くん、バージョンアップ可能か、検討してください。
佳美先輩、新しいバージョンはライセンスが変わっていますね。以前はGPL v2（注３）だったのに、新しいバージョンはGPL v3と書いてあります。
いいところに気付いたね！ 他にもバージョンアップの時の注意点があるから、一緒に見てみよう。
注3：GPL＝GNU GENERAL PUBLIC LICENSE
解説：バージョンアップでのライセンス確認
OSSはバージョンによりライセンスが異なることがありますので、OSSを採用する際にライセンスを確認するだけでなく、OSSをバージョンアップする際も確認する必要があります。
例えば、ライセンスのバージョンアップ版が公開され、OSSをバージョンアップする際に古いバージョンのライセンスから新しいものに変更されるということがあります（例：EPL v1.0→v2.0、MPL v1.1→v2.0）(注4）。別の例では、OSSのライセンスだったものが、商用利用する場合は有料のライセンスに変更されたケースや、ソースコード提供不要のライセンスが、クラウドサービスで利用する場合はソースコードを提供する条件に変更されたケースなどがあります。
新城くんのプロジェクトのように、脆弱性やバグの影響によりOSSをバージョンアップすることが考えられます。このときに、バージョンアップ版のライセンスが順守できないものであった場合、影響が大きいです。このような事態をなるべく避けるために、OSSを採用する際、ライセンスが変更される可能性が高いかどうかを考慮しておく方法があります。
例えば、OSSの開発に多数の企業や個人が参加していて、著作権が分散されている場合は、各開発者に了解を取らなければライセンスを変更できないので、変更される可能性は低いと考えられます。逆に、特定のベンダーが開発して著作権を独占している場合は、そのベンダーの方針次第でライセンスが変更される可能性があります。
注4：EPL＝Eclipse Public License、MPL＝Mozilla Public License
GPL v2とGPL v3の関係
GPL v2とGPL v3はバージョンが異なるだけで、どちらも“GNU GENERAL PUBLIC LICENSE”というライセンスですが、GPL v2のOSSとGPL v3のOSSを組み合わせて1つの著作物として配布することができません。理由は次の通りです。
GPLのOSSと他のソフトウェアを組み合わせて1つの著作物になったものを配布する場合、全体にGPLの条件を課す必要があります。しかし、GPLの条件にないものを追加することを、GPLでは禁止しています。GPL v3には、GPL v2に含まれない条件があるため、組み合わせて1つの著作物として配布することができないのです。このような関係をライセンスが「両立しない」といいます。
なお、利用するOSSに必須となるライブラリ等、依存関係のあるものがあった場合、そのOSSあるいはライブラリをバージョンアップする際、ライセンスが変更されていることが考えられますので、ライセンスが両立することをご確認ください。
次回は……
次回の「解決！ OSSコンプライアンス」では、ソフトウェア製品の機能をクラウドサービスで提供することになり、リリースに向けて発生した事案をもとに、OSSの配布の考え方やライセンスを調査するときの注意点について解説します。お楽しみに！
Copyright © ITmedia, Inc. All Rights Reserved.