OSSライセンスの「クリアランス」ってどういうこと？　具体的にどうやればいい？：解決！OSSコンプライアンス（6）

OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。6回目は、OSSコンプライアンスのために不可欠な「ライセンスクリアランス」について説明し、具体的な手順を紹介する。

» 2022年07月12日 05時00分公開

[福地弘行，OpenChain Japan Work Group]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　本連載では、オープンソースソフトウェア（OSS）の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。

　今回も前回に引き続き、ソフトウェア開発企業X社の開発者である新城くんが経験した、OSSコンプライアンス問題とその解決策を解説していきます。思わぬ落とし穴や難しい問題に直面しながらOSSコンプライアンスに対応していく新城くんのエピソードを通して、皆さんも理解を深めていってください。

　なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。

■今回の登場人物

新城くん　日本のソフトウェア開発企業X社で働く入社2年目の開発者。OSSは指示を受けながらソフトウェア製品やクラウドサービスで利用した経験あり。

佳美先輩　X社の先輩エンジニアで、新城くんの指導担当。OSSを活用した開発の経験が豊富。

エピソード9　OSSコンプライアンスって、時間がかかりすぎ！？

　後輩がついた新城くんは、チーム全体のOSSコンプライアンスのリーダーを任されることになった。リーダーとして、チーム全体の担当範囲を調査したところ、開発中のソフトウェア製品にOSSが数多く使われていることに気が付いた新城くん。

新城くん、OSSコンプライアンスについて聞きたいことって？

チームの担当範囲で数多くのOSSを使っていますよね？

そうね、新城くんのチームで30個くらいのOSSかな。

初めてだったとはいえ、自分の担当分だけでOSSライセンスの確認に数日かかったんですけど、30個もOSSがあったら単純計算で確認に30日以上かかりますよね？

新城くん、そう、OSSコンプライアンスは時間がかかるのよ。

どうやって間に合わせればいいですか？

ライセンスを守れなければ出荷できないんだから、ライセンス確認できていないのはソフトウェアバグと一緒。間に合うように計画するのよ。

解説：OSSライセンスクリアランスの具体的なやり方

　本稿では、出荷までに製品全体のOSSライセンス順守を確認する作業を「OSSライセンスクリアランス」（以下、クリアランスと記載）と呼びます。

　クリアランスは、製品に含まれている全てのOSSに関してライセンス条件を満足できることを確認し、配布の際に実施しなければならない事項（以下、「クリアランス関連情報」と記載）を準備することです。クリアランス関連情報には、例えばライセンス表記、著作権表記、ソースコード提供などがあります（ライセンスにより異なります）。

　ライセンス確認にはライセンスに関する知識と経験が必要である一方、製品に使用されるOSSは多数ありますから、クリアランスには時間がかかります。製品出荷までに終わらせるためには計画的にクリアランスを進める必要があります。クリアランスを計画的かつ効率的に進めるために、組織内にクリアランス担当者あるいはクリアランスチームを作るのは良い方法かもしれません。クリアランス担当者やクリアランスチームに知識や経験を蓄積していくことで、クリアランスを効率的かつ確実に実行できるようになります。

　計画の話をする前に、クリアランス全体の説明をします。

ライセンスクリアランスの全体像

　クリアランスへのインプットはOSSリスト、クリアランスのアウトプットはクリアランス関連情報です。

　クリアランスはOSSリストを作成することから始まります。OSSリストに含めた方がいい項目には次のようなものがありますが、会社や組織、取引先によって決められている場合がありますので、確認してください。作業を分担するためにも、他の人がOSSライセンスを確認できるように、OSSリストはクリアランスに必要な情報を含んでいる必要があります。

OSSの名前：OSSの特定に最も必要な情報です。
OSSのバージョン：バージョンによってライセンスが異なることがあるため、必ず利用するバージョンを特定し、そのバージョンでライセンスの確認を行います。
OSSをダウンロードした場所（URL）：ダウンロードしたOSSのファイル群に含まれるLicenseファイルや実際のソースコードのコメントなどを見て、ライセンスを確認するのに使います。また、OSSの名前に誤記があってどのOSSが分からない場合などに、OSSを特定する非常に有効な情報になります。
OSSに関する説明や情報（機能、Webサイト等）：OSSの利用目的が分かるように機能などを記載します。WebサイトやFAQに、ライセンスに関する情報があれば、その情報も記載します。
改変の有無：改変した場合、改変の内容を記載します。OSSを改変した場合に、それを明示する必要があるライセンスがあります。また、改変により組み込まれた自社特許を許諾するライセンスがあります。
OSSライセンスの名称：ライセンス条件を確認するのに使います。OSSリスト作成時に分かれば、クリアランス作業の必要情報になります。ライセンスにバージョン番号が含まれる場合には、バージョン番号も明記します。

　OSSリストを作成する際は、漏れがないように、使うOSSの名前を全てリストに記入し、次に他の項目も埋めていくといいでしょう。

　OSSリストの中に、製品に含まれない（配布しない）OSSが含まれている場合には、製品用と開発用と分けて管理すると良いかもしれません。クリアランスで確認するのは、製品やサンプルとして社外へ配布するOSSのライセンスです。

　OSSリストができたら、OSSライセンスをチェックして、ライセンス条件を全て順守できることを確認していきます。もし、会社や組織でOSSライセンスに関してルールがある場合には、そのルールを守っているかの確認も行います。

　OSSライセンスの確認ができたら、クリアランス関連資料を準備します。

　クリアランス関連情報には、代表的なものとして以下がありますが、OSSライセンスによって準備すべきものは変わりますので、ライセンスに従って準備してください。

1.OSSライセンス文

　OSSライセンス文の中には、文章の最後に、あなたのプログラムにライセンスを適用する方法を記載しているものがあります。この部分もライセンス文の一部なので、削除せず含めておく必要があります。

2.著作権表記など

　OSSに含まれる著作権表記などの知的財産に関する記載を残しておくことを条件にしているライセンスがあります。

3.ソースコード一式

　ソースコードを顧客へ提供する場合には、実際に製品で使っているソースコードを準備します（インターネットからダウンロードしたものから変更を加えている場合は、ダウンロードしたソースコードで代用はできません）。OSSライセンスによっては、ソースコードと一緒にビルドに使うスクリプト一式も必要になるものもありますので、OSSライセンス条件を確認してください。

　以上がクリアランスの全体の説明になります。

クリアランス計画のポイント

　次に計画のポイントを説明します。

　クリアランスを計画する際には、クリアランスにかかる時間の見積もりと、クリアランスを実施するタイミングが重要になります。

（クリアランスにかかる時間）＝（OSSリスト作成の時間）＋（OSSライセンス確認の時間）＋（クリアランス関連資料作成の時間）

　クリアランスにかかる時間を知るには、「OSSリスト作成の時間」「OSSライセンス確認の時間」「クリアランス関連資料作成の時間」を見積もります。OSSリストを作成するのは経験とスキルが必要な作業であり、時間もかかりますので、見積もる際には誰が行うかを考慮する必要があります。初めての場合には、大きめに見積もっておいた方が良いかもしれません。

　クリアランスのタイミングについては、次のような考慮をします。

　もし、順守できないOSSライセンス条件（あるいは会社や組織のルールで使わないことになっているOSSライセンス）や、ライセンスを確認できないソフトウェア（ライセンスが確認できないものはOSSではない）があった場合、あるいは両立できないライセンスがあった場合に、該当するOSSやソフトウェアを使わないように設計を変更する必要が出てきます。設計変更が可能なように、設計段階でOSSライセンスの一覧を確認するタイミングを設定した方が良いでしょう。

　クリアランスの中で、OSSリスト作成とOSSライセンス確認は設計段階で行うとともに、開発段階でOSSが追加された際にはその都度行うのが望ましいです。クリアランス関連資料の準備はそれほど急ぎませんので、もう少し後で計画してもよいかもしれません。ただし、OSSのバイナリのみをダウンロードしている場合、後日、ソースコードをダウンロードできなくなることがあるので、ソースコードも入手しておくのがよいでしょう。

最近よく聞く「SBOM」って何？

　最近、「SBOM（Software Bill of Material）」という言葉をよく耳にします。SBOMは、対象の製品やパッケージに含まれるソフトウェアの構成情報を記録したリストで、ライセンス順守や脆弱性に関連する情報を管理するときに利用できます。今回のエピソードで紹介したOSSリストは、ライセンス順守のための情報を管理するSBOMの例です。組織によってSBOMの利用目的や管理する項目は変わりますし、目的に応じてもっと多くの項目を管理しているSBOMもあります。

　SBOMは組織ごとにばらばらに定義されますが、組織間で互換性が取れるように仕様を標準化する動きがあります。Linux FoundationがホストするSPDXプロジェクトで定義しているSPDX（Software Package Data Exchange）仕様は、2021年にISO/IEC 5962になっています。