DMCA 下架政策

本文内容

欢迎来到 GitHub 的《数字千年版权法》指南，俗称“DMCA”。本页面并非旨在作为该法规的全面入门指南。但是，如果您收到了针对您在 GitHub 上发布的内容的 DMCA 下架通知，或者您是希望发布此类通知的权利人，本页面将有助于您更好地理解该法律以及我们遵守该法律的政策。

（如果您只想提交通知，可以跳到“G. 提交通知”。）

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

什么是 DMCA？

为了理解 DMCA 及其所划定的某些政策界限，或许可以考虑一下它颁布之前的情况。

DMCA 为托管用户生成内容的服务提供商提供了一个安全港。由于即使是单一的版权侵权索赔也可能承担高达 150,000 美元的法定赔偿金，因此对用户生成内容承担责任的可能性对服务提供商来说可能是非常有害的。随着潜在损害赔偿金在数百万用户中成倍增加，像 YouTube、Facebook 或 GitHub 这样的云计算和用户生成内容网站可能根本不会存在，如果没有 DMCA（或者至少没有将部分成本转嫁给用户）。

DMCA 通过为托管涉嫌侵权用户生成内容的互联网服务提供商创建版权责任安全港来解决这个问题。本质上，只要服务提供商遵循 DMCA 的通知和下架规则，它就不会因用户生成内容而承担版权侵权责任。因此，GitHub 保持其 DMCA 安全港地位非常重要。

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

DMCA 通知简述

DMCA 提供了两个简单直接的程序，所有 GitHub 用户都应该了解：(i) 下架通知程序，供版权所有者请求删除内容；以及 (ii) 反通知程序，供用户在内容被错误删除或误识别时重新启用内容。

DMCA 下架通知由版权所有者使用，要求 GitHub 删除他们认为侵权的内容。如果您是软件设计师或开发人员，您每天都会创建受版权保护的内容。如果其他人未经授权在 GitHub 上使用您的受版权保护的内容，您可以向我们发送 DMCA 下架通知，要求更改或删除侵权内容。

另一方面，反通知可用于纠正错误。也许发送下架通知的人不拥有版权，或者没有意识到您有许可证，或者在他们的下架通知中犯了一些其他错误。由于 GitHub 通常无法知道是否发生了错误，因此 DMCA 反通知允许您通知我们并要求我们重新发布内容。

DMCA 通知和下架流程仅应用于针对版权侵权的投诉。通过我们的 DMCA 流程发送的通知必须识别据称被侵权的版权作品或作品。该流程不能用于其他投诉，例如针对据称的 商标侵权 或 敏感数据 的投诉；对于这些情况，我们提供单独的流程。

A. 这实际上是如何运作的？

DMCA 框架有点像在课堂上传纸条。版权所有者向 GitHub 提交关于用户的投诉。如果写得正确，我们会将投诉转交给用户。如果用户对投诉有异议，他们可以回传纸条说明情况。GitHub 在该流程中几乎没有自由裁量权，只是确定通知是否符合 DMCA 的最低要求。由各方（及其律师）评估其主张的价值，并牢记通知必须在作伪证的处罚下进行。

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

  1. 版权所有者调查。版权所有者应始终进行初步调查，以确认 (a) 他们拥有原创作品的版权，以及 (b) GitHub 上的内容未经授权且构成侵权。这包括确认该使用是否不受 合理使用 的保护。如果只使用少量版权内容、以改造方式使用该内容、出于教育目的使用该内容，或以上几种情况的组合，则特定使用可能是合理的。由于代码天生适合此类使用，因此每个用例都不同，必须单独考虑。

    示例：Acme Web 公司的一名员工在 GitHub 存储库中发现了一些公司的代码。Acme Web 公司将其源代码许可给几个值得信赖的合作伙伴。在发送下架通知之前，Acme 应审查这些许可证及其协议，以确认 GitHub 上的代码未经任何许可证授权。

  2. 版权所有者发送通知。在进行调查后，版权所有者会准备并发送 下架通知 给 GitHub。假设下架通知根据法定要求足够详细（如 操作指南 中所述），我们将 发布通知 到我们的 公共存储库 并将链接传递给受影响的用户。

  3. GitHub 要求用户进行更改。如果通知声称整个存储库的内容构成侵权，或软件包构成侵权，我们将跳到步骤 6 并立即禁用整个存储库或软件包。否则，由于 GitHub 无法禁用对存储库中特定文件的访问，我们将联系创建存储库的用户，并给他们大约 1 个工作日的时间来删除或修改通知中指定的内容。如果我们给用户机会进行更改，我们将通知版权所有者。由于软件包是不可变的，如果软件包的一部分构成侵权，GitHub 将需要禁用整个软件包，但我们允许在删除侵权部分后恢复软件包。

  4. 用户通知 GitHub 更改。 如果用户选择进行指定的更改，他们必须在约 1 个工作日的时间窗口内通知我们。如果他们没有这样做，我们将禁用存储库（如步骤 6 中所述）。如果用户通知我们他们已进行更改，我们将验证更改是否已完成，然后通知版权所有者。

  5. 版权所有者修改或撤回通知。 如果用户进行更改，版权所有者必须审查更改，并在更改不足的情况下更新或修改其下架通知。除非版权所有者联系我们以更新原始下架通知或提交修改后的通知，否则 GitHub 不会采取任何进一步的行动。如果版权所有者对更改感到满意，他们可以提交正式撤回通知，也可以不采取任何行动。GitHub 将把超过两周的沉默解释为对下架通知的默示撤回。

  6. GitHub 可能会禁用对内容的访问。 GitHub 将禁用用户的以下内容： (i) 版权所有者声称对用户的整个存储库或软件包拥有版权（如步骤 3 中所述）；(ii) 用户在被给予更改机会后没有进行任何更改（如步骤 4 中所述）；或 (iii) 版权所有者在用户有机会进行更改后更新了其下架通知。如果版权所有者选择修改通知，我们将返回步骤 2 并重复该过程，就好像修改后的通知是新的通知一样。

  7. 用户可以发送反通知。 我们鼓励内容被禁用的用户咨询律师了解他们的选择。如果用户认为其内容被禁用是由于错误或误识别，他们可以向我们发送反通知。与原始通知一样，我们将确保反通知足够详细（如操作指南中所述）。如果是这样，我们将发布到我们的公共存储库中，并将通知通过发送链接的方式传递给版权所有者。

  8. 版权所有者可以提起诉讼。 如果版权所有者希望在收到反通知后继续禁用内容，他们需要提起诉讼，寻求法院命令禁止用户在 GitHub 上进行与该内容相关的侵权活动。换句话说，你可能会被起诉。如果版权所有者未在 10-14 天内通过发送在有管辖权的法院提起的有效法律诉讼副本的方式通知 GitHub，GitHub 将重新启用被禁用的内容。

B. 分支怎么办？（或者什么是分支？）

GitHub 最棒的功能之一是允许用户“分支”彼此的仓库。这是什么意思？本质上，这意味着用户可以将 GitHub 上的项目复制到自己的仓库中。根据许可证或法律的允许，用户可以对该分支进行更改，将其推送到主项目中，或者将其保留为项目的变体。每个副本都是原始仓库的“GitHub 词汇表”，而原始仓库也可能被称为该分支的“父仓库”。

GitHub 不会在禁用父仓库时自动禁用分支。这是因为分支属于不同的用户，可能已经以显著的方式进行了更改，并且可能以受合理使用原则保护的不同方式获得许可或使用。GitHub 不会对分支进行任何独立调查。我们期望版权所有者进行该调查，如果他们认为分支也构成侵权，则在他们的下架通知中明确包含分支。

在极少数情况下，您可能声称对正在积极分支的完整仓库存在版权侵权。如果您在提交通知时已将该仓库的所有现有分支识别为涉嫌侵权，那么我们将在处理通知时对该网络中当时的所有分支处理有效索赔。我们会这样做，因为所有新创建的分支都可能包含相同的内容。此外，如果报告的网络包含涉嫌侵权内容的仓库数量超过一百 (100) 个，因此难以全面审查，如果您在通知中声明，“根据我审查的代表性分支数量，我相信所有或大多数分支都与父仓库一样构成侵权”，我们可能会考虑禁用整个网络。您的宣誓声明将适用于此声明。

C. 规避索赔怎么办？

DMCA 禁止规避有效控制对受版权保护作品访问的技术措施。鉴于此类索赔通常具有高度技术性，GitHub 要求索赔人提供有关这些索赔的详细信息，我们会进行更深入的审查。

规避索赔必须包含以下有关技术措施和被指控项目规避这些措施方式的详细信息。具体而言，发给 GitHub 的通知必须包含详细说明以下内容的声明

  1. 技术措施是什么；
  2. 他们如何有效地控制对受版权保护材料的访问；以及
  3. 被告项目是如何设计来绕过他们之前描述的技术保护措施的。

GitHub 将仔细审查规避索赔，包括由技术和法律专家进行审查。在技术审查中，我们将寻求验证有关技术保护措施运作方式和项目据称规避这些措施方式的详细信息。在法律审查中，我们将寻求确保索赔不超出 DMCA 的范围。在无法确定索赔是否有效的情况下，我们将站在开发人员一边，并将内容保留。如果索赔人希望提供更多详细信息，我们将重新启动审查流程以评估修改后的索赔。

如果我们的专家确定索赔完整、合法且技术上合理，我们将联系仓库所有者，并给他们机会对索赔做出回应或对仓库进行更改以避免下架。如果他们没有回应，我们将尝试再次联系仓库所有者，然后再采取任何进一步的措施。换句话说，我们不会仅凭规避技术索赔而禁用仓库，而不会先尝试联系仓库所有者，给他们机会做出回应或进行更改。如果我们无法通过首先联系仓库所有者来解决问题，即使内容已被禁用，我们也始终乐于考虑仓库所有者的回应，如果他们希望有机会对索赔提出异议，向我们提供更多事实，或进行更改以恢复内容。当我们需要禁用内容时，我们将确保仓库所有者可以在法律允许的范围内导出其问题和拉取请求以及其他不包含据称规避代码的仓库数据。

请注意，我们对规避技术的审查流程不适用于违反我们的《可接受使用政策》中关于分享未经授权的产品许可证密钥、用于生成未经授权的产品许可证密钥的软件或用于绕过产品许可证密钥检查的软件的限制的内容。尽管这些类型的索赔也可能违反 DMCA 关于规避技术的规定，但这些通常很简单，不需要额外的技术和法律审查。尽管如此，如果索赔并不简单，例如越狱的情况下，规避技术索赔审查流程将适用。

当 GitHub 根据我们的规避技术索赔审查流程处理 DMCA 下架时，我们将为仓库所有者提供转介，让他们通过 GitHub 的开发者辩护基金 免费获得独立的法律咨询。

D. 如果我不小心错过了修改内容的时间窗口怎么办？

我们理解，您可能有很多正当理由无法在我们提供的大约 1 个工作日的时间窗口内进行修改。也许我们的邮件被标记为垃圾邮件，也许您正在休假，也许您不定期查看该电子邮件帐户，或者也许您只是很忙。我们理解。如果您回复我们，告诉我们您本想进行修改，但不知何故错过了第一次机会，我们将重新启用存储库大约 1 个工作日，以便您进行修改。再次强调，您必须通知我们您已完成修改，以便在该大约 1 个工作日的时间窗口结束后继续启用存储库，如上文 步骤 A.4 中所述。请注意，我们只提供一次额外机会。

E. 透明度

我们认为透明度是一种美德。公众应该知道哪些内容从 GitHub 中删除以及原因。知情的公众可以注意到并发现潜在的问题，否则这些问题在不透明的系统中会被人忽视。我们将发布我们收到的任何法律通知的经过编辑的副本（包括原始通知、反通知或撤回通知），地址为 https://github.com/github/dmca。我们不会公开发布您的个人联系信息；我们在发布通知之前会删除个人信息（URL 中的用户名除外）。但是，除非您明确要求我们，否则我们不会从您的通知中删除任何其他信息。以下是一些已发布的 通知 和 反通知 的示例，供您参考。当我们删除内容时，我们将在其位置发布指向相关通知的链接。

另请注意，虽然我们不会公开发布未经编辑的通知，但我们可能会向任何受其影响的权利方提供我们收到的任何通知的完整未经编辑的副本。

F. 重复侵权

GitHub 的政策是在适当情况下，并由其自行决定，禁用和终止可能侵犯 GitHub 或其他方版权或其他知识产权的用户的帐户。

G. 提交通知

如果您已准备好提交通知或反通知

了解更多并发表意见

如果您在互联网上四处浏览，不难找到关于版权制度本身以及 DMCA 的评论和批评。虽然 GitHub 承认并赞赏 DMCA 在促进在线创新方面发挥的重要作用，但我们认为版权法可能需要修补一下——如果不是完全重新发布的话。在软件方面，我们不断改进和更新我们的代码。想想自 1998 年 DMCA 制定以来技术发生了多少变化。更新这些适用于软件的法律难道没有道理吗？

我们不假装拥有所有答案。但如果您好奇，以下是一些我们找到的关于改革意见和建议的学术文章和博客文章链接。

GitHub 不一定认可这些文章中的任何观点。我们提供这些链接是为了鼓励您了解更多信息，形成自己的观点，然后联系您当选的代表（例如，在美国国会或欧盟议会）寻求您认为应该进行的任何更改。