実際に起きたライセンスの係争
経済産業省の事例集は、係争の例を挙げています。
2017年3月、ある会社が開発した航空機内エンターテインメントのソフトウェアについて、競合する会社から、ライセンス違反だとしてニューヨークの連邦裁判所に提訴されました。
Linuxをもとにしたソフトウェアのソースコードが適切に開示されていないことが指摘され、1億ドルの賠償が要求されました。2018年1月に和解しましたが、賠償額は明らかにされていません [L6]。
ライセンス違反が、事業上の大きなリスクになりうることを示す例です。
納品物にどんなOSSが入っているか
経済産業省の資料は、OSSが自社のほか、サプライチェーン（部品や開発の委託先）でも使われていると説明しています。そのような場合でも、納品物の中のOSSを把握し、ライセンスへの対応やバグ・脆弱性への対応を、自社でOSSを使う場合と同じように行う必要があります。
そのため、各社が使うOSSの情報を適切に集める必要があります [L6]。
事例集には、企業の工夫が載っています [L6]。
- 委託先に、OSSの使用を事前に通知させる：日立製作所は委託先との基本契約書に、OSSを使う場合は事前に通知する旨を盛り込んでいる。また、発注の条件書に、OSSの使用の可否を書いている
- 契約書の雛形で、原則使わない・使うなら通告する：オムロンは、外部の開発委託先と交わす契約書の雛形で、OSSを原則使用しないこと、使用する場合はそのOSSを通告することを定めている
- 納品物の検査：委託先から納品されたソフトウェアをツールで検査して、組み込まれているOSSを特定している企業が複数ある
- 顧客への納品時の責任分担：日立製作所は、顧客へ納品する際も組み込んだOSSを顧客に申告し、保守情報の確認、修正パッチの適用、適用後の動作確認といった作業の責任範囲を、顧客との間で明確にしている
- OSSの利用範囲を、契約で明確にする：OSSTechは、顧客向けに開発する機能のライセンスをコアとなるOSSのライセンスに合わせているが、顧客の希望と食い違うことがあるため、契約の段階でOSSのライセンスを適用する範囲を明確に合意しておくことが重要としている
ソフトウェアの「部品表」：SBOMとSPDX
SBOM（エスボム）は、ソフトウェアの部品表です。どの部品（OSSなど）をどのバージョンで使っているかの一覧です。
事例集では、多くの企業がSBOMを使ってライセンスや脆弱性を管理しています [L6]。
トヨタ自動車は、サプライヤから受け取る使用ソフトウェアのリストの書式として、SPDX Liteを採用しています。
SPDX（エスピーディーエックス）は、Linux Foundationが支援するソフトウェアパッケージの部品、ライセンス、著作権などの情報をやり取りするための標準的な形式で、SPDX Liteはその簡易版です。Excelなどでも管理できます [L6]。
ライセンスがあとから変わることもある
事例集には、OSSのライセンスが変更された例も載っています。
ラキール社は、あるOSSのライセンスが変更され、商用利用するにはソースコードの公開義務が生じる内容になったことを知り、OSSの管理を見直すきっかけになりました。
そのOSSは用途を把握できていたため、結果的に影響はありませんでしたが、「知らないうちにライセンス違反になるのでは」という懸念が大きくなりました [L6]。
使っているOSSのライセンスを継続して確認する仕組みが必要です。
見えない部品：再帰的に使われるOSS
事例集によると、ラキール社がツールで検出すると、あるプロダクトで利用していると想定していたOSSは20〜30程度でしたが、再帰的（部品が使う部品）なものも含めると数百ありました [L6]。
人が把握している数と実際に入っている数は、大きく違うことがあるのです。
コンプライアンス体制の国際標準：OpenChain（ISO/IEC 5230）
OpenChainは、Linux Foundationのプロジェクトで、サプライチェーン全体にわたってOSSコンプライアンスを実現する、業界標準の作成と普及を目的としています。
その仕様は、2020年12月にISO/IEC 5230として、国際標準になりました。
企業が組織内に作るべきコンプライアンスのプログラムの要件を定めています [L6]。
運用で起きること：脆弱性、サポート期間
事例集は、OSSの脆弱性の例として、2014年4月に公表されたOpenSSLの「Heartbleed」を挙げています。
TLSの通信を維持する機能の弱点で、細工したリクエストを送るとサーバーのメモリ上のデータ（IDやパスワード、サーバー証明書の秘密鍵など）が漏れる可能性がありました [L6]。
このシリーズの「通信・Web」の記事で触れたTLSの部品に弱点があった例です。
OSSは、商用ソフトに比べてサポート期間（ライフサイクル）が比較的短く、サポートが十分でない場合があります。
そのため、バグや脆弱性が判明したときに利用者側で対応しなければならないことがあります [L6]。事例集には、次のような取り組みがあります [L6]。
- 長期の保守コストを、事前に顧客と合意する：三菱電機インフォメーションシステムズは、OSSを5年程度使うことを前提に、OSSのコミュニティがサポートを終了するリスクとその場合の保守コストを、開発の初期に顧客に説明し合意している
- サポート終了（EOL）の扱いを決める：日立製作所は、原則としてEOLになったOSSは使わない。出荷後にEOLになった場合は、関係者に通知し、対応計画の作成と定期的な報告を徹底している
脆弱性の情報を集める公的な仕組みもあります。
IPAとJPCERTコーディネーションセンターが運営する「情報セキュリティ早期警戒パートナーシップ」と、脆弱性情報のポータルサイト「JVN」です [L6]。
体制：誰が見るのか
事例集の「まとめ」は、OSSへの対応には、OSS自体やOSSを使う自社の製品・サービスの十分な理解に加えて、セキュリティ、法務、調達、品質管理といった複数の部門にまたがる広い知識が必要だと述べています [L6]。
専門組織を持つ企業もあれば、各部門の代表が集まる委員会型の組織を持つ企業もあります [L6]。
発注・運用の前に確認したいこと
- 納品物に含まれるOSSの一覧（SBOM）と各OSSのライセンスを、納品物として受け取れるか
- 委託先がOSSを使う場合の、事前の通知や申告のルールが契約に入っているか
- 納品後にOSSの脆弱性が見つかったとき、誰がどれくらいの期間で対応するのか。保守の費用と範囲は決まっているか
- 使うOSSのサポート期間（EOL）とシステムの使う期間は釣り合っているか
- OSSのライセンスや脆弱性の確認を、誰がどのくらいの頻度で行うのか（ツールを使うか）
注記：この5点は、各資料の内容から私が整理した確認項目です。
資料がこの形のチェックリストを示しているわけではありません。
契約書への具体的な書き方は、案件ごとに異なります。専門家にご確認ください。
参照元
[L6] 経済産業省, OSSの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集（令和4年8月1日） — https://www.meti.go.jp/policy/netsecurity/wg1/ossjirei_20220801.pdf
コメント