オープンソース ライセンスのコンプライアンス: ソフトウェア会社のための実践ガイド

平均的な商用アプリケーションには 77% のオープンソース コードが含まれており、500 以上の依存関係にまたがっています。 各依存関係には、特定の義務を伴う独自のライセンスが適用されます。これらの義務に違反すると、会社は訴訟、コードの強制開示、風評被害にさらされることになります。しかし、ほとんどの企業には、オープンソース ライセンスを追跡または遵守するためのプロセスがありません。

このガイドでは、ライセンスの分類から自動スキャンと SBOM の生成に至るまで、オープンソース ライセンス コンプライアンスのための実践的なフレームワークを提供します。

重要なポイント

• すべてのオープンソース ライセンスが同じというわけではありません。寛容なライセンスではほぼすべてのものが許可されますが、コピーレフト ライセンスでは変更を共有する必要があります。
• ソフトウェア部品表 (SBOM) は政府調達における法的要件になりつつあります (米国大統領令 14028)
• CI/CD での自動ライセンス スキャンにより、非準拠の依存関係がコードベースに侵入するのを防ぎます
• コピーレフトの「感染」リスクは現実的です。1 つの GPL 依存関係により、アプリケーション全体をオープンソースにすることが義務付けられる可能性があります

---

ライセンス カテゴリ

許容ライセンス (低リスク)

商用利用も安全です。 配布物にはライセンステキストと著作権表示を含めてください。さらに、Apache 2.0 では、元のコードへの変更に注意する必要があり、特許ライセンスが含まれています。

弱いコピーレフト (中リスク)

注意して使用してください。 LGPL ライブラリは、静的にリンクされるのではなく、共有 (動的) ライブラリとして保持してください。 MPL ライセンスのコードは、独自のコードとは別のファイルに保管してください。

強力なコピーレフト (高リスク)

商用ソフトウェアの場合、最も高いリスクがあります。 アプリケーションで GPL コードを使用すると、アプリケーション全体を GPL に基づいてリリースすることが必要になる場合があります。 AGPL はこれをサーバー側ソフトウェアに拡張します。バイナリを配布しない場合でも、ソフトウェアを Web サービスとして提供すると、コピーレフト義務が発生します。

---

コンプライアンスのワークフロー

ステップ 1: SBOM を生成する

# For Node.js projects (using CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json --spec-version 1.5

# For Python projects
pip install cyclonedx-bom
cyclonedx-py environment --output sbom.json

# For multi-language projects (using Syft)
syft . -o cyclonedx-json > sbom.json

ステップ 2: ライセンス準拠をスキャンする

# Using license-checker for Node.js
npx license-checker --production --json --out licenses.json

# Using scancode-toolkit (comprehensive, all languages)
scancode --license --copyright --output-json scan-results.json .

ステップ 3: 分類と承認

承認されたライセンス リストを作成します。

{
  "approved": [
    "MIT", "BSD-2-Clause", "BSD-3-Clause", "Apache-2.0",
    "ISC", "0BSD", "Unlicense", "CC0-1.0"
  ],
  "conditional": [
    "LGPL-2.1", "LGPL-3.0", "MPL-2.0", "EPL-2.0"
  ],
  "prohibited": [
    "GPL-2.0", "GPL-3.0", "AGPL-3.0", "SSPL-1.0",
    "EUPL-1.2", "OSL-3.0"
  ]
}

ステップ 4: CI/CD の統合

# .github/workflows/license-check.yml
name: License Compliance
on: [pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: pnpm install --frozen-lockfile

      - name: Check licenses
        run: |
          npx license-checker --production --excludePackages "" \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --summary

---

SBOM (ソフトウェア部品表)

SBOM が重要な理由

• 米国大統領令 14028 では、米国政府に販売されるソフトウェアに SBOM が必要です
• EU サイバーレジリエンス法 により、EU 内で販売されるソフトウェアには SBOM が義務付けられます
• サプライ チェーン セキュリティ: SBOM により、脆弱性への迅速な対応が可能になります (log4j が発生すると、影響を受けているかどうかがわかります)
• 顧客の信頼: 企業のバイヤーは調達時に SBOM を要求することが増えています

SBOM規格

推奨事項: ほとんどのソフトウェア会社向けの CycloneDX。これはよりシンプルで、ツールのサポートが優れており、業界のデフォルトになりつつあります。

---

一般的なコンプライアンス シナリオ

シナリオ 1: Node.js Web アプリケーション

一般的な node_modules ディレクトリには 500 ～ 2,000 のパッケージが含まれています。大多数は MIT または ISC ライセンスを使用します。よくある問題:

• GPL を使用した推移的な依存関係 (直接追加しませんでした)
• UNKNOWN ライセンス フィールドは手動調査が必要です
• 単一パッケージ上の複数のライセンス (例: 「MIT OR Apache-2.0」)

アクション: npx license-checker --production を毎週実行します。許可されていないライセンスを調査します。 GPL の依存関係を寛容な代替案に置き換えます。

シナリオ 2: Odoo モジュールの開発

Odoo コミュニティ エディションは LGPL v3 です。 Odoo Enterprise は独自のものです。カスタム モジュール:

• コミュニティ モジュール: LGPL v3 または互換性がある必要があります (配布されている場合)
• プライベート内部モジュール: 配布されていないため、LGPL は適用されません
• エンタープライズ アドオン: Odoo Enterprise ライセンス条項に準拠する必要があります

シナリオ 3: AGPL 依存関係のある SaaS

SaaS アプリケーションが AGPL ライセンスのコード (SSPL に切り替える前の MongoDB など) を使用している場合は、次のいずれかを行う必要があります。

1. アプリケーションのソース コード全体を AGPL に基づいてリリースします。
2. AGPL 依存関係を削除し、代替手段を使用します。
3. AGPL プロジェクトから商用ライセンスを取得します (利用可能な場合)

サーバー側で AGPL コードを使用すると、バイナリを「配布」しない場合でも、コピーレフトの義務が生じます。

---

よくある質問

API で GPL ライブラリを使用すると、API をオープンソースにする必要がありますか?

それは使い方次第です。 GPL ライブラリがアプリケーションに (静的または動的に) リンクされている場合、FSF の立場は、アプリケーションは「二次的著作物」であり、GPL に基づいてライセンスを取得する必要があるというものです。ネットワーク API を介して GPL ソフトウェアと通信する場合 (たとえば、GPL ライセンスのデータベース サーバーを使用する場合)、それは通常、二次的著作物とみなされません。特定の事件については弁護士に相談してください。

依存関係によってライセンスが変更された場合はどうなりますか?

あなたは、将来のライセンスの変更ではなく、コードを取得したときのライセンスに拘束されます。ただし、新しいライセンスを使用して新しいバージョンに更新すると、新しいライセンスがそのバージョンに適用されます。これが、バージョン固定の SBOM が重要である理由です。SBOM には、使用しているバージョン (およびライセンス) が正確に文書化されています。

「不明」ライセンスの依存関係はどのように処理すればよいですか?

パッケージのリポジトリで LICENSE ファイルを確認してください。ライセンスが指定されていない場合、コードは技術的に完全な著作権保護下にあります。コードを使用、変更、配布する権利はありません。ライセンスを見つけて (標準以外の場所にある可能性があります)、作成者にライセンスの追加を要求するか、依存関係を明確にライセンスされている代替のものに置き換えます。

MIT ライセンスのパッケージの帰属を示す必要がありますか?

はい。 MIT およびほとんどの寛容なライセンスでは、ソフトウェアを配布するときに著作権表示とライセンス テキストを含める必要があります。 Web アプリケーションの場合、これは通常、THIRD-PARTY-NOTICES ファイル、またはすべてのオープンソース コンポーネントとそのライセンスをリストしたページを含めることを意味します。

---

コンプライアンス プログラムの構築

四半期ごとのコンプライアンスレビュー

1. すべてのプロジェクトの SBOM を再生成
2. 前回のレビュー以降に追加された 新しい依存関係をスキャン
3. 更新されたパッケージで ライセンスの変更を確認
4. 表示された「不明」ライセンスを確認します
5. 新しいライセンスが見つかった場合は、承認されたライセンス リストを更新します
6. 監査証跡のために SBOM スナップショットをアーカイブ

コンプライアンスの役割

小規模なチームの場合、軽量なコンプライアンス プログラムは四半期あたり 2 ～ 4 時間かかり、製品の発売後またはデュー デリジェンス中にコンプライアンス問題を発見するためのはるかに大きなコストを回避できます。

---

次に何が起こるか

ライセンスのコンプライアンスはソフトウェア ガバナンスの 1 つの側面です。独自のコードの場合は IP 保護、ベンダー ソフトウェアの場合は SaaS 契約の要点、セキュリティ コンプライアンスの場合は サイバーセキュリティ規制要件 と組み合わせます。

オープンソースのコンプライアンス監査および SBOM 生成サービスについては、ECOSIRE にお問い合わせください。

---

ECOSIRE が発行 -- 企業が責任を持ってオープンソースを使用できるよう支援します。