DMCA 删除政策

欢迎阅读 GitHub 的《数字千年版权法案》（DMCA）指南。此页面并非该法案的完整入门教材。但如果您收到针对您在 GitHub 上发布的内容的 DMCA 删除通知，或者您是权利持有人，想要发出此类通知，本页将帮助您稍微解开法律的神秘面纱，并了解我们遵守该法的相关政策。

(如果您只想提交通知，可以直接跳到 G. 提交通知。)

和所有法律事务一样，最好就您的具体问题或情况咨询专业人士。我们强烈建议您在采取可能影响您权利的任何行动之前这样做。本指南并非法律意见，也不应被视为法律意见。

什么是 DMCA？

要了解 DMCA 以及它所衍生的若干政策条款，回顾它颁布前的生活或许会有帮助。

DMCA 为托管用户生成内容的服务提供商提供了安全港。由于一次版权侵权指控最高可导致高达 150,000 美元的法定赔偿，服务提供商因用户生成内容而承担责任的风险极高。如果不考虑 DMCA，云计算平台以及 YouTube、Facebook、GitHub 等用户生成内容站点可能根本不存在（或者至少不会在不将部分成本转嫁给用户的情况下存在）。

DMCA 通过为托管据称侵权的用户生成内容的互联网服务提供商创建版权责任安全港来解决此问题。基本上，只要服务提供商遵循 DMCA 的通知‑删除规则，就不会因用户生成内容而对版权侵权承担责任。因此，GitHub 必须维护其 DMCA 安全港地位。

DMCA 还禁止规避技术措施，这些技术措施有效地控制对受版权保护作品的访问。

DMCA 通知概述

DMCA 为所有 GitHub 用户提供了两套简明、直接的程序：(i) 删除通知程序，供版权持有人请求移除内容；以及 (ii) 反通知程序，供用户在内容被错误删除或误认时恢复内容。

另一方面，反通知可用于纠正错误。也许发送删除通知的人并未持有版权，或没有意识到您拥有授权，或在其删除通知中出现其他错误。由于 GitHub 通常无法判断是否存在错误，DMCA 反通知允许您告知我们并请求重新上架内容。

DMCA 通知和删除流程仅用于版权侵权的投诉。通过我们的 DMCA 流程发送的通知必须指明所指称被侵权的受版权保护的作品。该流程不能用于其他类别的投诉，例如针对商标侵权或敏感数据的投诉；我们为这些情形提供了独立的流程。

A. 这到底是怎么运作的？

DMCA 框架有点像课堂上传纸条。版权拥有者把对某位用户的投诉递交给 GitHub。如果内容写得合规，我们会把投诉转交给该用户。如果用户对投诉提出异议，他们可以回递纸条。GitHub 在此过程中的自由裁量权几乎只有判断通知是否符合 DMCA 的最低要求。具体的权利与义务评估留给当事人（及其律师），并且所有通知均需在作伪证罪的处罚下作出。

以下是此流程的基本步骤。

版权拥有者调查。 版权拥有者应始终先进行初步调查，以确认 (a) 他们拥有原始作品的版权，以及 (b) GitHub 上的内容未经授权且构成侵权。这包括确认该使用不属于合理使用。当使用仅涉及少量受版权保护的内容、以变形方式使用、用于教育目的或上述组合时，可能构成合理使用。由于代码天生易于产生此类使用，每一种使用情形都不同，需要单独评估。

示例： Acme Web Company 的一名员工在 GitHub 仓库中发现了公司的部分代码。Acme Web Company 将其源代码授权给多个可信合作伙伴。在发送删除通知之前，Acme 应审查这些许可证及其协议，以确认 GitHub 上的代码未获授权。
版权拥有者发送通知。 完成调查后，版权拥有者准备并向 GitHub 发送删除通知。只要该删除通知根据法定要求（如操作指南所述）足够详细，我们将在我们的公开仓库 https://github.com/github/dmca 中公布该通知，并将链接转发给受影响用户。
GitHub 请求用户进行修改。 如果通知声称整个仓库或整个软件包均构成侵权，我们将直接跳至第 6 步，迅速禁用整个仓库或软件包。否则，由于 GitHub 无法对仓库内单个文件进行访问限制，我们会联系创建该仓库的用户，给予其大约 1 个工作日的时间来删除或修改通知中指明的内容。我们将在给用户提供修改机会时通知版权拥有者。因为软件包是不可变的，如果仅有部分软件包侵权，GitHub 仍需禁用整个软件包，但在侵权部分移除后我们允许恢复。
用户通知 GitHub 已完成修改。 若用户选择进行指定的修改，他们 **必须** 在大约 1 个工作日的窗口期内告知我们。如果未告知，我们将在第 6 步中禁用该仓库。如果用户通知我们已完成修改，我们会核实修改已生效后再通知版权拥有者。
版权拥有者修改或撤回通知。 若用户已完成修改，版权拥有者必须审查这些修改，并在修改不足时续发或修订其删除通知。除非版权拥有者联系 GitHub 续发原删除通知或提交修订版，否则 GitHub 不会采取进一步行动。若版权拥有者对修改满意，他们可以正式撤回通知，或保持沉默。GitHub 将把超过两周的沉默视为对删除通知的默示撤回。
GitHub 可能禁用内容访问。 当出现以下任一情形时，GitHub 将禁用用户内容：(i) 版权拥有者指称整个仓库或软件包侵犯其版权（如第 3 步所述）；(ii) 用户在获准修改后未作任何修改（如第 4 步所述）；或 (iii) 版权拥有者在用户获得修改机会后仍续发其删除通知。如果版权拥有者改为 **修订** 通知，GitHub 将回到第 2 步，视修订后的通知为全新通知重新进行流程。
用户可发送反通知。 我们鼓励内容被禁用的用户咨询律师，以了解可行的选项。如果用户认为其内容因错误或误认而被禁用，可向我们发送反通知。与原通知一样，我们会确保反通知足够详细（如操作指南所述）。若符合要求，我们会在我们的公开仓库上公布，并将链接回传给版权拥有者。
版权拥有者可提起法律诉讼。 如果版权拥有者在收到反通知后仍希望保持内容禁用状态，则需通过提起诉讼，寻求法院命令限制用户在 GitHub 上继续进行侵权活动。换句话说，您可能会被起诉。若版权拥有者在 10‑14 天内未向 GitHub 提交有效的法院起诉副本，GitHub 将重新启用被禁用的内容。

B. 那么 fork 是什么？（或者 fork 是什么？）

GitHub 最棒的功能之一是用户可以 “fork” 彼此的仓库。这意味着什么？本质上，用户可以将 GitHub 上的项目复制到自己的仓库中。只要许可证或法律允许，用户便可以对该 fork 进行更改，随后推回主项目或仅作为自己的项目变体保存。每一个此类副本都是原始仓库的 GitHub 术语，而原仓库则可称为该 fork 的 “父仓库”。

GitHub 不会在禁用父仓库时自动禁用其 fork。原因在于 fork 属于不同的用户，可能已被显著修改，且可能在不同的许可证或使用方式下受合理使用原则保护。GitHub 不会对 fork 进行独立调查。我们期望版权拥有者自行调查，并在认为 fork 也构成侵权时，在其删除通知中明确列出 fork。

在极少数情况下，您可能正在针对一个正在被积极 fork 的完整仓库提出侵权指控。如果在您提交通知时已标识出所有现有的 fork 为侵权，我们将在处理通知时对当时网络中的所有 fork 进行有效主张。鉴于新创建的 fork 极有可能包含相同内容，我们会据此处理。此外，如果涉及的网络包含的仓库数量超过一百（100）且难以逐一审查，我们可能会在您的通知中出现以下声明时禁用整个网络：“基于我审查的代表性 fork 数量，我认为所有或大多数 fork 与父仓库的侵权程度相同。” 您的宣誓声明将适用于此说明。

C. 那么规避主张呢？

DMCA 禁止规避技术措施，这些技术措施有效地控制对受版权保护作品的访问。鉴于此类主张往往高度技术化，GitHub 要求主张方提供详细信息，并进行更为深入的审查。

规避主张必须包括以下关于技术措施及被指项目规避方式的细节。具体而言，通知 GitHub 时必须包含对以下内容的详细陈述：

技术措施是什么；
这些措施如何有效控制对受版权保护材料的访问；以及
被指项目是如何设计以规避上述技术保护措施的。

GitHub 将对规避主张进行严格审查，审查工作由技术与法律专家共同完成。在技术审查中，我们将验证技术保护措施的运作方式及项目声称的规避方式；在法律审查中，我们将确保主张未超出 DMCA 的范围。若我们无法确定主张是否合法，我们将倾向于开发者，保持内容上线。若主张人希望补充细节，我们会重新启动审查流程，以评估修订后的主张。

当我们的专家认定主张完整、合法且技术上可信时，我们会联系仓库所有者，给他们机会回应主张或修改仓库以避免删除。如果他们未回应，我们将在采取进一步措施前再次尝试联系仓库所有者。换言之，我们不会在未先尝试联系仓库所有者并给其回应或修改机会的情况下，仅凭规避技术主张禁用仓库。如果首次联系未能解决问题，即使内容已被禁用，我们仍乐意在仓库所有者提供争议、补充事实或进行修改后重新上架。当我们需要禁用内容时，将在法律允许的范围内确保仓库所有者能够导出除涉嫌规避代码之外的 issue、pull request 及其他仓库数据。

请注意，我们对规避技术的审查流程不适用于本应受《可接受使用政策》限制的内容——例如共享未经授权的产品授权密钥、生成未经授权的产品授权密钥的软件，或用于绕过产品授权密钥检查的软件。虽然这些主张同样可能违反 DMCA 对规避技术的规定，但通常较为直接，无需额外的技术和法律审查。不过，当主张不够直接（例如 jailbreak），则仍适用规避技术主张审查流程。

当 GitHub 根据我们的规避技术主张审查流程处理 DMCA 删除时，我们将向仓库所有者提供通过 GitHub 开发者防御基金获得独立法律咨询的转介，费用全免。

D. 如果我不小心错过了修改的时限怎么办？

我们认识到，您可能因多种合理原因未能在约 1 个工作日的窗口期内完成修改。也许我们的信息被标记为垃圾邮件，您正度假，您并不经常查看该邮箱，或只是太忙了。我们理解。如果您回复告知我们本想进行修改却错过了第一次机会，我们将再额外为您提供约 1 个工作日的时间重新启用仓库，以便您完成修改。正如上文步骤 A.4 所述，您必须在此额外窗口期内通知我们已完成修改，方能保持仓库启用。请注意，我们仅提供这一次额外机会。

E. 透明度

我们相信透明度是一种美德。公众应当知道 GitHub 正在删除哪些内容以及原因。知情的公众能够发现并揭露在不透明系统中可能被忽视的问题。我们会在 https://github.com/github/dmca 上发布我们收到的任何法律通知（包括原始通知、反通知或撤回）的马赛克处理副本。我们不会公开发布您的个人联系信息；在发布通知前会删除个人信息（URL 中的用户名除外）。除非您明确要求，我们不会对通知的其他信息进行马赛克处理。以下是已发布的通知与反通知示例，您可查看其外观。当我们移除内容时，会在原位置发布相关通知的链接。

请同样注意，虽然我们不会公开未马赛克处理的通知，但我们可能会向任何受该通知影响的当事方直接提供完整的未马赛克副本。

非预期后果：DMCA 十二年（电子前哨基金会）
版权法中的法定赔偿：亟待改革的救济（William & Mary 法律评论）
版权保护期限是否过长？（The 1709 Blog）
如果我们要修改 DMCA 的“通知‑删除”，就应关注其被滥用的广度（TechDirt）
版权改革的机会（Cato Unbound）
合理使用原则与数字千年版权法案：在 DMCA 下互联网是否存在合理使用？（圣克拉拉法学评论）

GitHub 并不一定赞同这些文章中的任何观点。我们提供这些链接是为了鼓励您进一步了解、形成自己的看法，并向您所在地区的民选代表（例如美国国会或欧盟议会）提出您认为应当进行的变革。

本文内容