線上修圖工具 Photopea 的開發者在 Hacker News 指出，大量使用者要求 AI 模型複製其網站程式碼、移除廣告後重新發佈成「新產品」，一個月內已出現數十個這類專案。他於 9 月 4 日向 GitHub 提出下架請求，一個月後收到的回覆是：無法確認構成 17 U.S. Code § 1201 的違反。這則貼文累積 569 分與 343 則討論，本文整理事件經過、平台回覆的法律依據，以及獨立開發者可行的應對做法。

這起程式碼被抄事件是怎麼發生的？

Photopea 開發者指出，大量使用者要求 AI 複製其網站程式碼、移除廣告後重新發佈，一個月內出現數十個專案，向 GitHub 申訴後仍未下架。

Photopea 是一款直接在瀏覽器運行的熱門修圖工具，由獨立開發者長期維護。他在貼文中說明，許多使用者要求 AI 模型抓取其網站的 JavaScript 程式碼，移除內建的廣告之後，包裝成「新產品」發佈到 GitHub 供人下載，短短一個月內已累積數十個這類專案。

更麻煩的是名譽與售後的混淆。他提到，曾收到使用者來信抱怨 Photopea 的某些問題，往來數封郵件後才發現，對方用的根本不是 Photopea 官方網站，而是那些被改造過的版本。這類情況讓原作者的商譽受到牽連，也難以對外說明。他在 9 月 4 日正式向 GitHub 提出下架請求，並附上相關連結作為依據。

為什麼向平台申訴會被打回？

GitHub 回覆稱，經審視後無法確認構成 17 U.S. Code § 1201 的違反。該條文針對規避技術保護措施，與單純的著作權複製並不相同，因此申訴方向可能不符。

一個月後，開發者收到 GitHub 的回覆，內容是經過審視後，無法確認這些專案構成 17 U.S. Code § 1201 的違反。這條美國法規處理的是「規避技術保護措施」，也就是破解防拷機制一類的行為，與單純複製受著作權保護的程式碼，在法理上屬於不同的問題。

討論區中有熟悉流程的網友分析，開發者這次的申訴，很可能被平台解讀為 § 1201 的請求，因此回覆本身在法律上未必有錯，只是處理的條文不對。換句話說，問題也許不在於「有沒有侵權」，而在於申訴時援引的法條與平台審查的框架對不上。這種落差，往往令不熟悉法規的獨立開發者在第一關就卡住。

AI 讓程式碼複製變容易，問題出在哪？

生成式 AI 讓複製前端程式碼的成本趨近於零，使用者只要一句指令就能取得近似成品，再移除廣告、重新打包上架，令原作者的付費模式與商譽同時受損。

這起事件之所以引起廣泛討論，在於它觸及一個結構性的轉變。過去要仿製一套網頁應用，得先弄懂別人的程式碼、逐段搬移，門檻不低；如今生成式 AI 能在幾句指令之內產出功能相近的版本，複製的成本被壓到趨近於零，於是「順手抄一份」變成一件毫不費力的事。

當複製幾乎沒有成本，開源與盜版的界線就變得模糊。有人主張，前端程式碼一旦送到使用者瀏覽器，本來就難以完全保護；也有人認為，移除廣告、重新打包並對外發佈，明顯超出了合理使用的範圍。討論中最務實的建議，是呼籲開發者在產品中加入辨識機制，例如偵測程式是否在自己網域之外執行，藉此增加盜用的技術門檻，即使無法完全阻擋，也能讓多數人放棄繞路。

開發者可以怎麼自保與維權？

開發者可為程式碼加上授權聲明與使用條款，保留完整的發布與時間紀錄作為證據，必要時循正式法律途徑處理，並在產品中加入辨識機制提高盜用門檻。

面對這種情況，可行做法分成事前與事後兩部分。事前方面，在程式碼與網站上清楚標示授權條款與使用限制，保存每一次正式發佈的版本與時間紀錄，日後若要主張權利，這些都是基本證據。產品層面則可加入輕量的辨識機制，讓程式在非官方網域運行時出現限制或提示，提高搬移的成本。

事後方面，若平台申訴未果，可考慮諮詢熟悉智慧財產的律師，把申訴方向調整到正確的法條框架，而非單靠平台的自動化審查。討論區中也有開發者提醒，這類爭議往往同時牽涉 AI 訓練資料、平台責任與個人開發者生計，很難靠單一申訴解決，因此把防護做在前面，通常比事後追討更實際。

出處連結有哪些？

本文資訊整理自 Hacker News 的貼文與討論，以及 GitHub 對申訴的公開回覆內容。事件時序與各方說法可於下列來源查閱。

完整的貼文內容與討論，可於下列來源查閱：

常見問題有哪些？

以下整理四個常見疑問，涵蓋申訴被拒的原因、AI 生成程式碼的版權歸屬、開發者可行的維權途徑，以及如何降低被抄襲的風險。

為什麼向 GitHub 申訴會被拒絕？

依回覆內容，平台認為這些專案未違反 17 U.S. Code § 1201。該條文處理的是規避技術保護措施，與直接複製著作權內容屬於不同問題，申訴時援引的法條若不符，就容易被駁回。

用 AI 生成的程式碼，版權算誰的？

這是目前仍無定論的爭點。多數司法管轄區傾向認為，單純由 AI 生成、缺乏人類實質創作投入的內容，難以取得著作權保護；但若涉及複製他人既有程式碼，則可能構成侵權，須個案判斷。

獨立開發者可以採取哪些維權途徑？

先循平台機制申訴並準備完整證據，若未獲處理，可諮詢智慧財產律師，評估改以著作權侵權等其他法條主張，或透過正式法律程序處理。

如何降低程式碼被抄走的風險？

在程式碼與網站標示授權條款、保留發布紀錄、為產品加入網域辨識或授權驗證機制，都能提高複製與再利用的門檻，雖無法完全防堵，但可減少大規模盜用。

總結：這件事對獨立開發者意味什麼？

這起事件反映，當複製成本趨近於零，平台與開發者對合理使用的界線仍無共識。獨立開發者除了強化授權與技術防護，也需要理解現行法規，才不會在申訴時走錯方向。

這起事件的意義，不只是某一套工具被抄，而是它揭示了當複製成本趨近於零時，平台與開發者對「合理使用」的界線仍缺乏共識。開發者以為自己在主張著作權，平台卻以另一條法規來審查，兩邊用不同的語言對話，申訴自然容易落空。

對獨立開發者而言，務實的態度是把防護做在前面：清楚標示授權、保留發布紀錄、在產品中加入辨識與授權機制，並事先了解相關法規的適用範圍。這些做法無法讓抄襲消失，但能在爭議發生時，讓自己站得住腳，也少走一段冤枉路。