オープンソースコンプライアンスプロセスの流れ

どのようにオープンソースコンプライアンスプロセスを実施するかは、さまざまな理由により、企業ごとに異なります。しかし、コアになる要素はたいてい同じです。つまり、コード中のオープンソースを識別し、レビューを行い、使用を承認し、ライセンスの義務に従います。

このブログ記事では、典型的なオープンソースコンプライアンスプロセスの概要を示し、フリーオープンソースソフトウェア(FOSS)のコンポーネントが使用を承認されるまでの過程を説明します。

監査によって指摘された問題を解決する

監査ステップの結果、ソースコードスキャナーによって検出された課題(ライセンスの競合など)があれば、解決すべきチケットとして登録します。監査で作成されたすべてのチケットは、経過をモニターし、クローズまで追跡します。すべての関連チケットがクローズされたら、新たに監査を行って課題が解決済みであることを確認します。

適切なレビューを完了する

それまでに指摘された問題がすべて解決したら、コンプライアンスチケットはレビュープロセスに移行します。レビュープロセスでは、エンジニアリングチームとコンプライアンスチームがアーキテクチャレビューとコンポーネントのリンク分析を行い、問題が発見されなければ次のステップの準備をします。

  • アーキテクチャレビューでは、オープンソースコード、サードパーティ製コード、自社開発コードの間の連携を確認する。目的は、ライセンス義務がオープンソースコンポーネントから自社開発コードにまで波及するかどうかを確認することです。
  • リンクレビューでは、特に、静的および動的リンクのレベルで潜在的な問題があるコードの組み合わせがないかどうかを確認する。

オープンソース使用の承認を受ける

すべてのレビューが完了したら、コンプライアンスチケットは承認プロセスに移行します。オープンソースレビューチームは、チケットを承認または却下します。チケットが承認されると、オープンソースレビューチームは製品チームに承認を通知し、製品チームは責任を理解したうえでライセンス義務を満たすための準備を始めます。

ソフトウェア目録へのオープンソースの登録

製品中でのソフトウェアコンポーネントの使用が承認されると、次のタスクが発生します。

  • オープンソースの使用を追跡するソフトウェア目録にコンポーネントを追加する
  • 製品のコンプライアンスチケットに承認を反映する。ソフトウェアコンポーネントの使用が却下された場合は、後で参照するときのために却下の理由を登録するべきです。

製品ドキュメントにオープンソースソフトウェアを記載する

オープンソースを使用する際の主な義務の1つは、文書化の義務(通知義務とも呼ばれます)です。社外に配布される製品でオープンソースを使用する場合、企業はオープンソースを使用していることを明確にするため、要求されるコピーライトや作成者の情報を表示し、製品に含まれるオープンソースコードの使用許諾書全体を複製し、(ライセンスが要求する場合)ソースコードのコピーを入手する方法をエンドユーザーに通知します。

配布の前にすべてのステップの検証を行う

このステップの目的は以下を確認することです。

  • 配布物に含まれる予定のすべてのオープンソースパッケージが識別され、承認されていること
  • ソースコードパッケージ(変更されたものを含む)が製品とともに配布されるバイナリと一致しているかの検証を行ったこと
  • 作成者情報などが適切に製品ドキュメントに記載され、(ライセンスが要求する場合)エンドユーザーにコードを請求する権利があることが通知されていること
  • すべてのソースコードがレビューされ、外部への配布が承認されていること

ソースコードパッケージの配布および最終検証の実行

検証ステップが完了したら、オープンソースパッケージおよび適切な通知を配布用 Web サイトにアップロードします。パッケージが正常にアップロードされており、問題なくダウンロードして展開できることを確認するよう推奨します。

(この記事は、FOSSID Blog 「Walkthrough of an Open Source Compliance Process」2019年3月19日 Fredrik Ehrenstrale 投稿記事をFOSSID社の許可を得て翻訳したものです。)

企業向けSBOMガイドのご提供

「SBOMの導入によるライセンス コンプライアンスと ソフトウェア セキュリティの強化」 企業向けSBOMガイドの資料を提供しています。

SBOM導入ガイド