理解しておく必要がある5つのソフトウェア・ライセンス・タイプ

コードを再利用する場合、タイプが異なるソフトウェア・ライセンスでは一定の義務に従う必要があります。以下では、5種類の一般的なソフトウェア・ライセンスをご紹介します。

ソフトウェアを構築する場合、コード・スニペット、ライブラリ、関数、フレームワーク、およびアプリケーション全体を含めて、コードを再利用します。ほとんどのアプリケーションは、コードの大部分が再利用されたサードパーティー製コンポーネントで構成されています。すべてのソフトウェア・コードは、第三者が使用する場合、または会社のコードベースに組み込む場合には、一定の権利と義務が伴います。スタック・オーバーフローからコピーしたコード・スニペットにも再利用する際には義務があります。これらのサードパーティー製コンポーネントの多くはオープンソースです。オープンソース・ソフトウェアは無料ですが、一定の義務を伴う別の種類のライセンスで管理されています。

さまざまな形態のソフトウェア・ライセンスがありますが、ライセンス非遵守は重大な問題となります。ライセンスなしで、またはライセンスの義務を遵守せずにコンポーネントを再利用した場合、著作権者から起訴される可能性があります。場合によっては、不正使用されたコンポーネントを含む製品の配布に対する差止命令を受けたり、損害を被ったり、独自のソース・コードの公開を余儀なくされることがあります。多くの企業は、サードパーティー製ソフトウェアの使用に「問題がない」ことを願っています。コードと組織を守るために、ライブラリやフレームワークを含め、独自に作成していないコードの使用条件を規定するソフトウェア・ライセンスを理解しておく必要があります。以下では、当社のトップ・オープンソース・ライセンスのリストおよびそれぞれの潜在的な法律上のリスクをご紹介します。

さまざまなタイプのソフトウェア・ライセンス

以下では、コードベースで再利用可能なコンポーネントに一般的な5つのタイプのライセンス・モデルと、一般的ではなく、誤って解釈されることの多いパブリック・ドメインのソフトウェア・カテゴリ、および比較的一般的なライセンスなしのソフトウェア・カテゴリについてご説明します。

パーミッシブ。パーミッシブ・ライセンスは、ソフトウェアの変更または再頒布方法に関する要件が最小限のソフトウェア・ライセンスです。通常、ソフトウェアを配布する際に著作権情報を記載した告知ファイルを含めることのみを許諾要件としているため、「帰属スタイル」ライセンスとしても知られています。オープンソース・ライセンスとしては、このタイプのソフトウェア・ライセンスが最も一般的です。このカテゴリの代表的な例としてApacheライセンス、BSDライセンス、MITライセンスがあり、特にMITライセンスが一般的です。

弱いコピーレフト。GNU Lesser General Public License（LGPL）は「弱いコピーレフト」スタイルのライセンスとも呼ばれ、ほとんど義務を負わずにオープンソース・ライブラリにリンクできます。LGPLライセンスを付与されたライブラリにソフトウェアを動的にリンクすれば、著作物全体を任意のライセンス（プロプライエタリ・ライセンスを含む）に基づき、最小限の要件で配布することができますが、静的リンクやライブラリの変更が複雑になります。また、LGPLライセンスのコンポーネントを別の方法で使用する場合には、コピーレフトの義務が伴います。他の弱いコピーレフト・ライセンス（MPL、CDDL、Eclipseなど）は、パーミッシブ・ライセンスとコピーレフト・ライセンスの中間に位置します。

コピーレフト。コピーレフト・ライセンスは、レシプロカル・ライセンスまたは制限付きライセンスとしても知られています。一般に、他のライセンスと比べて商用にはあまり適しません。最もよく知られている使用頻度の高いライセンスは、一般公衆利用許諾契約書（GPL）タイプのライセンスです。このタイプのライセンスを使用すると、同じソフトウェア・ライセンスに基づいて新しい著作物や翻案のソースコードを頒布する限りにおいて、ライセンスされたコードを変更して独自開発のコードに組み込んだ新しい派生物を頒布することができます （これに類似したライセンスにAffero General Public License [AGPL] がありますが、頒布時だけでなく、ホストされたデプロイでもトリガされるため、「SaaSの抜け穴」を塞ぐ役割を果たします）。問題は、これらのライセンスでは新しい派生物とともにソースコードも頒布する必要があるため、GPLライセンスを付与されたコードを含む独自開発の著作物のライセンスには、独自開発のソースコードの頒布が必要になるということです。ソースコードをユーザーや競合企業に公開することは、通常、企業にとってビジネス上の利益につながらないため、商用アプリケーションを製造する企業は、この種のライセンス条件に従ってソフトウェアを使用することを敬遠する傾向があります。

商用または独自開発。すべてのタイプのソフトウェア・ライセンスの中で、最も制限が厳しいライセンス。このタイプのライセンスは、一般に商用ソフトウェアに使用され、付与される権利に関して著作権者がコードの共有、リバース・エンジニアリング、変更、再配布、販売などを認めないという明示的な条件を表明しています。

デュアル。著作権者がユーザーに応じて異なるライセンス条件でソフトウェアを提供できるライセンス。コピーレフトなどの制限の厳しいオープン・ライセンスと商用ライセンスに基づいて配布されるデュアル・ライセンスのビジネス・モデルは普及が進んでいます。このモデルでは、オープンソース・ライセンスによってコードを手軽に入手して試すことができますが、商用目的でソフトウェアを使用する場合には、商用ライセンスの購入が義務付けられます。AGPLライセンスはこの目的で使用されることが多く、商業目的で使用する場合の制限を厳しくしたサーバーサイド・パブリック・ライセンスなどの新種も登場しています。

パブリック・ドメイン。パブリック・ドメインのソフトウェアもあります。一般に、ソフトウェア著作物は著作権によって保護されており、何らかの形でソフトウェアを使用するには、作成者または著作権者の許可、すなわちライセンスが必要ですが、パブリック・ドメインのソフトウェアには著作権が適用されず、誰でもソフトウェアを制限なく変更および使用することができます。ただし、パブリック・ドメインのコードは少なく、その定義は法域によって異なることを知っておく必要があります。

ライセンスなし。明示的なライセンスを持たないコードはパブリック・ドメインではありません。基本的に、ソフトウェアを使用するにはライセンスが必要です。したがって、使用しているソフトウェアに関連するライセンスを確認できない場合、著作権法に違反している可能性があります。

特定のソフトウェア・コードベースに適用されるライセンスを確認する方法

コードベース内のコンポーネントを規定するライセンスを特定する前に、コード内の全コンポーネントを一覧にしたソフトウェア部品表（SBOM）を作成する必要があります。ポリシー、プロセス、トレーニング、ソフトウェア・コンポジション解析（SCA）ツールを含めたプログラムを策定することで、正確なSBOMを長期的に維持できます。優れたSCAツールは、すべてのコンポーネントとコード・スニペットを見つける機能を備え、コンポーネント内の既知のセキュリティ脆弱性を特定するとともに、各コードに適用されるライセンス、また使用ライセンスが競合する可能性があるかどうかを教えてくれます。適切なツールがない場合や、M&A（合併・買収）取引などでは、信頼できる有能な第三者の監査によって適時に正確なスナップショットを取得することができます。

SBOMが作成されていれば、SCAツールまたは監査担当者の助力がある場合には特に、ほとんどのライセンスは理解しやすくなりますが、この記事では必ずしもそうならないことに注目しています。最善の方法は、オープンソースに精通したIP（知的財産）分野の弁護士にすぐに相談できる環境を整え、必然的に生じる複雑な問題について相談することです。

この投稿は2016年10月7日に発表され、2022年7月27日に更新されました。