自分が公開したオープンソースのコードが、誰かに無断でコピペされていたら、あなたはどうしますか？
それも、自分のパッケージ名を直接挙げて「これより優れている」と謳う形で。
Redditのr/Pythonで、まさにそんな事例が投稿されました。
AGPL-3.0ライセンスのコードが、複数の開発者によって流用されたのです。
そして、別パッケージとしてPyPIに再公開されました。
本記事では、この事例の概要を整理してご紹介します。
また、コミュニティから寄せられたアドバイスもまとめます。
事例の概要
ある開発者が、コードベース分析ツール「repowise」をPyPIで公開しました。
コードのwiki生成、git履歴からのホットスポット抽出、所有者情報の分析などを行うツールです。
ライセンスはAGPL-3.0で配布されました。
公開後しばらくして、PyPI上に妙な現象が起こります。
数時間以内に、3つの新しいパッケージが連続して現れたのです。
しかも、それぞれの説明文には共通する文言が含まれていました。
「先読みするコードベース解析、あらゆる面でrepowiseを凌駕する」といった内容です。
つまり、オリジナルのパッケージ名を直接挙げて、それを上回ると謳っていたわけですね。
中身を確認すると、もっと深刻な事実が明らかになります。
3つともAGPL-3.0のコードをforkしていました。
そして、LLMで軽く手直しした上で、別名義で再公開していたのです。
LICENSEファイルなし。
著作権表示なし。
元リポジトリへのリンクもなし。
完全に丸裸の状態でした。
開発者が試みた対応
被害者となった開発者は、いくつかの手段を講じます。
まず、PyPIの悪用報告フォームから通報を行いました。
次に、ライセンス違反としてDMCA申請も提出。
さらに法務担当者にもメールを送ります。
ところが、数週間経っても3つのパッケージは生きたままでした。
オリジナルプロジェクトの名前を借りて、淡々とダウンロード数を稼ぎ続けている状態だったのです。
PyPIの悪用対応プロセスは、フォーム一枚と沈黙のみ。
そんな状況だったようです。
レジストリ自体には、コピーレフトライセンスを強制する仕組みが組み込まれていません。
そのため、AGPL違反への対処はDMCAに依存することになります。
しかし、DMCAは時間がかかる上に、無視されやすいという現実があります。
コミュニティから寄せられたアドバイス
この投稿には、有用なアドバイスが多数寄せられました。
順番にご紹介します。
正式なDMCA手続きを踏む
「これは私のIPを侵害している」と非公式に主張するだけでは、PyPIは対応してくれない場合があります。
なぜなら、法的にそれが本当かどうかは、裁判所しか判断できないからです。
PyPI側からすれば、申立者が嘘をついている可能性も否定できません。
そこで、正式なDMCA通知の形式で再提出することが推奨されました。
費用はかかりません。
Georgetown大学図書館などが公開しているテンプレートを使います。
そして、legal@python.org宛にメールを送る方法です。
ただし、注意点があります。
DMCA通知には、申立者の物理的な住所を記載する必要があります。
そして、その情報は相手方にも開示されます。
これは米国法の要求であり、回避できません。
正式な通知を受けたPSF（Python Software Foundation）の法務チームは、相手方に通知を転送します。
相手方は数日以内に、異議を申し立てるかどうかを決める必要があります。
異議が出なければ、パッケージは速やかに削除されます。
一方、異議が出た場合は、申立者が訴訟を起こすかどうかの判断を求められる流れになります。
CDN業者やホスティング先にも通知を送る
PyPIだけでなく、PyPIが利用しているCDN業者にもDMCA通知を送る。
そんな戦略も提案されました。
具体的には、Fastlyのような業者です。
CDN業者は通常、通知をPyPIに転送します。
しかし、通知のタイマーが動き始めるという効果があります。
著作権侵害に加担している状況を放置すれば、CDN業者自身も責任を負うリスクが生じます。
そのため、最終的にはサービス提供の見直しを迫られる状況に追い込めるという理屈ですね。
Software Freedom Conservancyに相談する
訴訟を本気で検討する場合、SFC（sfconservancy.org）への相談という選択肢があります。
彼らはDMCA以降の戦術に詳しいです。
そして、フリーソフトウェアのライセンス違反問題に専門性を持っています。
実際の訴訟まで進まなくとも、法的レターヘッドの入った警告文が大きな威力を発揮することもあるそうです。
LinkedInから直接コンタクトを試みる
意外と見落とされがちな手段があります。
コピペした側のGitHubプロフィールから、LinkedInなどの連絡先が判明するケースです。
訴訟や法的手続きに進む前に、まず本人に直接お願いしてみる手があります。
「パッケージを取り下げてほしい」と。
多くの場合、悪意ではなく無知から起こっているケースも考えられます。
LICENSEファイルと帰属表示のリンクを追加すれば、AGPL違反は解消されます。
たった2分の作業で済む話なんですよね。
PRを送るというトリッキーな作戦
もう一つ、面白いアイデアが寄せられました。
各リポジトリにLICENSE.txtを追加するPRを送るというものです。
相手の開発者がGitHub CopilotなどのAIコーディングアシスタントを使っていれば、PRのコメントにマージ推奨のサジェストが表示されるかもしれません。
皮肉な話です。
しかし、有効に機能する可能性があります。
全ての証拠を文書化する
何をするにしても、すべてのやり取りを文書化しておくことが重要です。
文書化すべきものは、以下のとおりです。
- メールのコピー
- DMCA申請の控え
- LinkedInのスクリーンショット
- 自分のコードと相手のリポジトリの差分
こうした証拠の積み重ねが、後の交渉や法的手続きで力を発揮します。
なぜAGPL違反がこの事例で強い意味を持つのか
今回の事例には、AGPL違反を主張する上で特に有利なポイントがあります。
それは、コピペした側がパッケージの説明文で、オリジナルのパッケージ名を直接挙げている点です。
「repowiseを凌駕する」と書いているわけですから、オリジナルの存在を認識した上で派生物を作ったことになります。
つまり、意図性を否定するのが極めて難しい状況なのです。
通常のライセンス違反であれば、「知らなかった」「偶然似ただけだ」という言い逃れが可能なケースもあります。
しかし、今回はそれが通用しません。
コミュニティの法務に詳しいユーザーも、この点が攻めやすいポイントだと指摘していました。
LLM時代の新しい論点
コメント欄では、興味深い問題提起もありました。
「LLMが生成したコードに著作権は発生するのか」という論点です。
AGPLの条文には、こんな記述があります。
「The Programは、本ライセンスの下でライセンスされた著作権を有する著作物を指す」。
ここで「著作権を有する」という部分が問題になるわけですね。
LLMが生成した部分のコードに、著作権が認められない可能性があるからです。
もし生成AIが全てのコードに関与していれば、コードベース全体が著作権で保護されないという主張も成り立ちます。
理論上の話ですが。
ただし、これに対する反論もあります。
人間がAIを「道具として」使うケースです。
選別、編集、構成に実質的な創造的貢献を行えば、著作権は依然として有効と考えられます。
実際に、Anthropic社がClaude CodeのソースコードについてDMCA通知を送っている事例もあります。
この論点は、法的にまだ確定していません。
判例の積み重ねを待つ段階だと言えるでしょう。
なぜ3つも同じパッケージを作るのか
「なぜ同一の海賊版パッケージを3つも作るのか」。
この疑問もコメントで上がりました。
考えられる動機の一つは、検索結果での競争相手の埋没化です。
類似名のパッケージで検索結果を埋め尽くす。
そうすることで、オリジナルへの誘導を阻害する戦術と考えられます。
もう一つの動機は、履歴書の見栄えです。
GitHub上の他人のプロジェクトをforkして、コミット履歴を削除する。
そして、自分が長期間関わってきたかのように見せかける。
こうした手法は、面接の場でも観察されているそうです。
PyPI側の事情も理解する必要がある
ここで一つ、考慮すべき視点もあります。
PyPIは慢性的にリソース不足の状態にある、というコメントです。
元々潤沢な資金があったわけではありません。
そして、LLM時代になって作業量が爆発的に増加しているのが現状とのこと。
abuseフローへの対応の遅さは、彼らの怠慢ではないかもしれません。
むしろ、構造的な問題から生まれている可能性があります。
怒りをぶつける前に、その背景を理解する余地もあるかもしれません。
まとめ
PyPIにおけるAGPL違反は、対処が容易ではないという現実があります。
法的手段は時間とコストを要します。
そして、個人開発者にとっては大きな負担になります。
それでも、有効な手段はいくつか存在します。
- 正式なDMCA通知の提出
- CDN業者やホスティング先への通知
- SFCへの相談
- 相手方への直接コンタクト
- すべての記録を文書化すること
これらを組み合わせて圧力をかけていくのが、現実的な道筋と言えるでしょう。
オープンソースのコピーレフトライセンスは、根本的な課題を抱えています。
それは、強制執行のメカニズムが弱いという問題です。
法律的にはライセンス違反であっても、それを是正させるには相応の労力と覚悟が必要になります。
LLMの登場により、コードのコピーと改変は格段に容易になりました。
そのため、著作権侵害のスケールも拡大しています。
一方で、コードの著作権そのものをめぐる法的解釈にも、新しい論点が生まれつつあります。
OSS開発者として何ができるか。
そして、どこまで戦うべきか。
そんなことを考えさせられる事例でした。
似たような被害に遭った場合の参考にしていただければと思います。
