OSSライセンス混在の落とし穴、AGPLv3リポジトリに潜む「All Rights Reserved」を検出する方法

マルチエージェント連携基盤をOSS（オープンソースソフトウェア）として採用する前に、ライセンス表記の一貫性を確認しているでしょうか。

この記事は、社内でOSSのワークスペース基盤やエージェント連携ツールの採用を検討しているアーキテクトやテックリードに向けたものです。ライセンス確認を「一度READMEを見れば終わり」で済ませてしまっている場合、思わぬ落とし穴があるかもしれません。参考になれば幸いです。

事例として、ドキュメント・タスク・メール・通話・CRM（顧客管理）・エージェントを統合するワークスペース基盤「Macro」のリポジトリ構成が挙げられます。ルート直下の LICENSE.txt はAGPLv3（GNU Affero General Public License v3、ネットワーク経由の利用でもソース公開義務が発生する強いコピーレフトライセンス）を掲げています。ところが同じリポジトリ内の apps/web/LICENSE には「Copyright 2023 CoParse, Inc. All rights reserved.」という、権利をまったく開放しない全権保持の記述が存在します。

何が起きるか

この状態は、リポジトリ全体が単一のライセンスで統一されているという前提を崩します。

ルートのAGPLv3だけを見て「このコードは自由に改変・再配布できる」と判断すると、apps/web 配下のファイルについては権利者の許諾なく使えない可能性が残ります。スクリーンショットやアセット、Webアプリのソースコードが対象になり得る、という点が問題の核心です。

影響範囲は法務リスクだけではありません。フォーク（リポジトリを自分の環境に複製する操作）して社内改造版を作る場合、どのディレクトリがどのライセンス配下にあるかを誤認したまま配布・提供してしまうと、後から差し戻しや削除対応が必要になるおそれがあります。特にSaaS化やクライアントへの納品物に組み込む場合は、契約上の説明責任にも直結します。

なぜ起きるか

原因を段階的に分解すると、3つの層に分けられます。

1つ目は、モノレポ（複数のアプリやパッケージを1つのリポジトリで管理する構成）特有の事情です。Macroはドキュメント・メール・CRM・エージェント機能を1つのリポジトリに統合しており、コア部分とWebアプリ部分の出自や権利関係が異なるまま統合された可能性があります。

2つ目は、ライセンスファイルの「上書き粒度」に対する認識不足です。GitやGitHubの慣習では、ルートの LICENSE はリポジトリ全体の既定値であり、サブディレクトリに個別の LICENSE ファイルがあればそちらが優先されるという明文の規約はありません。プロジェクトごとに解釈が異なるため、利用者側が両方を確認しないと矛盾に気づけません。

3つ目は、レビュー体制の問題です。READMEやライセンスバッジだけを見て導入判断をするワークフローでは、ディレクトリ単位のライセンスファイルまで目が届きません。特に「スターが伸びている」「GitHub Trendingで1位になった」といった注目度の高さが、ライセンス精査を後回しにする圧力として働くケースもあります。

自分のプロジェクトが該当するか確認する方法

対象がMacroかどうかに関わらず、外部OSSを採用する前に以下を確認する価値があります。

git clone https://github.com/macro-inc/macro.git
cd macro
find . -iname "LICENSE*" -not -path "./node_modules/*"
cat LICENSE.txt
cat apps/web/LICENSE
git log -1 --oneline
git rev-parse HEAD

find コマンドでリポジトリ内の全 LICENSE* ファイルを列挙し、内容が矛盾していないかを目視で比較します。

もう1つの確認軸は、依存関係全体のライセンススキャンです。Node.js系プロジェクトであれば license-checker や licensee といったツールで、直接依存だけでなく間接依存のライセンスも一覧化できます。モノレポの場合はパッケージ単位でスキャン範囲を分けないと、矛盾するライセンスが1つのレポートに混在して見落としにつながります。

バージョン管理の観点では、フォーク元との差分がゼロであることの確認も重要です。

git remote add upstream https://github.com/macro-inc/macro.git
git fetch upstream main
git rev-list --left-right --count upstream/main...HEAD

このコマンドで upstream との前後関係（何コミット進んでいて何コミット遅れているか）が数値で出ます。ライセンス確認の前提として、どのコミットSHAを見ているかを固定しておかないと、後から「確認した時点と違う」という水掛け論になりかねません。

対策の手順

矛盾するライセンスを見つけた場合、以下の順で対応するのが妥当です。

ディレクトリ単位でライセンス適用範囲を洗い出す（コア/Webアプリ/ドキュメントなど機能単位で分類）
矛盾を発見した時点で、そのファイル・ディレクトリを利用対象から一時的に除外する
リポジトリのIssueまたはメンテナー宛の問い合わせで、公式な意図を確認する
確認が取れるまで、当該範囲のコードを製品コードベースに取り込まない

ライセンスファイルが複数存在するリポジトリは、ルートだけでなく全サブディレクトリを走査してから採用判断を下すべきです。

技術的負債の観点でも、この確認を怠るコストは無視できません。ライセンス不整合を把握せずに製品に組み込んでしまうと、後から該当コードを差し替える作業は、通常のリファクタリングよりもはるかに大きな工数がかかります。監査対応やクライアントへの説明も発生するため、初期導入時のコストとしてライセンス精査を組み込んでおく方が結果的に安く済みます。

なお、AGPLv3自体もネットワーク経由でサービス提供する場合にソースコード開示義務が発生する、比較的制約の強いライセンスです。SaaSとして提供する予定のあるプロジェクトであれば、AGPLv3単体でも社内ポリシーとの整合性を別途確認しておく必要があります。

まとめ

OSSのワークスペース基盤やエージェント連携ツールを採用する際は、README記載のライセンスバッジだけで判断しないことが肝心です。

find . -iname "LICENSE*" でリポジトリ内の全ライセンスファイルを洗い出す
ディレクトリごとの適用範囲が矛盾していないか目視で比較する
矛盾を見つけたら該当範囲を除外し、メンテナーと法務に確認を取ってから採用する
upstreamとのコミット差分を固定し、いつの時点の確認かを記録に残す

まずは自社で採用中、あるいは検討中のリポジトリに対して find . -iname "LICENSE*" を1回実行してみてください。それだけでも、見落としていた矛盾に気づける可能性があります。