OSSライセンス違反が時限爆弾になる瞬間
M&Aの最終契約直前、買い手のCTOが対象企業のリポジトリに踏み込んだ瞬間、譲渡額の前提が音を立てて崩れる── そんな場面に、私はこの数年で何度も立ち会ってきました。引き金は財務でも顧客名簿でもなく、ソースコードに混入した「OSSライセンスの時限爆弾」です。
GPLに汚染されたコード片が買い手の中核プロプライエタリ製品とリンクされていた、AGPLのOSSをSaaSに組み込んでいるのにユーザーへのソース提供導線が存在しない、CC-NCの素材が商用バナーに使われ続けている── これらは仲介業者・税理士・会計士・弁護士の通常業務範囲では検出されません。検出されるのは買い手が技術DDに本気の人間を入れた瞬間か、買収後にコミュニティから告発状が届いた瞬間のどちらかです。
本記事はコンテンツ層の権利問題を扱った前回（著作権・肖像権の時限爆弾）の続編格として、「コードに眠る権利の時限爆弾」を独立論点で剥がしていきます。
1. なぜOSSライセンスがM&Aの最大級リスクに浮上したのか
1-1. 「無料で使える」OSSは、契約書を書いた覚えがなくても「ライセンス契約」が成立している
OSS（オープンソースソフトウェア）の最大の誤解は「無料＝自由に使える」という認識です。事実は逆で、OSSは「著作権者が提示するライセンス条件を、利用者が受け入れることを条件に、無償で利用を許諾する」契約です。GitHubからクローンした瞬間、npm installした瞬間、リポジトリ同梱のLICENSEファイルに記載された条項を契約として受け入れたものと見なされます。M&Aで譲渡対象のリポジトリに数百〜数千のOSSが含まれていれば、買い手はその全契約条件を丸ごと引き継ぐことになります。
1-2. 前回扱った著作権・肖像権が「コンテンツ」の問題なら、OSSは「コードそのもの」に内蔵された時限爆弾
前回の記事ではコンテンツ層の権利リスクを扱いました。これは「サイトに何が載っているか」という表層の問題です。OSSライセンス問題はその下層、サイトを動かしているコード自体に内蔵された時限爆弾です。コンテンツ層の侵害は削除や慰謝料で決着しやすい一方、コード層、特にコピーレフト系の違反は「ソースコード全公開命令」という回復不能な処分に発展する余地があり、ダメージのオーダーが2桁以上違います。
1-3. 仲介・税理士・会計士・弁護士の通常業務範囲では検出不可能な構造的事実
OSSライセンス問題が見過ごされ続ける最大の理由は関係する士業の誰の標準業務範囲にも入っていないことです。仲介業者は契約まとめ、税理士・会計士は数字、弁護士は契約条項。「リポジトリを開いて依存ツリーを展開しLICENSEファイルを精読する」作業は誰の標準工程にも組み込まれていません。買い手の経営企画部や財務系DD担当者にもこの作業を回せる人材は通常いません。結果として、譲渡対象のリポジトリは「数字の付随物」として一切検証されないまま受け渡されます。
2. コピーレフトの「伝播」構造 ── GPLが買い手のプロプライエタリ資産に襲いかかる
2-1. GPLの「派生著作物」概念が、リンク・組み込み・改変を経て商用コードに伝染する
GPLの核心は「派生著作物（derivative work）も同じライセンスで公開せよ」という条項です。GPLコードを取り込んで改変したり、自社コードとリンクさせて新たなプログラムを作ったりした場合、新たなプログラム全体がGPLの条件で配布されなければなりません。これがコピーレフト（著作権の連鎖）です。
買い手にとって深刻なのは「気付かないうちに伝播していた」ケースです。社内エンジニアがコピペしたサンプルコードがGPL由来だった、外注先がGPLライブラリを組み込んでいた、過去のM&Aで取り込んだ事業のコードに既にGPL汚染があった── 発生源を追跡しきれないまま買い手の中核プロダクトがGPLの傘下に入る事例が現実に存在します。
2-2. 静的リンク・動的リンク・プロセス分離で汚染範囲はどう変わるか
GPL汚染の範囲はコードの結合形式に依存します。静的リンクはほぼ確実に派生著作物と判定。動的リンクはFSF解釈では派生著作物だが企業側で否定する見解もありグレー。プロセス分離（パイプ・ソケット経由通信）は派生著作物に該当しないのが通説です。M&Aの場面では「グレーゾーンを白扱いで放置」状態が頻発し、社内で問題視していなくても買い手の法務はリスクとして必ず議題に上げ値下げ交渉のテコとして機能します。売り手は事前にプロセス分離への切り替えや商用ライセンス購入による回避を進めるのが鉄則です。
2-3. LGPLが安全と誤解されている実態 ── 改変した瞬間にGPL同等の公開義務が発生する罠
LGPLは「動的リンクで使う限りプロプライエタリ製品から呼び出せる」とされ商用利用者から「弱コピーレフト」として安全視されてきました。しかしLGPLを改変した瞬間、改変版にはLGPLの公開義務が発生し、密結合で組み込めばGPL同等の公開義務に伸長する余地があります。DDで頻発するのが「LGPLライブラリを使っている」という説明と「実はバグ修正のためにライブラリ本体に手を入れていた」という現場実態の乖離です。改変の有無こそがLGPLの安全性を左右する分岐点であり、コミット履歴を遡って改変箇所を特定する作業を初手として組み込む必要があります。
3. AGPLというSaaS時代の地雷 ── 「サーバ提供＝頒布」と見なす劇薬ライセンス
3-1. AGPLはSaaS提供を「ネットワーク経由の頒布」と定義し、ユーザーへのソース提供義務を発生させる
AGPL（GNU Affero General Public License）はGPLのSaaS抜け穴を塞ぐために設計されたライセンスです。GPLは「ソフトウェアを配布した時」に公開義務を発生させますが、SaaSは本体を配布せずネットワーク経由で機能を提供するため公開義務が発生しないという解釈が成立してしまいます。AGPLはこの抜け穴を塞ぎ、「ネットワーク経由でユーザーに機能を提供すること」そのものを公開義務の発生事由として明記しました。AGPLのコードを使ったSaaSを提供する企業は、利用ユーザー全員に対し改変版を含むソースコード全体を提供する義務を負います。世界唯一の劇薬条項であり、SaaS事業者にとって最大級の地雷です。
3-2. 「社内利用だから問題ない」という誤解 ── 社外から1人でもアクセスした瞬間に発動する
AGPLについて最も多い誤解は「社内利用なら公開義務は発生しない」です。GPLは社内利用なら配布が発生しないため公開義務もありませんが、AGPLは「ネットワーク経由で機能を提供した相手」全員に対して公開義務を発生させる構造です。社員のみのイントラネットツールなら一応セーフでも、外部委託先・取引先・顧客が1人でもアクセスする構成なら、その時点で公開義務が発動します。
対象事業がBtoB SaaSや会員制サービスを提供している場合、「社内利用」の境界線は限りなくグレーです。買い手側DDではAGPL系コードへのアクセス導線を持つ全ユーザーカテゴリを棚卸しし、各カテゴリに対する公開義務の有無を整理する必要があります。
3-3. AGPL汚染されたSaaSを譲り受けた瞬間、買い手の独自開発機能まで開示請求される
AGPLライセンスのコードを基盤にしたSaaSに買い手が独自開発機能を追加した場合、その独自機能のコードまで公開義務の対象になります。これは買収後に買い手側で投じた開発費用が、そのまま競合他社にも開示される構造を意味します。
AGPL汚染の有無は、譲渡対象がSaaSモデルである場合譲渡対価の前提を覆すレベルの重大論点です。買い手はLOI段階でSBOMと依存ライセンス一覧の事前開示を交渉条件として組み込み、AGPL系の混入が発覚した場合の値下げまたは破談条項を契約書に必ず盛り込むべきです。
4. ライセンス互換性とコード外側の権利 ── 「混ぜるな危険」と素材・フォントの落とし穴
4-1. ライセンス互換性の迷路 ── デュアルライセンスOSSの「商用ライセンスを買い忘れた」状態
OSSライセンスは「ゆるい順」で並べられても相互互換性は単純な階層関係で整理できません。Apache 2.0はGPLv2と非互換（GPLv3は互換）であり、両者を組み合わせて1プログラムを構成すると配布そのものが違反になります。さらにQt・MySQL・Highchartsなど一部OSSはデュアルライセンス（GPL系＋商用）形式で提供され、プロプライエタリ製品への組み込みには商用ライセンス購入が必要です。M&A実務で頻発するのが、初期は購入していたが契約更新を怠ったまま使い続けているケース。「商用ライセンスを買い忘れたまま運用」状態は、その時点でGPL条件下で運用していたとみなされ、GPL汚染と同等のリスクを抱えます。
4-2. CC-NC素材・商用フォント・Webフォント規約 ── コードの外側にある権利の時限爆弾
コードの外側にも複数の権利地雷があります。第一にCC-NC（非商用限定）素材。FlickrやWikimedia Commonsから拾った画像にCC-NCが混入していれば、商用サイトでの利用そのものが著作権侵害です。第二に商用フォントの無断利用。モリサワ・フォントワークス・Adobeフォント等は「Web埋め込み・電子書籍配布・ロゴ商標利用」に個別ライセンス条件があり、「PCにインストールしてあるから自由に使える」誤解のままWebフォント化・画像化・PDF埋め込みを行う事例が頻発します。第三にWebフォントサービス規約違反。Google Fonts・Adobe Fonts等は規約・対応フォントを定期変更しており、契約名義と譲渡時の名義変更可否を契約書類と実装の両方から照合する必要があります。
4-3. NOTICE・LICENSEファイル不備が、それ自体でライセンス違反を構成する
OSSライセンスの多くは「再配布時に著作権表示・ライセンス条文・NOTICE記載を保持すること」を最低条件として要求します。MIT・BSD・Apache 2.0など寛容ライセンスでも表示義務を怠ればそれ自体が違反です。Dockerイメージに同梱して顧客環境で動かしている、SaaSのフロントエンドJSにバンドルしている── 表示義務が抜け落ちている事例は現場感として多数派です。
5. SBOMと検証ツールチェーン ── 技術者DDが1日で剥がし切る武装
5-1. SBOMが買い手DDの第一級証拠になった理由
SBOM（Software Bill of Materials）はソフトウェア製品に含まれる全コンポーネントを網羅した「部品表」です。2021年5月の米国大統領令14028号で連邦政府機関納入ソフトウェアにSBOM提出が義務化されて以降、米国主要企業は調達条件としてSBOM提出を要求する流れが定着しました。フォーマットはSPDX（ISO/IEC 5962:2021、政府調達系で重視）とCycloneDX（OWASP主導、脆弱性連携に強い）の2つが主流で、形式を指定せず「SBOMください」と求めるとフリーフォーマットのスプレッドシートが提出され機械的検証ができない状態に陥ります。SBOM未整備の譲渡対象は「ライセンス管理体制が存在しない」証拠そのものとして扱われ、整備のための追加コストが譲渡対価の値下げ材料に直結します。
5-2. license-checker・FOSSA・npm audit ── 軽量検証から商用SCAまでのツール選定
技術DDの初手は軽量ツールでの全体把握です。license-checker（Node.js環境で依存パッケージのライセンス一覧を即出力）、licensee（GitHub製Ruby gem）、askalono（Mozilla採用のRust製）。これらで1時間以内にGPL/AGPL/SSPL等コピーレフト系の混入有無を即座に把握できます。
商用SCA（Software Composition Analysis）としてFOSSA・Black Duck・Snyk License Complianceが定番で、深い依存ツリー解析・互換性マトリクス自動判定・コピーレフト伝播範囲の可視化を提供します。並行して各言語の脆弱性監査（npm audit・pip-audit・bundler-audit・cargo audit・govulncheck）を走らせれば、「ライセンス違反＋既知脆弱性＋未パッチ放置」の3点セットが可視化され、買い手は値下げ交渉のテコを多面的に得ます。
5-3. ScanCode Toolkit・FOSSologyというOSSベースの検証スタック
商用SCA契約を持たない買い手DDチームでも、OSSベースで実用に耐える解析が可能です。ScanCode Toolkit（AboutCode Project提供、ライセンス・著作権・依存関係を網羅検出）、FOSSology（Linux Foundation配下のWebベース解析）、syft（CycloneDX/SPDX出力対応のCLI）の組み合わせで、商用SCAに匹敵する検証品質をコストゼロで実現できます。
6. ライセンス違反が露呈した時の実害 ── 過去判例と業界の自浄圧力
6-1. BusyBox訴訟・SFCの警告書 ── GPL違反で「ソース全公開」を命じた米国判例の系譜
GPL違反で「ソース全公開」が現実に命じられた代表的判例として、BusyBox訴訟（2007年以降、SFLC主導でCisco・Westinghouse等が和解）、Versata訴訟（2014年）があります。これらの判例で確立されたのは、GPLが単なるライセンス契約ではなく、著作権者が著作権法に基づき直接行使できる権利として裁判所により執行可能であるという事実です。指摘は著作権者本人だけからではなく、SFC（Software Freedom Conservancy）はLinux・Git・BusyBox等の著作権を擁護する非営利団体として、企業違反に対し警告書送付→和解交渉→訴訟のフェーズを踏みます。「日本ではGPLは執行されない」という思い込みはもはや成立しません。
6-2. 違反公表で技術コミュニティに一夜で拡散される自浄圧力と、買い手のPR事故
OSSライセンス違反は、Hacker News・GitHub Issues・Reddit・X（旧Twitter）の技術コミュニティで、一夜にして世界中に拡散します。「あの企業がGPL違反している」という指摘は技術者コミュニティで最も注目度の高いコンテンツのひとつであり、企業ブランド価値を瞬時に毀損します。M&Aで買収した事業のライセンス違反が買収完了後にコミュニティから指摘されるシナリオは、買い手にとって最悪のPR事故です。
6-3. 表明保証違反としてクローバック請求できるか ── 契約条項に「ライセンス適合性表明」を必ず入れる作法
M&A契約書には「対象事業のソフトウェア・コンテンツが第三者の知的財産権を侵害していないこと」を売り手が表明保証する条項が必ず入ります。OSSライセンス違反もこの表明保証の対象に含めて読まれるのが通説ですが、技術者DDを経験した買い手は「OSSライセンスの全てを遵守している」旨の独立した表明条項を追加するのが作法です。
違反が事後に発覚した場合、表明保証違反として譲渡対価の一部返還（クローバック）・損害賠償・場合によっては契約解除が請求可能になります。表明条項の文言の精度こそが、買い手の最後の防衛ラインです。
7. 売り手が「クリーンなコード」で価格を守るための逆説的アプローチ
7-1. SBOMを譲渡前に自主作成し、ライセンス棚卸しを完了させた売り手のIMが最も信頼される
売り手が譲渡前にSBOMを自主作成し依存OSSのライセンス棚卸しを完了させた状態でIMを提出した場合、買い手の心象は劇的に変わります。「ライセンス管理体制が組織として存在する」事実が、それ自体で対象事業の運営品質を裏付ける証拠になるからです。SBOM作成はScanCode Toolkit・FOSSology・syftなど無償ツールで内製化でき、譲渡準備の数ヶ月前から取り組めば外注費を最小化しつつ買い手にとって最高の信頼材料を整備できます。
7-2. 「違反箇所の自主開示＋是正計画」セットでの提出が、減額交渉ではなく信頼形成に転じる
SBOM作成過程で過去の違反が自社内で発覚するケースは現実に発生します。ここで売り手が選ぶべきは隠蔽ではなく自主開示です。違反箇所を一覧化し、それぞれに是正計画（商用ライセンス切り替え／代替OSSへの差し替え／コード書き直し／義務遵守）をセットで提出すれば、買い手はこれを減額材料ではなく信頼材料として受け取ります。隠蔽したまま譲渡を進めて買収後に発覚すれば、表明保証違反として譲渡対価の数十%が削られる可能性があります。自主開示なら是正コストを譲渡対価から事前に控除する形で着地でき、最終的な手取り額は自主開示の方が確実に大きくなる逆説が成立します。
7-3. クリーンなコードベースほど指値交渉に強い ── 結果として手取り額が守られる構造
ライセンスクリーンなコードベースは買い手側のリスクプレミアムを最小化します。買い手は「想定外の請求が後から発生しない」前提で譲渡対価を提示できるため盛らなくても満額に近い金額が出る構造です。逆に管理が雑なコードベースは買い手が大きなリスクプレミアムを織り込むため譲渡対価が構造的に下がります。盛ったIMで高値を提示してもDDで違反が発覚した瞬間に値段が崩れる── クリーンに整えた方が、最終的な売り手のキャッシュ受け取り額は守られる。これが本記事を通じて売り手側に共有したい逆説です。
8. コードを書ける買い手と、コードを読める伴走者だけが、OSS時限爆弾を解除できる
ここまで、コピーレフトの伝播、AGPLというSaaS時代の劇薬、ライセンス互換性とコード外側の権利、SBOMと検証ツールチェーン、判例から見える実害、売り手の逆説的アプローチを順に剥がしてきました。これらに共通するのは「コードを書ける人間でなければ、そもそも論点の存在すら認知できない」事実です。仲介業者は契約まとめ、税理士・会計士は数字、弁護士は契約条項。誰の業務範囲にも、リポジトリを開いて依存ツリーを展開しLICENSEファイルを精読しSBOMを生成して互換性マトリクスを叩く作業は入っていません。
本シリーズで触れてきたAdsense一発BANリスク、会員DB×改正個情法、著作権・肖像権、IM粉飾15パターン── これら全てに共通するのは「数字に出ない領域に、事業価値を毀損する時限爆弾が眠っている」構造です。OSSライセンスはその中でも最も技術的な深さを要求される領域であり、買い手側の技術者DD能力が問われる最前線です。
買い手としては、SBOMとSCAレポートの提出を譲渡対価確定前の工程に組み込むこと。売り手としては、譲渡準備の数ヶ月前からSBOM自主作成と棚卸しに着手すること。両者にとってこの工程は「面倒な追加作業」ではなく、譲渡を破談・減額の地獄から守る最後の防壁です。コードを書ける買い手と、コードを読める伴走者。この2者だけが、OSSの時限爆弾を爆発前に解除できます。
