GitHub 專案被 DMCA 下架？開發者申訴教學
GitHub 專案被 DMCA 下架？開發者申訴完整教學
摘要
你的開源專案在沒有任何預警的情況下被 GitHub 下架，瀏覽頁面只顯示「Repository unavailable due to DMCA takedown」。這種情況對開發者而言幾乎等同於專案被瞬間「斬首」——所有協作者無法推送程式碼、Issue 追蹤中斷、依賴此專案的下游使用者全部受到波及。然而，DMCA 下架並非終局。美國《數位千禧年著作權法案》在設計通知與下架機制時，同步建立了一套「抗辯通知」（counter notice）制度，讓被指控侵權的一方有機會反擊。2025 年 GitHub 處理了 2,661 件下架請求，影響多達 47,228 個儲存庫，但與此同時，GitHub 也在持續完善開發者保護機制。本文將從法律框架、實務流程、常見錯誤、替代策略到實際案例，為開發者提供一套可操作的申訴指南。找 DMCA 律師前要先準備哪些資料
第一章：DMCA 的法律框架與 GitHub 的處理邏輯
DMCA 安全港與通知下架機制
理解申訴流程之前，需要先理解 DMCA 的核心設計。美國國會制定 DMCA 的目的是解決一個根本矛盾：如果服務提供商必須為使用者上傳的每一段內容承擔著作權侵權責任，那麼像 GitHub、YouTube 這類依賴使用者生成內容的平台將無法生存。DMCA 第 512 條為符合條件的服務提供商建立了「安全港」（safe harbor），只要平台遵守通知與下架規則，就不會因為託管涉嫌侵權的使用者內容而承擔責任。
這套規則的核心邏輯是：
- 著作權人發送下架通知，聲稱其作品被侵權使用
- 平台收到通知後迅速移除或停用被指控的內容
- 使用者若認為下架有誤，可提交抗辯通知要求恢復
- 平台在收到合格抗辯通知後，等待 10-14 天，若著作權人未提起訴訟，則恢復內容
GitHub 的合規義務與開發者權益
GitHub 作為全球最大的程式碼託管平台，對 DMCA 的合規處理極度謹慎。一旦收到符合形式要件的下架通知，GitHub 會立即停用被指控的儲存庫。這不是因為 GitHub 認定內容確實侵權，而是因為安全港保護要求平台「迅速」回應通知。
值得留意的是，GitHub 並非被動地執行所有通知。該平台對涉及第 1201 條反規避條款的請求有額外的審查機制，會由技術專家和法律專家共同評估，若無法確定請求的有效性，會選擇站在開發者一方，保留內容。此外，GitHub 設立了 100 萬美元的「開發者防禦基金」（Developer Defense Fund），並與史丹佛大學法學院合作設立開發者權利研究員計畫，為面臨 DMCA 爭議的開發者提供獨立法律支援。
兩種不同類型的 DMCA 下架通知
開發者需要區分兩種性質不同的下架通知：
一般著作權下架通知：著作權人聲稱其受著作權保護的作品被未經授權複製或散布。這是最常見的類型，例如使用了他人的程式碼而未遵守授權條款。
反規避下架通知：基於 DMCA 第 1201 條，聲稱某項軟體或工具用於規避控制存取受著作權保護作品的技術措施。這類通知在近年大幅增加，2025 年 GitHub 收到了 645 件反規避請求，較前一年增長 41%。任天堂曾在 2025 年 3 月針對 Switch 模擬器相關的儲存庫發送反規避通知，導致超過 4,300 個儲存庫被一併清除。
第二章：被下架後的完整申訴流程
第一步：確認下架類型與收到通知
當儲存庫被 DMCA 下架時，GitHub 會向儲存庫所有者發送一封電子郵件通知，說明下架的原因、被指控的內容以及提交抗辯通知的方式。這封郵件是你後續所有行動的關鍵依據，務必妥善保存。
如果你從未收到這封郵件，可能是因為：
- 你的電子郵件地址未在 GitHub 帳戶中正確設定
- 郵件被歸類為垃圾郵件
- 你是被波及的 Fork 網路成員，而非原始儲存庫所有者
在後兩種情況下，你需要主動聯繫 GitHub 支援團隊（dmca@github.com）確認你的儲存庫狀態。
第二步：評估申訴的可行性
在提交抗辯通知之前，必須進行一次誠實的自我評估。以下情形適合提交抗辯通知：
以下情形則不建議貿然申訴：
- 你確實複製了他人受著作權保護的程式碼
- 你違反了原專案的開源授權條款（例如移除版權聲明、未遵守 GPL 的傳染性要求）
- 你無法明確指出下架通知中的具體錯誤
第三步：撰寫合格的抗辯通知
抗辯通知是一份具有法律效力的聲明，其格式和內容必須符合 DMCA 第 512(g) 條的法定要求。一份合格的抗辯通知必須包含以下要素：
| 法定要素 | 具體要求 |
|---|---|
| 聯絡資訊 | 完整的實體地址、電話號碼和電子郵件地址 |
| 內容識別 | 被停用內容的 URL 及其在被停用前出現的位置 |
| 善意聲明 | 在偽證罪處罰下聲明，你善意相信內容因錯誤或誤識別而被移除 |
| 管轄權同意 | 同意接受原投訴方的法律送達，並接受所在聯邦地方法院管轄 |
| 簽名 | 你的完整法定姓名作為電子簽名 |
以下是抗辯通知的核心聲明範本（必須包含的法定文字）：
「我已閱讀並理解 GitHub 的《提交 DMCA 反通知指南》。我宣誓，我善意相信材料被移除或禁用是因為投訴有誤或材料標識錯誤，如有不實，願接受偽證罪處罰。我同意接受原投訴方送達的法律程序，並同意接受管轄權。」
第四步：提交與等待期
GitHub 建議透過其官方抗辯通知表格提交，以確保格式合規。提交後，GitHub 會將你的抗辯通知副本轉發給原投訴方，並告知對方內容將在 10-14 個工作日內恢復，除非對方在期限內提起法律訴訟。
這 10-14 天的等待期是整個流程中最關鍵的風險窗口。在此期間，原投訴方有權向聯邦法院提起訴訟以繼續禁用內容。若對方選擇起訴，GitHub 將不會恢復你的內容，爭議將進入司法程序。
第三章：常見錯誤與申訴失敗原因
錯誤一：未包含法定聲明
這是最常見的申訴失敗原因。GitHub 的抗辯通知表格要求包含特定的法定聲明文字，缺少其中任何一句都可能導致申訴被退回。特別是「我已閱讀並理解 GitHub 的《提交 DMCA 反通知指南》」這一句，看似形式化，卻是 GitHub 驗證通知合規性的必要條件。
錯誤二：使用非本人簽名或虛假資訊
抗辯通知必須以你的法定姓名簽署。使用化名、公司名稱或他人姓名簽署都可能導致申訴無效。DMCA 明確規定，在宣誓聲明中故意說謊構成聯邦犯罪，並可能導致民事賠償責任。
錯誤三：未具體識別被下架的內容
申訴中必須明確列出每一個被下架儲存庫的完整 URL，以及這些內容在被下架前出現的位置。僅寫「我的所有儲存庫」而不提供具體 URL，將無法通過審核。
錯誤四：未準備好面對法律訴訟
提交抗辯通知等於向原投訴方發出了一個明確信號：你願意在聯邦法院面前為自己的立場辯護。如果對方確實擁有著作權且決心維護，他們可能在等待期內提起訴訟。在沒有律師協助的情況下貿然提交抗辯通知，可能讓自己陷入不必要的法律風險。
第四章：替代策略與補救路徑
策略一：直接與投訴方協商
在許多情況下，投訴方並非惡意攻擊，而是出於誤解或溝通不足。開發者可以嘗試直接聯繫投訴方，解釋自己的立場，或提出修改方案以消除侵權疑慮。若投訴方接受，他們可以向 GitHub 提交正式的撤回聲明，GitHub 隨後會恢復被停用的內容。
需要注意：即使投訴方撤回，GitHub 也不會自動恢復儲存庫。儲存庫所有者仍需主動聯繫 GitHub 支援團隊，引用原始下架案例編號，正式請求恢復。
策略二：修改內容後重新上架
若下架的核心原因是特定檔案或功能模組，開發者可以考慮在本地移除或修改爭議內容，然後建立一個新的儲存庫，將清理後的程式碼重新上架。具體步驟包括：
- 在本地移除被指控侵權的檔案
- 使用
git filter-repo工具從提交歷史中徹底清除相關檔案（僅刪除檔案而不清理歷史是不夠的，因為 Git 歷史中仍保留著這些檔案的記錄） - 建立新的 GitHub 儲存庫，推送清理後的版本
- 在新儲存庫中加入合規聲明，說明已移除的內容及修改原因
這種做法雖然會損失原有的 Star 數和 Issue 記錄，但可以最快速度恢復專案的可存取性，避免法律風險。
策略三：遷移至其他平台
對於不願意或無法在 GitHub 上解決爭議的開發者，將專案遷移至其他程式碼託管平台是一個現實的選擇。Codeberg、GitLab、自建的 Gitea 執行個體都是可行的替代方案。遷移時應同時保留完整的提交歷史（若其中不含爭議內容），並在新的儲存庫中明確標示授權條款。
第五章：第 512(f) 條——對抗惡意下架的法律武器
什麼是第 512(f) 條
DMCA 第 512(f) 條規定，任何人若在通知中故意重大不實陳述，聲稱材料或活動構成侵權，或聲稱材料因錯誤或誤識別而被移除，應對因此遭受損害的一方承擔賠償責任，包括訴訟費用和律師費。這項條款是對抗惡意或輕率下架通知的法律基礎。
實際適用場景
第 512(f) 條的適用門檻較高。法院通常要求證明投訴方在主觀上明知其陳述不實，或對事實真相存在「故意漠視」。單純的過失或善意誤解通常不足以構成第 512(f) 條的違反。
然而，在某些案件中，法院已認定著作權人不能透過「刻意迴避知悉真相」來逃避責任。例如，若投訴方明知其下架通知可能包含不實陳述，卻選擇不對通知內容進行最基本的核實，法院可能認定其構成第 512(f) 條的違反。
實務建議
對於開發者而言，第 512(f) 條更多是威懾工具而非首選訴訟策略。在提交抗辯通知時，可以附帶提及若投訴方的下架通知被認定為惡意，你保留依據第 512(f) 條追究其責任的權利。這種做法有時能促使對方重新評估其立場。
第六章：實際案例分析
案例一：youtube-dl 的下架與恢復
2020 年 10 月，美國唱片業協會（RIAA）依據 DMCA 第 1201 條向 GitHub 發送下架通知，聲稱開源工具 youtube-dl 用於規避 YouTube 的技術保護措施。GitHub 最初移除了該專案，但此舉引發了開源社群的強烈反彈。
在隨後的調查中，GitHub 的技術專家確認 youtube-dl 並未規避有效的技術保護措施，且開發者已移除了涉及版權音樂的測試範例。GitHub 恢復了該專案，並宣布了新的第 1201 條審查流程，同時撥款 100 萬美元設立開發者防禦基金。這個案例確立了一個重要先例：平台在面對反規避通知時，不應機械式執行，而應進行實質審查。
案例二：瑞芯微與 FFmpeg 的授權衝突
2025 年 12 月，FFmpeg 貢獻者向 GitHub 提交 DMCA 下架通知，指控晶片設計公司瑞芯微電子的 MPP 儲存庫違反 LGPL 授權條款——具體而言，瑞芯微使用了 FFmpeg 的程式碼，卻移除了版權聲明，且未以相容的授權條款開源其整個專案。在長達兩年的溝通未果後，FFmpeg 選擇了 DMCA 下架作為最終手段。GitHub 在審查後停用了瑞芯微的 MPP 儲存庫。
這個案例揭示了開源授權合規的重要性。違反開源授權條款不僅是道德問題，更可能導致專案被下架，對商業產品的開發和維護造成實質影響。
常見問答
被 DMCA 下架後，我的 Fork 會受到影響嗎？
會。當原始儲存庫被 DMCA 下架時，位於同一 Fork 網路中的所有 Fork 儲存庫都會受到影響。若你希望保留 Fork 中的內容，應在原始儲存庫被下架之前執行「Leave fork network」操作，將 Fork 轉換為獨立儲存庫。
提交抗辯通知需要律師嗎？
法律上並不要求，但強烈建議諮詢律師。抗辯通知是一份在偽證罪處罰下作出的法律聲明，且提交後將觸發 10-14 天的訴訟窗口。若原投訴方在此期間提起訴訟，你將需要自行承擔法律辯護費用。GitHub 的開發者防禦基金在某些情況下可以提供法律支援協助。
抗辯通知提交後多久能恢復內容？
若原投訴方未在 10-14 天的等待期內提起訴訟，GitHub 將恢復你的內容。實際恢復時間可能因 GitHub 的處理佇列而略有延遲，通常在等待期結束後的數個工作日內完成。
如果我的申訴被拒絕怎麼辦？
申訴被拒絕通常意味著抗辯通知不符合法定格式要求。你可以修改後重新提交。若申訴被拒絕的原因是你無法證明下架有誤，則需要考慮其他策略，例如與投訴方協商、修改內容後重新上架，或遷移至其他平台。
开源授權條款能否作為申訴依據？
可以。如果你使用的內容是依據 MIT、Apache 2.0、GPL 等開源授權條款發布的，且你的使用方式符合該授權條款的條件，這構成了一個強而有力的抗辯理由。但需注意，不同授權條款的條件差異很大。例如，MIT 授權要求保留版權聲明，GPL 則要求衍生作品也必須以 GPL 授權發布。違反這些條件可能使你的使用失去授權保護。
GitHub 的透明度報告提供了哪些申訴相關數據？
GitHub 每年發布透明度報告，公開 DMCA 下架通知的處理數量、受影響的儲存庫數量、抗辯通知的提交數量以及反規避通知的統計數據。2025 年的報告顯示，下半年處理了 1,354 件下架通知，影響 29,267 個儲存庫，兩項數據均創歷史新高。這些數據可以幫助開發者了解 DMCA 下架的整體趨勢和自身面臨的風險水平。
總結
GitHub 專案被 DMCA 下架是一個令人沮喪的經歷，但它並不意味著專案的終結。開發者手中握有明確的法律工具——抗辯通知——來挑戰他們認為錯誤的下架。成功的關鍵在於：準確理解 DMCA 的法律框架、嚴格遵守抗辯通知的法定格式要求、在提交前進行充分的法律風險評估，以及在必要時尋求專業法律協助。
2025 年 GitHub 處理的下架通知數量和受影響儲存庫數量雙雙創下歷史新高，顯示 DMCA 下架已成為開源開發者必須正視的風險。與此同時，GitHub 也在持續強化對開發者的保護——從反規避請求的實質審查、開發者防禦基金的設立，到與史丹佛大學法學院的合作計畫，這些機制都為面臨 DMCA 爭議的開發者提供了額外的支援。
最終，最好的防禦是預防。在開發過程中嚴格遵守開源授權條款、保留完整的版權聲明和授權文件、定期審查專案中使用的第三方程式碼，這些做法能大幅降低被 DMCA 下架的風險。而當下架真的發生時，冷靜、有策略地運用本文所述的法律工具和實務策略，是保護自身權益的最佳路徑。
作者簡介
林明，開源法律與軟體授權合規顧問，擁有資訊工程與法律雙背景。曾任職於跨國科技公司的開源合規部門，協助企業建立開源軟體使用政策，處理超過 50 件 DMCA 相關爭議。目前為獨立顧問，為開源專案維護者和企業提供授權合規與智慧財產權策略諮詢。