「協力会社のOSS利用、把握する必要なんかあるんですか？」：解決！OSSコンプライアンス（9）
OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。今回からは、ソフトウェア開発企業X社の開発者である新城くんが、協力会社も巻き込んだ大規模な開発に取り組む中で直面する、OSSコンプライアンス問題とその解決策を解説していきます。
本連載では、オープンソースソフトウェア（OSS）の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。
今回からは、ソフトウェア開発企業X社の開発者である新城くんが、協力会社も巻き込んだ大規模な開発に取り組む中で直面する、OSSコンプライアンス問題とその解決策を解説していきます。思わぬ落とし穴や難しい問題に直面しながら、OSSコンプライアンスに対応していく新城くんのエピソードを通して、皆さんも理解を深めていってください。
なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。
■今回の登場人物
新城くん 日本のソフトウェア開発会社X社で働く入社3年目の開発者。佳美先輩のもとでOSS活用に関する経験を積み、大規模プロジェクトのメンバーに抜擢（ばってき）された。
因幡PM 新城くんが参加している大規模なソフトウェア開発プロジェクトのマネジャー。
蒲田さん 新城くんが担当する機能の一部モジュールの開発を委託しているＹ社の担当者。
エピソード13 ベンダーが納入したOSSのライセンスも把握？
佳美先輩の指導によりOSSを活用したソフトウェア開発の経験を積んだおかげで、協力会社も巻き込んだ大規模な開発プロジェクトのメンバーに大抜擢された新城くん。プロジェクトの進捗（しんちょく）を確認する会議で、因幡PMに自分が担当する機能の開発進捗状況を報告することに。
内製で開発しているAモジュールとY社さんにお願いしているBモジュール、Cモジュールともに開発は順調で、現状のバージョンでの結合テストを進めています。
OSSのライセンスの精査は行っていますか？
はい！ AモジュールにはMITライセンスのライブラリSSSとライブラリRRRを利用しています。
BモジュールとCモジュールはどうなっていますか？
えっ？ Y社さんに委託しているモジュールはバイナリで納入いただいていますので、ライセンスは分かりません……。
解説：委託先などの協力会社が開発したソフトウェアのOSSコンプライアンス
ソフトウェア開発の大規模化に伴い、委託先や共同開発先などの協力会社とともにソフトウェアの開発を進めることが多くなっています。これまでの連載でも触れてきましたように、OSSコンプライアンス業務を適切に進めるためには、製品に含まれる全てのOSSのライセンス条件を把握する必要があります。
これは、協力会社が開発したソフトウェアであっても例外ではありません。今回のケースのように協力会社がバイナリ形式で納入した場合、ライセンスを確認することは困難です。従って、ソースコードも納入してもらうか、秘密情報を含むなどの理由でそれが難しい場合は、利用しているOSSのリスト（SBOM）を提出してもらうことが必要です。
もちろん、ソースコードでの納入であったとしても、ソフトウェアの作り手がOSSのリストも作成した方が正確なものができるでしょうから、リスト提出に協力してもらうことが望ましいでしょう。
あらかじめ、協力会社とOSSコンプライアンスの進め方を決めておこう
どんな納入形態であれ、協力会社は顧客である自社へソフトウェアを納入する際、OSSのライセンス条件を順守する必要があるため、ライセンス条件に応じてライセンス文や著作権表示、ソースコードの提供などを行う必要があります。一方で、自社もソフトウェアを顧客へ納入する際、ライセンス条件を順守する必要があります。
お互いのコンプライアンス業務を円滑に進めるためにも、利用するOSSの情報の授受について、協力会社とあらかじめ進め方を決めておくとよいでしょう。この決めごとは共同開発契約や委託契約の中に含めたり、その契約に基づいた覚書などにしたりするのも良いですし、個別契約にひも付かない会社同士のガイドラインとしておいてもよいと考えられます。この決めごとには下記のような情報を含めると良いでしょう。
OSS情報の共有タイミング・担当者・方法
開発期間が長いソフトウェア開発の場合、納入時のみにOSS情報を共有すると、想定していなかったライセンスのソフトウェアが含まれていた場合、リリース時期が遅れてしまうおそれがあります。ですので、開発期間の中で、いつ、どのような開発フェーズで情報を共有するのかをあらかじめ決めておくと良いでしょう。
また、その際、誰がトリガーをかけ、利用しているOSSのリスト（SBOMなど）のフォーマットや、リストをどのような方法で共有するかも決めておくとスムーズに情報共有を進めることができるでしょう。
今回の開発で利用が困難なライセンス条件、ライブラリ
ソフトウェアのユースケースによっては履行することができないライセンス条件や、セキュリティ上の理由で採用することのできないライブラリなどが存在する場合があります。そのようなライセンスやソフトウェアが存在する場合には、今回は採用できない旨を明文化して協力会社へ提示しておくと良いでしょう。
ライセンス条件の順守方法、問い合わせ時の対応
自社が顧客へ納入する場合は、ライセンス条件を履行するために、ライセンス文や著作権表示、ソースコードの提供などを行う必要があるので、その段取りを顧客と取り決めておくと良いでしょう。また、ライセンス条件の順守について顧客からの問い合わせがあった場合に備えて、自社内での役割分担を含め、どのように対応するのかもあらかじめ決めておきましょう。
エピソード14 サプライチェーン全体を見なくてはならない
BモジュールとCモジュールにOSSが使われているのか、使われているとすればどんなライセンスなのかなどを確認するため、Y社の担当者である蒲田さんと打ち合わせを行うことに。
貴社にお願いしているモジュールのOSSの情報をいただきたいんですが、お願いできますか？
はい。弊社で開発しているBモジュールのOSSのリストを後ほどメールでお送りますね。
Cモジュールについてもリストをいただけますか？
えーと……。Cモジュールについては、私たちからZ社さんに再委託してまして、確認してみますので持ち帰らせていただけますか？
（不安だ……）
解説：OSSのサプライチェーンマネジメント
今回のケースのように、協力会社がさらに他のソフトウェア開発会社に再委託しているケースもあります。そのため、必ずしも協力会社が全てのOSSに関する情報を把握しているとは限りません。一方、自社としては自社のソフトウェアに含まれる全てのOSS情報を入手しないと、適切にライセンス条件を順守することができません。
ですので、協力会社に開発業務を依頼するときに、OSSを利用する場合はライセンスを把握するため、協力会社だけでなく、再委託先が利用しているOSSの情報も提供してもらう必要があることをあらかじめ伝えておくと、スムーズに進むでしょう。また、リリース前にあわてて対応といったことにならないように、どのタイミングで誰がトリガーをかけて、どのような方法で情報を提供し、内容を精査していくのかもあらかじめ相談し、サプライチェーン内で共有しておくとよいでしょう。
このように、サプライチェーン全体で利用しているOSSなどのソフトウェアコンポーネントの情報を可視化していくことを、ソフトウェアの「トランスペアレンシー（Transparency：透明性）の向上」といいます。これは、セキュリティ対応という観点でも、企業にとって非常に重要な課題となってきています。
なぜなら、自社のソフトウェアに脆弱（ぜいじゃく）性がないかチェックするために、利用しているOSSのコンポーネントの可視化が必要だからです。トランスペアレンシーを向上するために、OSSのサプライチェーンマネジメントを進めていくための手段としては、サプライチェーン内のルール整備、SBOMやツールの活用による情報共有の効率化などが挙げられます。詳細は次回以降で事例を交えて紹介していきます。
国内外で活発化するソフトウェアのトランスペアレンシー向上の取り組み
ソフトウェアのトランスペアレンシーについては、米国におけるNTIAの取り組み（注1）が有名です。また、日本政府においても、経済産業省のサイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース（注2）が取り組んでいます。この活動の一環として、「オープンソースソフトウェアの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集」（注3）がリリースされており、企業におけるOSS管理の参考になる、さまざまな企業の取り組み事例が紹介されています。
このように、国内外で多様な取り組みが進んでいますが、世界的な気運が高まったのが、2021年5月に署名された米国の大統領令の中で、ソフトウェアのトランペアレンシーを高めるために、連邦政府の情報システムに求められる要件の一つとして、OSSリスト（SBOM）の作成と提供が求められたことです。このニュースをきっかけに、各国や各社、各コミュニティーの活動がより活発になってきています。
注1：NTIA Software Component Transparency
https://www.ntia.doc.gov/SoftwareTransparency
注2：サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース
https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_bunyaodan/software/index.html
注3：OSSの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集
https://www.meti.go.jp/press/2021/04/20210421001/20210421001.html
次回は……
次回の「解決！ OSSコンプライアンス」では、詳しくSBOMの取り組みを見ていきます。
Copyright © ITmedia, Inc. All Rights Reserved.