OSSライセンスは数多くありますが、**「コピーレフトの強さ」**で分類すると一気に見通しが良くなります。配布する製品にとって重要なのは「自社コードにどこまで影響するか」。下の早見表で大枠をつかめます。

コピーレフトの4分類

分類代表ライセンス配布時の主な義務自社コードへの影響
許容型MIT, Apache-2.0, BSD, ISC, Zlib著作権表示・ライセンス文の同梱ほぼなし
弱（ファイル単位）MPL-2.0, EPL-2.0対象ファイルの改変ソース開示専有部分は非開示で結合可
弱（ライブラリ単位）LGPL-2.1, LGPL-3.0ライブラリのソース提供＋再リンク保証動的リンクなら専有を保てる
強GPL-2.0, GPL-3.0派生物全体のソース公開伝搬し得る（要注意）
ネットワークAGPL-3.0配布だけでなくSaaS提供でもソース提供SaaSでも回避不可

ポイント解説

  • 許容型：最も扱いやすい。表示を守れば商用・専有でも自由。Apache-2.0は加えて特許条項とNOTICE保持に留意。
  • 弱（ライブラリ）＝LGPL：「動的リンク＋利用者が差し替え可能（再リンク保証）」なら、自社の専有アプリを非公開のまま配布できます。静的リンクは要注意。
  • 強＝GPL：配布時、結合形態しだいで自社コードにも公開義務が伝搬し得ます。組込み・受託で最も注意。
  • ネットワーク＝AGPL：「配布していないから大丈夫」が通じない唯一の類型。SaaSでも義務が生じ得ます。

注意：表示は「宣言」、実体は別

「このOSS＝このライセンス」という表示はパッケージが宣言する代表ライセンスにすぎません。実際には、内部に別ライセンスの第三者コンポーネントや例外条項（例：GPL WITH FOSS-exception）が含まれることがよくあります。配布を前提にするなら、ソース単位のディープスキャンでの精査が安全です。

この早見表は大枠の理解のためのものです。実際の判断は利用形態（配布/SaaS/組込・リンク形態）と内部構成で変わります。