github/dmca: the public archive of takedown notices GitHub received

What github/dmca actually is, and who needs it

The repository holds the text of DMCA takedown notices and counter-notices GitHub has received. The README states the project was inspired by Lumen (formerly Chilling Effects) and by Google's DMCA publication practice, and that notices are published as received, with only private information redacted, along with URLs that GitHub determined were not actionable under the DMCA.

The intended reader is not a developer looking for a library. It is someone who wants the primary document: a researcher measuring how often takedowns target particular kinds of repositories, a journalist checking what a company actually claimed, or a maintainer who wants to see how a notice against a similar repository was worded. The README is explicit that posting a notice here means only that GitHub received it on the indicated date, and that GitHub makes no judgment about the merit of the claims.

That framing matters. The archive is evidence of receipt and processing, not of wrongdoing. Anyone citing a notice as proof that content was infringing is misreading the project's own stated position.

How the archive is organized, and how notices are annotated

The top level of the repository is a set of year directories running from 2011 through 2026, plus a data/ directory, CONTRIBUTING.md and README.md. The primary language listed for the repository is DIGITAL Command Language, which is a byproduct of the notice files rather than a sign that the project is a software codebase.

Each notice is published with the original text and a small set of annotations. The README documents four of them. The first is a note, added starting in March 2021, recording that GitHub contacted repository owners to give them a chance to make changes before processing the notice, and pointed them at the counter-notice guide. The README explains that this appears when the notice did not allege that an entire repository infringed, or when the copyright holder identified changes that would resolve the complaint, because GitHub cannot disable individual files inside a repository and instead gives the owner roughly one business day to delete or modify the content.

The second annotation is the marker [invalid], used where GitHub decided only some of the reported URLs were actionable, including cases where reported content was not available at review time. Before March 2021 those URLs were replaced with [private], which is still used for redacting private information.

The third covers fork networks. Where a notice reported a repository that was actively being forked, and the submitter identified all known forks, GitHub processed the notice against the entire fork network, and the notice carries a note stating how many forks were disabled. The fourth covers networks larger than one hundred repositories: in those cases the submitter reviewed a representative sample of forks and included a sworn statement that all or most forks were infringing to the same extent as the parent, and GitHub disabled the whole network.

Those annotations are the most useful part of the archive for anyone doing analysis, because they separate the claim from the outcome.

Reading a notice: what the files tell you and what they do not

A notice file is a document, not a record with structured fields, so any analysis means parsing prose. The annotations are the closest thing to a status column: a notice with the pre-processing contact note may describe a repository that is still available, because the owner made changes, or one that is gone because the owner deleted it. The README says both outcomes are possible and that the notice itself will not always tell you which happened.

The [invalid] and [private] markers carry different meanings and should not be treated as the same thing. [invalid] means GitHub judged the reported URL not actionable; [private] means information was redacted. A dataset that counts them together will overstate how many claims were rejected.

For fork networks, the notice records the number of forks disabled at processing time. That number is a snapshot, not a current count, and the README gives no way to reconstruct the network afterwards. Anyone building a time series from these files should expect the fork figures to be one-off measurements rather than a continuous series.

Getting the archive and finding a notice

There is no installer and no package. The repository is the artifact; you read the files it contains. The README gives no build steps, no configuration keys and no environment variables, so any tooling for reading the notices is something you bring yourself. Anyone who wants to inspect the archive can fetch it from the project's homepage on GitHub.

Once you have the text, the year directories are the index. A notice received in a given year sits in that year's folder, and the README does not describe an alternative lookup path. To find notices that mention a specific repository or party, work inside a single year folder rather than the whole tree, since the README documents no search interface.

Read the top of each notice before the body. The annotations described in the README sit there, and they change how you should interpret everything below them: whether the owner was given a chance to change the content, whether some reported URLs were judged not actionable, and whether a fork network was processed.

Where the archive stops being the right tool

The repository is read-only by design. The README tells anyone looking to file or dispute a takedown notice by posting here to stop, because GitHub does not accept pull requests or other contributions, and notes that GitHub does not actively monitor comments. If your goal is to send a notice, to counter a notice, or to argue about one, this repository is the wrong destination; the README points to the DMCA policy and to GitHub support instead.

There is also no licence stated for the repository, which is a real constraint for anyone planning to redistribute the notices in bulk or republish them in a dataset. The README does not address reuse terms, so a project that needs a clear redistribution licence cannot get one from this material.

The archive is also incomplete as a picture of enforcement. It records notices GitHub received and processed. It does not record notices sent to other platforms, and it does not record disputes that never reached GitHub. A study of takedown behavior built only on this repository is a study of GitHub's inbox.

Finally, the redaction is deliberate and permanent. Private information is removed, so a notice cannot be used to identify the reporting party where GitHub chose to redact, and the [private] marker tells you a removal happened without telling you what was removed.

Lumen and Google's DMCA publication as the reference points

The README names the two projects this one follows: Lumen, formerly Chilling Effects, and Google's DMCA publication. The difference is scope and format. Lumen is a cross-platform database that aggregates notices from many senders and recipients and offers structured search over them, while github/dmca is a single company's record stored as plain text in year folders. Google publishes notices it receives for Search, and the README links to that practice as inspiration rather than as an integration.

If you need to search notices across many platforms, or you need fields rather than prose, Lumen is the closer fit and this repository will feel like raw material you have to normalize yourself. If you need the exact text GitHub published, including the annotations describing how GitHub processed the notice, this repository is the only place that text lives in that form. The two are complementary: use the archive here for GitHub-specific processing detail, and a cross-platform database for breadth.

The README also quotes Chilling Effects from 2014 on the concern that cease and desist letters can silence Internet users regardless of legal merit, which is the stated reason GitHub publishes notices at all. That is a policy rationale, not a feature, and it explains why the annotations emphasize what GitHub did rather than what the claim asserted.

Maintenance, format stability and cost of use

The repository is not archived, and the last push was on 2026-09-21, so notices continue to be added. There are no releases, which fits a repository that publishes documents rather than versioned software: there is nothing to upgrade, and no changelog to track. The cost of staying current is the cost of pulling new commits.

The format is append-only in practice, one directory per year, with the annotation conventions documented in the README and dated to March 2021. That date is the dividing line for anyone doing longitudinal work: notices before March 2021 use [private] where later notices use [invalid], and the pre-processing contact note does not appear at all. A parser written against 2026 notices will not silently work on 2015 notices, and it should not try to.

On licensing, the repository states no licence. That does not tell you what you may do with the notices; it tells you the repository does not grant you terms. If redistribution matters to your project, that is a question for the notices' contents and for GitHub, not something the README resolves.

Editorial conclusion

Use github/dmca if you need the primary text of notices GitHub processed, for research, journalism or legal review, and treat the year folders as the index. Do not use it to file or dispute a notice: the README says GitHub does not accept pull requests or contributions here, and directs you to the DMCA policy and support contact instead. Before relying on any single notice, read the annotations at the top of the file, since they record whether content was disabled, whether only some URLs were actionable, and whether a fork network was processed. Check the data/ directory and the newest year folder first if you need recent notices.

Frequently asked questions

Official sources

1. github/dmca on GitHub
2. Issues
3. Project website
4. README