GitHubがPhotopeaの削除要請を却下した理由
著者によると、誰かがAIで彼のJavaScriptを抜き取り、広告を除去して再公開したが、GitHubは1か月後に「17 U.S. Code § 1201違反を確認できない」と回答した。私は彼の過去2回の通知全文とGitHubのポリシーを読み、関連する41リポジトリのtarballを1つずつ開いて数えた。
日本語
コピー
2026年9月4日、Photopeaの作者Ivan KutskirはGitHubに削除要請を提出した。1か月後、彼が受け取ったのはこの一文だった。
DMCA削除要請をご提出いただきありがとうございます。ご提供いただいた情報を確認しましたが、提示された事実に基づくと、17 U.S. Code § 1201 の違反を確認することはできません。
10月6日、彼はこの件をHacker Newsに投稿した。タイトルは「GitHubが私のソフトのクラック版の削除を拒否、すでに1か月経過」。10月12日までにこの投稿は572ポイント、343コメントを集め、コメント欄で最も多く見られた反応は「提出した通知の種類が間違っている」だった。
私はこの件の資料を一通り調べた。GitHub自身が公開しているDMCAポリシー、github/dmcaという公開リポジトリにあるPhotopeaの過去2回の通知全文、そしてGitHub上のオフライン版Photopeaリポジトリが実際に何を入れているか。あの頻出の指摘はおおむね正しいが、半分しか説明していない。残りの半分はPhotopeaのようなソフトの構造の中にある。
120スターのElectronの殻で、
<webview>はphotopea.comを直接指している。今も残っている。対象はNFXT/Photopea-Desktop-App、理由は「誰かが私のソフトをクラックし、誰でもPremium機能を無料で使えるようにした」。通知には3つのforkも挙げられていた。
対象はspooknik/Photopea-Appimage。GitHubの注記は2022年のものと一字一句同じ。
今もGitHubに出回っているそのコピーは、ファイル名のタイムスタンプがこの日のもので、3つのファイルのsha256が2つのリポジトリで完全に一致する。
作者が削除要請を提出し、GitHub Trust & Safetyがその日のうちに受領確認、その後1か月の沈黙。
「§1201違反を確認できない」という返信を受け取り、同じ日にTell HNを投稿。
GitHubは再提出を求めてきて、彼は新しいチケット番号が4833281だと述べ、弁護士を探し始めた。
GitHubには2つの手続きがあり、強度が大きく違う
GitHubのDMCAポリシーは著作権通知と反回避の主張を別々に扱い、両者の審査方法はまったく異なる。
標準的な著作権通知はポリシーのA節に沿う。ポリシーはこの手続きについて、GitHubは「ほとんど裁量を行使せず、通知がDMCAの最低要件を満たすかどうかだけを判断する」と説明している。通知がリポジトリ全体の侵害を主張する場合、GitHubはリポジトリ全体を即座に削除する。一部のファイルにしか関わらない場合、GitHubはリポジトリの作者に連絡し、約1営業日の修正期間を与え、修正されなければ削除する。
反回避の主張はC節に沿う。法的根拠は17 U.S.C. § 1201、つまりDMCAで技術的措置の回避を禁じている条項だ。GitHubはこれについて提出者に3点を明確に書くよう求めている。技術的措置とは何か、それが著作権保護された素材へのアクセスをいかに効果的に制御しているか、被疑プロジェクトがそれをいかに回避しているか。そのうえで技術担当者と法務担当者が共同でより広範な審査を行う。ポリシーには決定的な一文もある。
主張が有効かどうかを判断できない場合、私たちは開発者に有利な側に倒し、コンテンツを残します。
作者が受け取った返信が§1201を名指ししていることから、通ったのは2つ目の手続きだとわかる。1か月の待機と「確認できない」という文言は、このポリシーの記述と符合する。
GitHubは彼のものを削除したことがある。2回ある
github/dmcaはGitHubが受け取ったすべての通知を公開保管しているリポジトリで、22400以上のファイルが年月順に並んでいる。中にPhotopeaの通知が2件ある。
1件は2022年3月22日、対象はNFXT/Photopea-Desktop-App、作者が書いた理由は「誰かが私のソフトをクラックし、クラック版をここに公開して、誰でも私のソフトの高度な機能を無料で使えるようにした。相手に連絡が取れない」。もう1件は2024年7月15日、対象はspooknik/Photopea-Appimage。
この2件の通知の注記は一字一句同じ。
GitHubは有効な反回避の主張を判断するのに十分な情報を見つけられなかったが、この削除要請には他の有効な著作権主張が含まれていると判断した。
反回避の部分は認められず、著作権の部分が成立し、コンテンツは処理された。今これらのリポジトリを見ると、NFXT/Photopea-Desktop-Appは404を返し、spooknik/Photopea-Appimageは451、つまりGitHubの「法的理由により利用不可」ページを返す。2022年の通知には3つのfork、DUOLabs333/photopea、tim0-12432/photopea、zhtengw/photopea-cloneも挙げられていたが、今は2つが451、1つが404だ。
今回の問題は「GitHub が動かない」ことではなく、この一本の経路にある。作者は 2022 年にも同じ道を通っていて、当時の GitHub の結論は今回届いたものとまったく同じだった。
「難読化は技術的措置に当たるか」
2022 年の通知のフォームには「あなたが著作権で保護された内容に技術的措置を講じたと主張しますか」という欄があり、彼は「はい」と答え、説明は一文だけだった。
私のコードは難読化していたが、相手はその難読化されたコードを改変した。
4年たっても、この論法は受け入れられていない。なぜ通らないのかを見るには、法文における技術的措置の定義に戻る必要がある。§ 1201(a)(3)(B) によれば、ある技術的措置が「アクセスを有効に制御する」と認められるには、通常の動作において作品に接触するために「情報、プロセス、または処理を適用する」ことを要求することが前提になる。ところが Photopea の 5 MB の JavaScript は、リクエストしてきたブラウザにページと一緒にそのまま送られる。情報もプロセスも要らない。圧縮と難読化はこの作品の形態であって、それを遮る扉ではない。
HN ではこれに異を唱える人もいた。ユーザー eli は § 1201(a)(3)(A) の動詞の並び、「avoid, bypass, remove, deactivate, or impair」を引き、難読化された JS はこの記述に当てはまると主張する。この動詞列はたしかに広い。だがそれは回避の手段を述べたもので、主語はあくまで前に置かれた「アクセスを有効に制御する」措置のほうだ。措置そのものがアクセスを制御していないなら、何行消しても回避にはならない。
並べて見る価値のあることがある。2022 年と 2024 年の通知で、作者はどちらも相手が Premium をアンロックしたと書いている。これは有料チェックの回避に当たる。GitHub のポリシーには、製品のライセンスチェックを回避するソフトウェアという区分が独立して設けられており、そうした主張は技術審査と法務審査の二重審査を経ないと明記されている。それが 2026 年になると、HN で彼が語る中心は「広告を消すこと」に変わっている。広告コードの削除と有料チェックの回避は別物で、前者は § 1201 からさらに遠い。
私は弁護士ではないし、ここまでの数段落は公開テキストの読み方にすぎない。確かな事実は二つだけだ。GitHub は 2022 年、2024 年、2026 年のいずれもこの論法を認めなかった。そしてポリシーには、判断がつかない場合はコンテンツをオンラインに残すと明記されている。
リポジトリを数えてみた
作者はこうしたリポジトリが「数十個ある」と言う。GitHub の検索 API で四つのクエリ（photopea、photopea in:name、photopea offline、photopea desktop）を実行し、重複を除くと 338 個のリポジトリが得られた。このうち名前、説明、topic のいずれかで offline、desktop、広告なし、クラックを名乗っているものが 41 個あった。
その 41 個の tarball を一つずつ落として、中身を確かめた。結果はこうなった。
| 実際の中身 | 数 |
|---|---|
| Photopea のビルド成果物が入っている（300 KB 超の圧縮 JS あり） | 4 |
| Electron または WebView のシェルで、コード内で photopea.com を指している | 17 |
| README だけの空殻 | 9 |
| その他の小規模プロジェクトで、ビルド成果物なし | 6 |
| ダウンロード失敗（切断、または gzip でない） | 3 |
| ページがブラウザをそのまま第三者ダウンロードサイトへ飛ばす | 1 |
| exe のみを配布し、ソースコードなし | 1 |
ビルド成果物を実際に同梱している4つのうち、2つには完全に同一のファイルが入っている。pp1753360222.js、DBS1751979998.js、ext1753387088.jsの3ファイルは、sha256が2つのリポジトリ間で1対1に対応して一致する。この2つのリポジトリは、片方が2026年9月2日、もう片方が2026年10月6日、つまり作者が投稿した当日に作成されている。
Photopeaはビルド時刻をファイル名に書き込むので、このコピーの年齢はそこから直接読み取れる。1753360222を換算すると2025年7月24日になる。サイト上の現行版はpp1791725206.js、2,643,122バイトで、2026年10月11日の夜にビルドされた。コピーはそれより15か月古い。
作者が言う「バイト単位で同一のJS」もコピーから確認できる。pp1753360222.jsの中でphotopeaという文字列が93回、photopea.comが52回出現するのを数えた。ブランドとドメインはそのまま残っていて、変わっているのはリポジトリのタイトルだけだ。
一つだけうまくいかなかったことがある。コピーと現在のオンラインビルドをそれぞれ1 KBのブロックに切って積集合を求め、一致率をパーセントで示そうとした。結果は0だった。Photopeaはビルドのたびに全体を再圧縮するので、15か月離れた2つのビルドの間に共通するバイト列は1ブロックもない。この方法は同じビルドに対してしか使えず、サイトは現行版しか配信しないため、2025年7月24日版は手に入らなかった。コピーのどの行が変更されたのかは検証しておらず、確認できたのは同一のファイル群、同一の命名、同一の作者のブランド表記だということだけだ。
GitHubで削除できない残り3類型
第一はラッパーで、41個のうち17個を占める最大の類型だ。2017年のスター120個のものは<webview>をライブサイトに向けているだけで、広告はそのまま読み込まれる。2025年のものはPlaywrightでサイトをローカルにキャッシュしてオフライン動作させ、キャッシュ時にphotopea.comとgstaticの2ドメインだけを許可する。つまり広告ブロッカーを内蔵しているのと同じだ。この種のプロジェクトは彼のコードを複製しておらず、広告を遮断すること自体は合法で、ブラウザ拡張は毎日同じことをしている。
第二は再実装。今回の引き金は別のプロジェクトで、オフラインコピーとは別物だ。André Kleinは10月4日に「Vibecoding Photoshop」を書き、AI時代に現れた4つのPhotoshopクローンを概観した。その一つがPhotoSuiteだ。10月6日、「Photopea作者がPhotoSuiteについて言及」がHNに上がり、191ポイント。作者がコメントで示した根拠は確率推論で、PSD形式を完全にサポートできるエディタはPhotopeaとPhotoshopしかなく、匿名の作者が突然完全なPSDサポートを実装したのなら、このどちらかからコピーした可能性が高い、というものだ。
そのリポジトリのファイルツリー全体を見た。1521ファイル、153 MB、うち762がRustのソースファイルで、JS、WASM、HTMLを合わせて4つ、最大のものは21 KBのWebスクリプトだ。リポジトリにPhotopeaのビルド成果物は一切ない。機能が同じでも著作権侵害にはならず、コードが同じならなる。この2つは公開資料の中では別物だ。作者自身もHNで両者を分けており、GitHubに申し立てたのは「バイト単位で同一」のオフラインコピーだった。
第三は名前。GitHubのDMCAポリシーには、この手続きは著作権のみを扱い、商標には別の窓口があると明記されている。HNでは商標登録を勧める声があり、それにすぐ「商標はコードを保護せず、保護するのは標識とブランドだけだ。そしてブランドは簡単に消せる」と返す人がいた。どちらも正しい。商標で解決できるのは、ユーザーが他人の改変版を持ち込んで彼にバグ報告してくるという困りごとであって、コードが複製されることではない。
クライアントソフトウェアの構造的な弱点
Photopeaは純粋なクライアントソフトウェアだ。それが「ファイルがあなたのデバイスから出ない」を実現できる理由であり、一人で14年間メンテナンスできている理由でもある。代償は、訪問者一人ひとりのブラウザに完全なプログラムが入っていることだ。広告コードとプログラムは同じパッケージに入っており、広告を消す難易度は数行のコードを消すのと同じになる。
HNではこの論点が激しく紛糾した。一方の派は、ビジネスロジックをクライアントに置くならこの日が来ることは予想できたはずだと言う。ユーザーfg137の主張は、クローズドソースで純粋なクライアント、しかもJavaScriptが難読化されたアプリに、今日本当の著作権保護は存在しない、というものだ。もう一方の派はそうあるべきではないと言う。IP弁護士のDannyBeeの返答は、選択肢は2つしかない、この分野を専門にする法律事務所に金を払ってモグラ叩きをするか、どうせ防ぎきれないのだから通常の消耗として受け入れるか、というものだった。
私自身の判断では、この件でAIによって変わった部分は思っていたより狭い。GitHubに出回っているコピーは、実のところ2025年7月のスナップショットだ。2つのリポジトリが同じファイル群を互いに受け渡している。このスナップショットが現れた時点では、圧縮されたJSを読めるモデルはまだ普及していなかった。作者はHNで、今は「AIにコードを剥がさせ、広告を除去させる」者がいると述べている。この説明は他の場所では正確かもしれないが、私が数えた41のリポジトリでは、証拠が示すのは複製と受け渡しであり、どれもAIがその場で加工したわけではない。彼が感じている圧力は本物だが、圧力の形は投稿に書かれたものとは少しずれている。
構造的な緩和策はある。コアロジックをサーバー側に移す、WebAssemblyでバイナリにコンパイルする、ライセンス検証を加える。どれも参入障壁を高められる。代償も彼は分かっている。Photopeaは今、アカウントなしで使え、ファイルはアップロードされない。これをやればその一部を犠牲にすることになる。
現在の状態
彼は新しいチケット番号 4833281 に切り替え、弁護士を探すつもりだと公言している。いくつかのリポジトリのオンライン状態を確認したところ、ビルド成果物を含む 4 つのリポジトリは 10 月 12 日時点でいずれもまだ公開されていた。同じスナップショットを含む 2 つは、それぞれ 9 月 2 日と 10 月 6 日に作成されている。削除された 5 つは、すべて 2022 年と 2024 年の 2 回の通知によるものだ。
確認できなかった資料が 2 つあるので、ここに記しておく。彼が 9 月 4 日に提出した通知の本文は公開されていない。github/dmca には 2026 年の Photopea の記録がなく、手元にあるのは GitHub の返信の断片と、彼自身が述べた通知内容の要約だけだ。PhotoSuite の issue はリポジトリの作者によって削除され、API は 410 を返す。
2022 年、彼は正しい窓口を通り、結果も得た。今回は 2022 年より手元の材料が揃っている。コピーのブランド表記、ドメイン、ファイル名、ビルドのタイムスタンプが残っており、2 つのリポジトリに同じファイルが含まれていることも確認できる。あとは提出した資料に、どのファイルが権利を侵害しているのかが明確に書かれているか、fork も一緒に挙げられているかどうかだ。GitHub のポリシーはこの 2 点について非常に明快に書いている。