オープンソースライセンス衝突検出の実務：5 つの典型パターンとエンジニアリング対処法

ライセンスを一つずつ理解するのは難しくない。難しいのは組み合わせだ。現代のアプリケーションは数千のコンポーネントと数十種のライセンスを抱え、その相互の互換関係は複雑なマトリクスを成す。どこか一箇所の衝突が、製品全体の配布の適法性を揺るがしうる。本稿はエンジニアリングチームが実際に直面する 5 つの衝突パターンと、検出・対処をツールで流れ作業化する方法を扱う——法律事務所の解説記事には書かれないが、納品検収で実際にチェックされる部分である。

5 つの典型的な衝突パターン

その 1：強いコピーレフトの専有製品への混入。最も古典的で最も深刻——クローズドソース納品物への GPL コードの混入だ。入口は明示的な依存宣言であることは稀で、コピーされたユーティリティ関数、フォーク後に改名されたモジュール、委託先が「借用」した実装であることが多い。マニフェストは清潔なまま、衝突はファイルレベルに潜む。各層の伝染ロジックはライセンスリスクマップで詳述した。

その 2：オープンソースライセンス同士の非互換。最も有名な組み合わせは Apache-2.0 と GPLv2 である。Apache-2.0 の特許条項が GPLv2 の要求と衝突し、両者のコードは同一の派生物に統合できない（GPLv3 はこの問題を解決した）。CDDL と GPL も同様で、ZFS が長らく Linux カーネル本流に入れなかった理由がこれだ。個々のライセンスは「問題ない」のに、組み合わせが問題になる。

その 3：宣言と実体の不一致。パッケージのメタデータは MIT を宣言しているのに、中身に GPL ファイルが混じっている——上流の作者自身が他人のコードをコピーしていたケースだ。マニフェストレベルのツールは宣言を信頼するため、この種の衝突はファイルとスニペットの実体照合でしか発見できない。稀な話ではない。大規模な多言語プロジェクトでは、宣言と実体の乖離率はマニフェストのみの監査結論を無意味にするに足る。

その 4：デュアルライセンスの選択記録の欠如。MySQL クライアントライブラリや Qt のようなデュアルライセンス（GPL/商用）コンポーネントは、どちらのライセンスで配布するかの明示的な意思決定と記録が必要だ。記録がなければ、監査では最も厳格な解釈——通常は GPL——が適用される。

その 5：弱いコピーレフトの境界破壊。LGPL コンポーネントは安全に使えるはずだが、静的リンク、ソース改変後の非公開、コードの抜き出しと自モジュールへのインライン化は「ライブラリ境界」を突き破り、弱い伝染を現実の義務へ格上げする。

検出のエンジニアリング：3 層の段階的アプローチ

第 1 層はマニフェスト解析。依存宣言を読み、コンポーネントと宣言ライセンスのベースラインを素早く構築する——無料の CleanSource SCA コミュニティ版で完結する。第 2 層はファイル・スニペットレベルの検証。ソースコードそのものにライセンス文認識、著作権ヘッダー解析、コード指紋照合をかけ、「宣言の外」にある実体を発見し、宣言と実体の一致を検証する——これにはスニペットレベル検出が必要だ。第 3 層は衝突判定。ライセンス互換マトリクスと配布形態（対外納品/SaaS/内部利用）に基づいて衝突項目を自動計算し、深刻度別に出力する。

要となる設定は配布形態を判定の入力にすることだ。同じ AGPL コンポーネントでも、社内ツールなら低リスク、SaaS なら重大——配布形態を離れた衝突論は誤検知か見逃しのどちらかである。

4 段階の対処プレイブック

検出後はコストの低い順に進む。置換（同機能の寛容型ライセンス代替品。ツールが候補を推薦できることが多い）、隔離（プロセス分離、動的リンク、ネットワークインターフェース経由の呼び出しで伝染境界を製品の外に置く。隔離の有効性はアーキテクチャレビューで確認する）、履行（ライセンス要求に従い該当部分を公開し帰属表示を添付する。非中核モジュールの公開コストが置換より安いこともある）、商用ライセンス取得（デュアルライセンスの商用オプション購入、または権利者との交渉）。

すべての対処決定は台帳に記録する。どのコンポーネントで、何の衝突で、どの対処を選び、誰が承認したか——この記録が顧客デューデリジェンスと輸出認証におけるあなたの証拠チェーンになる。

最後にひとつの経験則

ライセンス衝突対応が最も高くつくのは「納品 2 週間前に始める」ときだ。3 層の検出を CI に組み込み、衝突を持ち込まれたその日に遮断すれば、対処コストは納品前の突貫作業の 10 分の 1 で済む。コンプライアンスは監査イベントではなく、常時開いているゲートである。