主要なオープンソース・ライセンスと開発者にとっての法的リスク

ソフトウェア・サプライチェーンマネジメントにはライセンスとセキュリティ・コンプライアンスが必要

ソフトウェア開発者は、多くの場合、オープンソースのコンポーネントとライブラリを使用してソフトウェアを構築していますが、これらのコンポーネントがさまざまなオープンソース・ライセンスによって管理されていることは知っていても、個々のライセンスの詳細まで熟知しているでしょうか。

特に、組織にコンプライアンス上の問題をもたらす可能性がある複雑なライセンス条件を把握している開発者は少ないのではないでしょうか。ソフトウェア内に不適合なライセンスが1つでもあると、法的措置、時間のかかる修正作業、製品の市場投入の遅れにつながる可能性があります。そのため、オープンソース・ライセンスのコンプライアンスを確保することが重要です。

ソフトウェア・サプライチェーンのガバナンスにおけるオープンソース・ライセンス管理のベスト・プラクティス

• すべてのサードパーティー製コンポーネントを特定します。オープンソースと商用ソフトウェアを含む、ソフトウェアで使用されているすべてのサードパーティー製ソフトウェア・コンポーネントの完全なインベントリを作成します。
• 開発者は、ライセンス違反や知的財産権侵害にあたるコードを生成する可能性があるAI支援コーディング・ツールの使用には注意する必要があります。AIによるコーディング支援の実用化と普及はまだ始まったばかりです。AIで生成されたコードの法的および倫理的な影響は未解決の問題であり、その解決は裁判所や政府の規制に委ねる必要があるかもしれません。
• ライセンス条件を評価します。各コンポーネントのライセンス条件を評価し、製品の使用目的に適合するかどうかを検討します。
• 相互に互換性がないライセンスもあるため、異なるコンポーネントのライセンス間の互換性を確認してください。
• 自動スキャン・ツールを使用して、各コンポーネントのライセンス義務と制限を確認および追跡します。
• 定期的なライセンス・スキャン、ライセンス・コンプライアンス手順の定期的なレビューなど、継続的なライセンス・コンプライアンスのためのコンプライアンス・プロセスを実装します。
• 新しいライセンスまたは馴染みのないライセンスのレビュー・プロセスとワークフローを実装します。
• 法律、技術、業務のステークホルダー間で効果的なコミュニケーションを確保し、ライセンス整理の取り組みに適切な優先順位を付けて実行します。
• 今後の監査を円滑にするため、ライセンス評価やコンプライアンス手順を含むすべてのライセンス整理手続きを文書化し、コンプライアンスの取り組みの記録を確保します。

要するに、多くのオープンソース・ライセンスはソフトウェアの使用状況に応じて解釈の余地があるということです。オープンソース・ソフトウェアの使用による法的リスクを判断することは、通常は法律の専門家ではない開発者にとっては特に、非常に困難な場合があります。

リスク別のオープンソース・ライセンス

Synopsysでは、2022年から2023年にかけて最も広く利用されているオープンソース・ライセンスを、知名度、利用規約、潜在的な法的リスクに基づいて3つのグループに大別しました。2022年から2023年にかけて開発者によって使用された上位20の人気のオープンソース・ライセンスのリストには、リスク分類と、オープンソース・イニシアティブ（OSI）によるライセンス承認の有無が追加されています。OSIのライセンス・レビュー・プロセスは、オープンソースとしてラベル付けされたソフトウェアとライセンスがコミュニティスタンダードに準拠していることを保証し、ライセンスの重複と拡散を最小限に抑えるために役立ちます。

このリストのデータは、Black Duck®監査サービス・チームが実施した商用ソフトウェアの監査の年間結果をまとめた「オープンソース・セキュリティ＆リスク分析」（OSSRA）レポートから取得したものです。Black Duckの監査によると、長年にわたり一貫して、使用されているオープンソースの約98%が上位20の人気のライセンスです。

リスクの分類は単なるガイドラインであり、個々のライセンスによって管理されるオープンソース・ソフトウェアの使用を決定するための判断材料とするべきではありません。開発者は、ライセンス・コンプライアンスについて、企業ポリシーを指針とし、法務チームに相談する必要があります。

2022～23年の上位20のオープンソース・ライセンス

*コンポーネントにはパブリック・ドメインであることを示す記述がありますが、UnlicenseやCCなどの特定のパブリック・ドメイン・ライセンスは使用していません。

低リスク、中リスク、高リスクのオープンソース・ライセンスについて

低リスク：パーミッシブ・ライセンス

一般に、パーミッシブ・ライセンスには実際の制限条件はありません。むしろ、このライセンスは概ね、自社のソフトウェアを配布する際に著作権表示を適切に行うことを求めています。つまり、著作権表示を適切に行えば、必要に応じてオープンソース・ソフトウェアを使用および変更できるということです。現在最も広く利用されているライセンスであるMITライセンスとApacheライセンスは、このカテゴリに分類されます。パーミッシブ・ライセンスは低リスクのライセンスと見なします。

中リスク：セミパーミッシブ・ライセンス

セミパーミッシブ・ライセンスでは通常、利用可能なソースコードに変更を加える場合には、指定されたライセンスの条件に従う必要があります。このカテゴリのライセンスの中には、何をもって変更とするかを明示的に定義しているものもあります。たとえば、ライセンスによっては、変更されていないオープンソース・コードを独自開発コードにコピーすることを変更の例として挙げている場合があります。ライセンス義務を遵守するには、ソースコード（オリジナル、変更を加えたもの、新しく追加したもの）を開示する必要があります。このカテゴリの代表的なオープンソース・ライセンスとしては、MozillaやEclipseのパブリック・ライセンスなどがあります。セミパーミッシブ・ライセンスは中リスクのライセンスと見なします。

高リスク：制限付きライセンス

一般的なオープンソース・ライセンスの中には、GNU General Public License v2.0以降やGNU Lesser General Public License v3.0以降など、厳格な制限が課されるものがあります。オープンソース・ソフトウェアを独自開発のソフトウェアに組み込む方法によっては、重大なリスクに直面する可能性があります。最悪の場合、独自開発のソフトウェアを同じライセンスで、ロイヤリティフリーで開示することが求められる場合もあります。制限のあるライセンスは高リスクのライセンスと見なします。

MITライセンスとCCライセンスについて

1位にランクインしたMITライセンスは、2023年のOSSRAで監査を受けたオープンソースの70%（約721,000件）で採用されていたことは驚くに当たりません。開発者がオープンソースを使用している場合、またはソフトウェアにサードパーティー製コンポーネントが含まれている場合は、ほぼ確実にMITライセンスがあります。MITライセンスは、独自開発のソフトウェア内での再利用を許可するパーミッシブ・ライセンスであるため、他のソフトウェア・ライセンスとの互換性が高く、低リスクです。

一方、クリエイティブ・コモンズ（CC）ライセンスは、オープンソース・コミュニティでは人気がありますが、作成者はソフトウェアやハードウェアでの使用については特に推奨していません。CCのFAQに記載されているように、ソフトウェア固有のライセンスとは異なり、CCライセンスにはソースコードの配布に関する具体的な条件が含まれていません。この点が、多くの場合、ソフトウェアを自由に再利用および変更する上で重要となります。

多くの開発者はCCライセンスをドキュメントに使用していますが、不注意で、または意図的に、CCライセンスをコードに適用しようとする開発者もいます。その結果、2023年のOSSRA監査結果では、クリエイティブ・コモンズ表示-継承3.0が矛盾のあるライセンスの1位になりました。

ソフトウェア・サプライチェーンにおけるオープンソース・ライセンスのリスク管理

パッケージソフトウェア、組み込みソフトウェア、商用SaaSソフトウェアのいずれを構築する場合でも、オープンソース・ライセンスのコンプライアンスは組織にとって重要な懸念事項となります。使用するオープンソース・コンポーネントのライセンスの種類と条件を確認し、ソフトウェアのパッケージおよび配布との互換性を確保する必要があります。ソフトウェアが商用製品ではなく、社内使用のみの場合でも、そのソフトウェアで使用されているオープンソース・コンポーネントのライセンス条項が適用されます。

まず、自動ソフトウェア・コンポジション解析ツールを使用して、ソフトウェアで使用されているすべてのオープンソース・コンポーネント、使用中のバージョン、およびそれらに関連するライセンスの最新かつ正確なソフトウェア部品表（SBOM）を作成します。SBOM上のソフトウェア部品に関連付けられたライセンス・テキストをコンパイルして、ソフトウェアの配布およびライセンス要件に準拠していないコンポーネント、またはソフトウェア内の他のコンポーネントで使用されている可能性のあるライセンスに準拠していないコンポーネントにフラグを立てることができます。最も寛容なオープンソース・ライセンスであっても帰属義務が存在するため、すべてのライセンスの義務に確実に準拠していることが重要です。

Black Duckソフトウェア・コンポジション解析（SCA）を使用することで、開発、セキュリティ、コンプライアンスの各チームがオープンソースの使用から生じるリスクを管理できます。Black Duckのマルチファクター・オープンソース検出および600万を超えるコンポーネントで構成されるKnowledgeBase™から、あらゆるアプリケーションやコンテナについて、ライセンス情報を含む正確な部品表（BoM）が得られます。オープンソース・コンポーネントの大部分は最も一般的な20のライセンスのいずれかを使用していますが、Black Duckはさらに、作成するソフトウェアに制限を課す可能性がある2,500以上の他のオープンソース・ライセンスに関するデータを提供します。オープンソースの追跡および管理にBlack Duckを利用することにより、高額の訴訟に発展する可能性があるライセンスの問題や重要な知的財産の侵害を防ぐことが可能です。

M&Aを計画している場合、または関与している場合

合併・買収（M&A）取引に売り手または買い手として関与する予定がある場合は、さまざまなライセンスの契約条件を理解し、ライセンスの矛盾を特定しなければなりません。この困難な作業を進めるためには、組織の法務顧問に関与を求めるか、外部弁護士の法的アドバイスを求める必要があるでしょう。通常、市販ソフトウェアの方がライセンス条項が明確に定義され、事後の条件緩和が難しいため、特にパッケージ・ソフトウェアや組み込みソフトウェアを構築する場合には、この点を事前に正しく理解しておくことが重要です。

企業のコードベースにどのようなオープンソース・コードが存在するかを知ることは、その使用と再利用を適切に管理し、ソフトウェア・ライセンスのコンプライアンスを確保し、脆弱性へのパッチ適用を適切に管理するために不可欠であり、ビジネス・リスクを軽減するために重要です。M&Aの観点から見ると、コード監査により、買い手は知的財産の価値に影響する可能性のあるソフトウェアのリスクと、そのリスクに対処するために必要な対策を理解することができます。一般的な企業のコードに未知のオープンソースが大量に含まれていることを考慮すると、売り手はデューデリジェンスでの予期せぬ事態を避けるために監査を積極的に採用する可能性があります。コードの構成をより詳細に理解したい企業にとって、オープンソース監査は欠かせません。監査のエキスパートは、Black Duck SCAを使用してコードベース内のオープンソース・コンポーネントを包括的に把握し、コンポーネントに関連する法令遵守の問題にフラグを立て、重大度に基づいて問題に優先順位を付けます。

監査により、オープンソース・コンポーネントに影響を与える既知のセキュリティ脆弱性、バージョン、重複、コンポーネントの開発アクティビティの状態などの情報が検出されます。また、買収対象企業のソフトウェア開発プロセスの精巧度を知る手がかりが得られます。オープンソースが広く普及している昨今では、企業がソフトウェア開発の一環としてオープンソースを適切に管理していなければ、他の側面が適切に管理されているかどうかについても疑問が生じます。

テクノロジー企業のM&A取引では、買い手側は、オープンソース監査をソフトウェア・デューデリジェンス・プロセスの一環として組み込む必要があります。買い手は、取引条件を設定する前に、買収対象のコード内に潜む問題のあるオープンソースを特定する必要がありますが、そのための詳細かつ包括的な見解を得る方法としては、信頼できる第三者による監査が最適です。売り手は、コードの構成や、オープンソースのセキュリティとライセンスのリスクをどの程度適切に管理しているかについての質問に備えておく必要があります。売り手は、先手を打って、買収に備えて事前にソフトウェアの監査を受けることもできます。

オープンソース監査によってオープンソース・コードおよびサードパーティー製のコンポーネントとライセンスを特定することで、M&A取引における潜在的な法的問題やセキュリティ上の問題について注意を促すことができます。オープンソース監査により、次のことが可能になります。

• 不測の事態を回避する
• 法的リスクを軽減する
• ソフトウェアの資産価値に影響を及ぼす可能性のあるリスクを把握する
• 潜在的な問題が取引に影響を与える前に問題を解決する
• 適切な保護を取引条件に組み込む
• 売り手/買い手のコードの統合と修正を計画する

買収先企業のコードのオープンソース・コンポーネントに、重大な財務上のリスクやブランド・リスクが潜んでいる可能性があります。買い手側のデューデリジェンスの一環として、リスク評価をM&Aの意思決定に取り入れる必要があります。