はじめに：その「動くコード」、"使っていいか"は誰か確認しましたか
AIにコードを書いてもらう。もう、当たり前になりましたよね。
正直に言いましょう。僕らはAIが出したコードに対して、だいたい2つのことを確認しています。ひとつは 「ちゃんと動くか」 。もうひとつは、意識が高い現場なら 「安全か（脆弱性はないか）」 。ここまでは、テストを書いたりレビューしたりで、だんだん文化になってきました。
でも、3つ目の問いが、すっぽり抜け落ちてる気がするんです。
それが 「このコード、"ライセンス的に"会社で使っていいの？」 という問いです。
考えてみてください。AIが提案してくれたその20行、実は世界のどこかのGPLライセンスのリポジトリにある実装、ほぼそのままだったら？ そのコードをあなたのプロダクトに入れて、お客さんに納品したり、有償SaaSとして売ったりした瞬間、「このプロダクト全体のソースコードを公開してください」という義務が、あとから降ってくるかもしれない。しかも、元のライセンス表示（誰が書いた、どのライセンスか）は、AIの出力からはきれいに剥がれていて、誰も気づかない。
こわいのは、「動く」し「安全」でも、この問題は起きるということなんです。テストは全部グリーン。脆弱性スキャンもクリーン。それでも、由来（来歴）がアウトなら、使っちゃいけない。検証している"軸"が、そもそも違うんですよね。
この記事は、その第3の軸 ―― 「使っていいか（ライセンス）」を、気合いや目視じゃなくて"仕組み"で検証する ための実践ガイドです。無料のツールから始められる4段のパイプラインを、CIに組み込むところまで持っていきます。
この記事の守備範囲（先に線引きしておきます）
- これは 「動くが危険なコード（SQLインジェクションやXSSなどの脆弱性）」の話ではありません 。それは別軸の検証で、以前に書きました。
- これは 「AIが存在しないパッケージ名をでっち上げる（パッケージ幻覚・slopsquatting）」の話でもありません 。それも別問題です。
- この記事が扱うのは、「実在するOSSのコードが、ライセンス表示なしにあなたのコードへ静かに混ざり込む」 という、来歴とライセンスの問題です。
なぜAIの書いたコードに、ライセンスの地雷が埋まるのか
まず「なんでそんなことが起きるの？」を、構造として理解しておきましょう。ここが腑に落ちないと、対策が"お守り"になってしまうので。
理由はシンプルです。大規模言語モデル（LLM）は、大量の公開ソースコードを学習して作られている から。GitHubをはじめとする世界中のOSSが、学習データに含まれています。その中には、自由に使える寛容なライセンスのコードもあれば、GPLやAGPLのような「コピーレフト」 ―― つまり「これを使うなら、あなたのコードも同じ条件で公開してね」という強い条件つきのコードも、当然たくさんある。
AIは、学習したパターンを再構成して出力します。ほとんどの場合はオリジナルに近い"新しい"コードですが、ときどき、学習元のコードと"striking similarity（際立った類似性）"を持つ断片 を吐き出すことがある。この「striking similarity」というのは法律の世界の言葉で、「偶然ここまで似ることはあり得ない＝実質コピーとみなせる」というレベルの類似を指します。
しかもタチが悪いのは、AIの出力からは、元コードの「ライセンス表示」や「著作者名」が消えている こと。この著作権表示・著者名・ライセンス条項といった情報を、専門用語で CMI（Copyright Management Information／著作権管理情報） と呼びます。人が普通にコピペするなら、まだヘッダーコメントに // Copyright ... が残っていて気づけるんですが、AIは中身のロジックだけを再構成するので、CMIがきれいに落ちる。この現象は 「license laundering（ライセンス・ロンダリング）」 ―― ライセンスの洗浄、と呼ばれたりします。地味だけど、けっこう本質を突いた表現だなと思います。
数字で見ると、どのくらいの頻度なのか
「そんなの、めったに起きないでしょ」と思うかもしれません。ここは煽らず、正確に見ておきましょう。
LiCoEval という研究（arXiv:2408.02487）が、14種類のLLMを評価しています。そこでの報告がわかりやすいので引用します。
- 最も優秀なモデルでも、生成コードの 0.88%〜2.01% が、既存のOSS実装と「striking similarity」を持っていた。
- そして、ほとんどのLLMは、その類似コードについて正しいライセンス情報を申告できなかった 。特にコピーレフトなライセンスで顕著だった。
この数字、どう受け止めますか。「たった1〜2%か」とも読めるし、「50〜100回に1回は地雷を踏みうる」とも読める。僕は後者で捉えるべきだと思っています。というのも、これは 典型的な"低確率×高影響"の非対称リスク だから。ほとんどは無害。でも、1回でもコピーレフトのコードを製品に取り込んで、それが表沙汰になれば、影響は「プロダクト全体のソース公開」や「取引先との契約トラブル」まで一気に跳ねる。頻度は低くても、期待値としては無視できないんですよね。
法律の世界でも、まだ答えは出ていない
参考までに、業界の空気感も。GitHub Copilotをめぐっては、OSS開発者らが起こした訴訟（Doe v. GitHub、2022年11月提訴）が続いています。多くの請求は2024年までに退けられましたが、「AIの出力からCMIを剥がすことがDMCA（デジタルミレニアム著作権法）§1202(b)違反にあたるか」 という論点が残り、2026年2月に米連邦第9巡回控訴裁判所で口頭弁論が行われました。この記事を書いている時点では、まだ判決は出ていません （筆者は法律の専門家ではないので、ここでは「係争中で決着していない」という現在地だけをお伝えします。判決の予測はしません）。
大事なのは、判決の行方そのものより、「ライセンス表示や来歴（provenance）を保つことは、それだけ重く見られている論点なんだ」 という感覚を持っておくことです。だからこそ、僕ら実装側は「AIが消してしまう来歴を、自分たちの仕組みで取り戻す」姿勢が要る、というわけです。
用語を、ぜんぶ"借り物"のたとえで整理する
ここで一回、専門用語をやさしく揃えておきましょう。AIコードのライセンス問題は、要は 「借り物かもしれないコードを、黙って自分のものとして使っていないか」 の話です。この比喩で全部つながります。
- ライセンス … コードという貸し出し品についてくる「借用のルール」。返さなくていいけど、使い方に条件がつく。
- permissive（寛容）ライセンス（MIT / Apache-2.0 / BSD など） … 「著作権表示さえ残してくれれば、あとは自由。商用もOK、改変もOK」という、ゆるい貸出条件。基本、味方。
- copyleft（コピーレフト）ライセンス（GPL / AGPL / LGPL など） … 「使ってもいいけど、これを含む"あなたの成果物"も同じ条件で公開してね」という、強い条件つきの貸出。これが混ざると、プロダクト全体に条件が"伝染"しうる のが怖いポイント。「感染」とよく比喩されます。
- CMI（著作権管理情報） … 貸出品に貼られた「持ち主の名札」。著作者名・著作権表示・ライセンス条項など。AIはこれを剥がしがち。
-
SPDX … ライセンスに世界共通の"型番"をつけた識別子。
MIT、GPL-3.0-only、Apache-2.0みたいに機械が読める形で書ける。 - SCA（Software Composition Analysis） … 「あなたのプロダクトに、どこの誰の借り物が、いくつ入っているか」を棚卸しする作業・ツール。
- スニペット照合（snippet scanning） … 借り物リスト（依存パッケージ）だけでなく、"ソースコードの断片そのもの"が既知のOSSと一致していないか を照合する、もう一段深い検査。AIコード対策ではここが効く。
- SBOM（Software Bill of Materials） … 「ソフトウェアの部品表（成分表）」。何が・どのバージョンで・どのライセンスで入っているかの一覧。食品の原材料表示みたいなものです。標準フォーマットに CycloneDX（OWASP由来）や SPDX があります。
この地図さえ頭にあれば、これから出てくるコマンドが「あ、名札を確認してるのね」「成分表を作ってるのね」と読めるようになります。
大前提：どこを人間が決めて、どこをAI・ツールに任せるか
手を動かす前に、役割分担を固定します。ここを最初に決めておかないと、「ツールが緑だから出荷OK」みたいな、判断の丸投げ が起きます。ライセンスは最終的に"事業の判断"なので、機械に決めさせてはいけない領域があるんです。
| 工程 | 誰がやる | 中身 |
|---|---|---|
| どのライセンスを許可/禁止するか（ポリシー策定） | 人間 | MIT/Apacheは許可、GPL/AGPLは要審査、など会社の方針として決める |
| コードの由来・ライセンスの調査（スキャン） | AI・ツール | ScanCodeやSCAで機械的に検出 |
| 依存やスニペットの一致検出 | ツール | 決定的に照合できる部分 |
| コピーレフト混入時に「使う/避ける/書き直す」の判断 | 人間 | 事業リスクとして受容するか決める |
| 部品表（SBOM）の生成 | ツール | CIで自動生成 |
| 最終的な「出荷してよい」の承認 | 人間 | 不可逆な行為の最終ゲート |
覚え方はいつもの通りです。「What（何を許すか）とWhy（なぜ）は人間、How（どう検出するか）はAI・ツール」 。検出は機械が速くて正確。でも「このリスクを背負って出荷するか」は、人間にしか決められません。
4段の検証パイプラインを組む
ここから本題。AIコードのライセンスを"仕組み"で守る、4段のパイプラインを作ります。いきなり全部やろうとすると重いので、上から順に、できるところから で大丈夫です。まず1段目だけでも、今日入ります。
段① 依存パッケージのライセンスを allowlist で縛る（いちばん軽い最初の一歩）
まずは足元から。AIが pip install や npm install を提案してくるたびに、その依存パッケージのライセンスが「うちで許可してるやつか」を機械的にチェックします。これは既存の無料ツールで一発です。
Node.js（license-checker）の例：
# 依存のライセンス一覧を出す
npx license-checker --summary
# 許可リスト以外が混ざっていたら失敗させる（CIで使える）
npx license-checker \
--onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC" \
--excludePrivatePackages \
|| { echo "許可外ライセンスの依存が見つかりました"; exit 1; }
Python（pip-licenses）の例：
pip install pip-licenses
# ライセンス別に一覧化
pip-licenses --format=markdown --order=license
# 禁止ライセンスが含まれていたら落とす
pip-licenses --allow-only="MIT License;Apache Software License;BSD License;ISC License (ISCL)" \
|| { echo "許可外ライセンスの依存が見つかりました"; exit 1; }
ポイントは、「許可リスト（allowlist）方式」にすること 。「これはダメ」を列挙する禁止リストだと、知らないライセンスがすり抜けます。「これだけOK、それ以外は全部止めて人間が見る」のほうが、圧倒的に安全なんです。ここは、以前セキュリティの記事で書いた「default deny（迷ったら止める）」と同じ発想ですね。
段② ソースコードの断片そのものをスキャンする（AIコード対策の本丸）
段①は「宣言された依存」しか見られません。でも、AIが埋め込むコードは 依存パッケージじゃなくて、あなたのソースに直接コピーされた断片 です。ここを捕まえるには、ソースレベルのスキャン が要る。無料で定番なのが ScanCode Toolkit（AboutCodeプロジェクト）です。ライセンス・著作権・コードの由来を、ソースから直接検出してくれます。
# インストール（pipで入ります）
pip install scancode-toolkit
# src/ 配下をスキャンして、ライセンス・著作権・URLを検出し、JSONで出力
scancode \
--license \
--copyright \
--url \
--json-pp scancode-report.json \
src/
# 出力の中身を軽く確認（検出されたライセンス識別子を拾う）
cat scancode-report.json | python -c "
import json, sys
data = json.load(sys.stdin)
found = set()
for f in data.get('files', []):
for d in f.get('license_detections', []):
found.add(d.get('license_expression'))
print('検出ライセンス:', sorted(x for x in found if x))
"
ScanCodeはSPDX形式の識別子で結果を返してくれるので、gpl-3.0 や agpl-3.0 みたいなコピーレフトが検出されたら、そこを人間が精査する、という運用に落とせます。「AIが書いたはずのファイルから、なぜかGPLの痕跡が出た」―― これが見えるだけで、事故率がぐっと下がります。
補足：ScanCodeのようなOSSツールは「ライセンステキストや既知パターンの照合」が主戦場です。もっと踏み込んで "世界中のOSSスニペットのデータベースと断片単位で突き合わせる" ところまでやりたい場合は、Black Duck・FOSSA・FossID といった商用のスニペット照合が強い領域です。まずは無料のScanCodeで土台を作り、規模が大きくなったら商用の段を足す、という順番がいいと思います。
段③ 部品表（SBOM）を自動生成して、成分を可視化する
検出できたら、次は 「うちのプロダクトには、こういう成分が入っています」を一覧化した部品表（SBOM）を残す 。これは監査・納品・脆弱性対応でも効いてくる、いわば"成分表示ラベル"です。OWASPの CycloneDX が軽量で、ライセンス情報もSPDXで持てます。
# 例: Node.js プロジェクトの SBOM を CycloneDX 形式で生成
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# 例: Python プロジェクトの SBOM を生成
pip install cyclonedx-bom
cyclonedx-py environment --output-format json --outfile sbom.cdx.json
生成したSBOMには各コンポーネントの licenses フィールドが入るので、ここを機械的に走査すれば「禁止ライセンスが成分に含まれていないか」を後段のゲートで判定できます。部品表は、未来の自分（や監査担当）への申し送り なんですよね。「このリリース時点で、何が入っていたか」を後から証明できる。これがあると、いざ問い合わせが来たときに、青ざめずに済みます。
段④ CIで「ライセンスゲート」を作り、コピーレフト混入を止める
最後に、①〜③を 人の善意に頼らず、パイプラインで強制 します。GitHub Actions で、プルリクのたびに走らせる例です。ここでの設計思想は、「決定的に真っ黒なもの（既知の禁止ライセンス）はblockで止める。グレー（未知・判定不能）はwarningにして人間に回す」 。全部blockにすると現場が回らなくなるので、濃淡をつけます。
# .github/workflows/license-gate.yml
name: license-gate
on:
pull_request:
jobs:
license-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Install scanners
run: pip install scancode-toolkit
- name: Scan source for licenses
run: |
scancode --license --copyright \
--json-pp scancode-report.json src/
- name: Enforce license policy
run: python scripts/check_license_policy.py scancode-report.json
判定スクリプトはこんな感じ。禁止（コピーレフト）は即失敗、未知ライセンスは警告して人間の目に載せる ようにしています。
# scripts/check_license_policy.py
import json
import sys
# 会社ポリシーとして人間が決める（What/Why は人間の仕事）
ALLOWED = {"mit", "apache-2.0", "bsd-2-clause", "bsd-3-clause", "isc"}
FORBIDDEN = {"gpl-2.0", "gpl-3.0", "agpl-3.0", "lgpl-3.0"} # コピーレフト = 要注意
def main(report_path: str) -> int:
with open(report_path, encoding="utf-8") as f:
report = json.load(f)
forbidden_hits = []
unknown_hits = []
for file in report.get("files", []):
path = file.get("path", "")
for det in file.get("license_detections", []):
expr = (det.get("license_expression") or "").lower()
if not expr:
continue
# 禁止ライセンスの痕跡 = 決定的にブロック
if any(bad in expr for bad in FORBIDDEN):
forbidden_hits.append((path, expr))
# 許可リストにも禁止にも無い = 未知。人間が見る
elif not any(ok in expr for ok in ALLOWED):
unknown_hits.append((path, expr))
for path, expr in unknown_hits:
print(f"::warning file={path}::未知のライセンス '{expr}' を検出。人間の確認が必要です")
if forbidden_hits:
for path, expr in forbidden_hits:
print(f"::error file={path}::禁止ライセンス '{expr}' を検出。出荷前に必ず対処してください")
return 1 # CI を失敗させる = マージをブロック
print("ライセンスチェック: 禁止ライセンスの混入なし")
return 0
if __name__ == "__main__":
sys.exit(main(sys.argv[1]))
これで、「AIが書いたコードにGPLの痕跡が混ざったまま、こっそりマージされる」という事故を、仕組みとして 止められます。人間がうっかりしても、パイプラインは寝てても働いてくれる。ここが"気合い"と"仕組み"の決定的な差なんですよね。
そもそも、入口を絞る（生成の段階でやれること）
出てきたものを検査するだけじゃなく、「そもそも似すぎたコードを出させない／出たら気づける」 入口の工夫もあります。両論、正直に紹介します。
たとえば GitHub Copilotには「Suggestions matching public code（複製検出フィルタ）」 という設定があります。これは、AIの提案コードと周辺の 約150文字（おおよそ65レキシム以上） を、GitHub上の公開コードのインデックスと照合して、一致・近似が見つかったら ブロックする（Blockモード） か、一致した公開リポジトリとそのライセンスを表示する（Allowモード＋code referencing） 機能です。組織単位でBlockに倒しておけば、"あからさまなコピー"はかなり減らせます。
ただし、正直に言っておくべき限界もあります。この手のフィルタは 「ほぼ完全一致」に近いものを捕まえるのが得意 で、少し変形されたコードや、ロジックだけ同じで書き方が違うケースまでは拾いきれません。だから、入口のフィルタ（ベンダー側の緩和策）と、出口のスキャン（自分たちの検査）は、両方あって初めて意味がある 。どちらか一方に寄りかからないのがコツです。
プロンプト例：AIを「来歴の調査係」として働かせる
ライセンスの最終判断は人間の仕事ですが、調査と整理はAIがめちゃくちゃ得意 です。ここでAIに任せるのは"判断"じゃなくて"下ごしらえ"。3本、そのまま使えるプロンプトを置いておきます。
プロンプト1：生成時に「来歴の自己申告」を義務づける
あなたはコードを生成するアシスタントです。以下のタスクのコードを書いてください。
ただし出力の最後に必ず「来歴セルフチェック」を付けてください:
- この実装は、特定の有名OSS実装と際立って似ている可能性があるか（Yes/No/わからない）
- 似ている可能性がある場合、想定される元プロジェクトとライセンス（推測でよいが「推測」と明記）
- コピーレフト（GPL/AGPL系）に由来する可能性の有無
注意: あなたの申告は「主張」であって「保証」ではありません。
最終判断のため、私が別途スキャン（ScanCode等）で必ず裏取りします。
これは魔法ではありません。研究（LiCoEval）でも、多くのモデルは正しいライセンスを申告できない と分かっています。だからこの申告を 信じてはいけない 。あくまで「怪しい所に人間の目線を寄せる、注意喚起の付箋」として使うのが正解です。
プロンプト2：ライセンス互換性のトリアージ
以下は、あるプロジェクトで検出されたライセンスの一覧です:
（scancode-report.json / SBOM から抽出したライセンス識別子を貼る）
このプロジェクトを「商用の閉じたソース（proprietary）」として配布する前提で、
各ライセンスを次の3段階に仕分けし、根拠を1行ずつ添えてください:
1. そのまま配布可（permissive: MIT/Apache 等、表示義務は残る）
2. 要注意・条件つき（copyleft や特殊条項。何が求められるかを明記）
3. 判定不能（情報不足。何が分かれば判定できるかを明記）
最終判断は人間（法務・責任者）が行います。あなたは分類の下書きに徹してください。
不確実なものを「たぶん大丈夫」と丸めないでください。
プロンプト3：コンプライアンス・レポートの初稿づくり
以下のスキャン結果とSBOMをもとに、経営・法務にも読める
「OSSライセンス・コンプライアンス報告」の初稿を作ってください。
- 検出されたライセンスの内訳（permissive / copyleft / 未知の件数）
- 特に注意すべきファイルとその理由（file:line で示す）
- 推奨アクション（書き直し / 代替ライブラリ / 表示追加 / 人間の審査）
- 未確認・情報不足の項目を「未検証」として明示
事実は貼った資料の範囲だけで書き、資料にない断定はしないでください。
3本に共通するのは、AIに「調べさせて・並べさせて・草案を書かせる」けれど、「決めさせない」 という姿勢です。判断の主語は、最後まで人間に置いておく。
安全に運用するための、外してはいけない4つ
仕組みを入れても、運用を間違えると意味がなくなります。ここは独立して回収しておきます。
-
コピーレフト混入は「低確率×高影響」。頻度で油断しない。 GPL/AGPLの断片が1つ入るだけで、最悪はプロダクト全体のソース公開義務に波及しうる。「1〜2%だから」ではなく「当たると重い」で身構える。逆に、permissive（MIT/Apache）は表示義務さえ守れば怖くないので、過剰に恐れて開発が止まるのも避けたい。濃淡をつけて怖がる のが正解です。
-
AIのライセンス申告を、最終判定に使わない。 前述の通り、研究上も多くのモデルは正しいライセンスを申告できません。AIの「これはMITだと思います」は、便利な付箋であって、証拠ではない。必ずScanCode等の決定的なスキャンで裏取り してください。
-
社内コードや秘密を、外部のスキャンSaaSに無断でアップロードしない。 ライセンススキャンをクラウドサービスに投げるとき、それは「自社の非公開ソースを外に出す」行為でもあります。AIやSaaSに渡す＝外に出る 。契約・データ取り扱いを確認し、機密性の高いコードはローカルで完結するツール（ScanCodeはローカル実行できます）を選ぶ。ここは以前から何度も書いている鉄則ですね。
-
不可逆な行為（出荷・納品・OSS公開）は、人間の承認ゲートを必ず通す。 CIのライセンスゲートは"門番"であって"最終決裁者"ではありません。グレーが残ったまま、機械の緑だけで世に出さない。世に出したコードは、取り消せない 。取り消せないことは、人間が最後にうなずいてから。
つまずきポイント early warning
| つまずき | 何が起きる | 対策 |
|---|---|---|
| 禁止リスト方式にする | 知らないライセンスがすり抜ける | 許可リスト（default deny）に倒す |
| 依存スキャンだけで満足 | ソースに直接埋まった断片を見逃す | ScanCode等でソースレベルも見る |
| AIの申告を鵜呑み | 誤ったライセンス判定で出荷 | 決定的スキャンで裏取り |
| 全部をblockにする | 現場が回らずゲートが形骸化 | 真っ黒はblock/グレーはwarningで人間へ |
| SBOMを作らない | 後から成分を証明できない | CIで毎ビルド自動生成 |
撤退ライン（無理をしない線）
- コピーレフトの断片が製品コアに深く食い込んでいる … その場で判断せず、書き直し・代替ライブラリ・法務相談へ切り替える。
- ツールが「判定不能」を大量に返す … スキャン設定や対象範囲を見直す。緑にするために基準を甘くしない。
- 由来がまったく追えないコードが混ざっている … 出荷を止めて、その部分をクリーンルームで書き直す判断も含めて検討する。
おわりに：30秒のスキャンは、明日の自分への「あざっす」
ここまで、AIコードの「使っていいか（ライセンス）」を仕組みで守る話をしてきました。最後に、少しだけ肩の力を抜いて。
僕がこの話を大事だと思うのは、これが 「過去の自分を責めない技術」 だからなんです。
半年後、監査や取引先から「このコード、由来は大丈夫ですか？」と聞かれたとき。SBOMもスキャンログも何もなかったら、当時の自分を責めながら、真っ青な顔で調査に何日も溶かすことになる。でも、今日CIにライセンスゲートを1本入れておけば、そのとき未来の自分は、部品表を一枚出して「はい、確認済みです」と、涼しい顔で答えられる。
これって、「明日の自分が"あざっす"って言ってくれる仕込み」 なんですよね。誰かを責めるためのチェックじゃなくて、未来の自分と、一緒に働く仲間を守るための思いやり。30秒〜数分のスキャンが、そういう装置になってくれる。
そして、こうやって積み上げた「安全に、堂々と出荷できる状態」は、消えない資産になります。動くコードは一瞬で価値を失うこともあるけど、"由来がクリーンで、いつでも証明できる"という信頼 は、あなたのプロダクトの土台として、ずっと積み上がっていく。コードそのものだけじゃなく、それを安心して世に出せる仕組みも含めて、資産（Capital）なんだと思います。
今日の最初の一歩は、たった1つでいい。あなたのリポジトリで license-checker か pip-licenses を1回走らせて、許可リストを書いてみる。 それだけで、第3の軸の入口に立てます。
一緒に、AIと気持ちよく、そして胸を張って作っていきましょう。
生成AI活用エンジニア＆3児のパパ。AI×開発の実践知を毎日発信しています → X: @akira_papa_AI
参考リンク（一次情報・事実照合先）
- LiCoEval: Evaluating LLMs on License Compliance in Code Generation（arXiv:2408.02487） https://arxiv.org/abs/2408.02487 ／ ベンチマーク https://github.com/osslab-pku/LiCoEval
- GitHub Copilot Litigation（Doe v. GitHub）ケース更新 https://githubcopilotlitigation.com/case-updates.html ／ 論点解説 https://www.bakerlaw.com/the-copilot-litigation/
- GitHub Docs: Finding public code that matches GitHub Copilot suggestions（複製検出フィルタ） https://docs.github.com/copilot/using-github-copilot/finding-public-code-that-matches-github-copilot-suggestions
- ScanCode Toolkit（AboutCode） https://github.com/aboutcode-org/scancode-toolkit
- CycloneDX（OWASP SBOM標準／Tool Center） https://cyclonedx.org/
- FOSSA: Snippet scanning explained https://fossa.com/blog/snippet-scanning-explained/
（注記: 本記事のコードは説明用の最小例です。license-checker / pip-licenses / scancode / GitHub Actions の各コマンド・オプションは公式ドキュメントに基づいて記載していますが、実行はお使いの環境・バージョンで確認してください。Pythonの判定スクリプトはロジックの雛形であり、実データでの動作は各自でご確認ください＝動作未確認の雛形として扱ってください。法的判断については、必ず自組織の法務・専門家にご相談ください。筆者は法律の専門家ではありません。）