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

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

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

一般に、パーミッシブ・ライセンスには実際の制限条件はありません。むしろ、このライセンスは概ね、自社のソフトウェアを配布する際に著作権表示を適切に行うことを求めています。つまり、著作権表示を適切に行えば、必要に応じてオープンソース・ソフトウェアを使用および変更できるということです。現在最も広く利用されているライセンスである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の意思決定に取り入れる必要があります。