When a transparency report’s headline number jumps seven times in one reporting period, the question worth asking first is what changed about the counting. GitHub’s H1 2026 update reported 708 government takedown requests, up from 98 in all of 2025. Most of that jump is methodology, not moderation. The headline is real. The story behind it is more useful.
I want to walk through what GitHub actually changed about how it counts, what the new denominator tells you about the real removal rate, and why this matters more for open source maintainers than for casual readers. By the end I will tell you what I would actually track if I were running a project that gets any kind of government attention, because the right answer is not “GitHub is censoring you.”
What changed about the counting
In the H1 2025 update, GitHub expanded what counts as a takedown request. The earlier definition was narrower, focused on requests tied to specific local laws or Terms of Service violations. The new definition is broader, capturing every government request that comes in, regardless of whether it cites a statute, claims a Terms of Service issue, or just sends a letter that says “remove it.”
GitHub also changed how duplicate requests get counted. Previously, multiple agencies sending letters about the same piece of content collapsed into a single request. Now each agency gets its own line item, even if every letter says the same thing about the same repository.
The math behind this is straightforward. If three federal agencies send letters about a single popular project, the old count would be one. The new count is three. If you send a hundred letters to GitHub about a thousand different repositories, each agency letter counts separately, even when the underlying issue is identical.
This is the single biggest reason the 7x jump looks dramatic. The volume of contact from governments grew. The volume of content actually removed did not grow the same way. Takedowns processed under local law or Terms of Service violations remain relatively rare. The headline tells you governments are paying more attention to platforms. The denominator tells you the actual removal rate is far less alarming.
What the new numbers actually count
The 708 number covers every government request, regardless of outcome. Many of those requests result in no removal at all. GitHub publishes the takedowns repository (a public GitHub repository that lists every processed takedown) where you can verify what was actually removed and why. The repository is the most honest artifact GitHub publishes, because it shows the work after the policy debates are done.
The denominator that matters is the ratio of requests that resulted in action. In H1 2026, the ratio is much lower than the absolute count suggests. Most requests are logged and reviewed but do not produce a takedown. The number of removals grew at a much smaller rate than the request count, because GitHub’s review process rejects a significant share of incoming requests on jurisdiction or Terms-of-Service grounds.
Other shifts are worth naming. What counts as a “request” in the first place. The expanded definition includes informal contacts, not just formal legal demands. A phone call from a regulator is now in the count. An email from a city attorney asking about a specific repository is now in the count. A letter from a foreign ministry that cites no specific law is now in the count. Each of these would have been excluded under the old definition.
Why the policy work matters more than the headline
The transparency numbers are interesting, but the policy work GitHub reports on is the part that affects open source maintainers directly. Several U.S. state legislatures have introduced age verification bills in 2026, with California’s framing as the template. Open source projects that maintain content consumed by minors, which is most of them, are now in scope for legislation that was originally aimed at social media platforms.
Federal preemption proposals (attempts to override state laws with a single national rule) are also in the mix, and they could either simplify the situation by giving everyone one rule to follow or make it more complicated by stacking federal requirements on top of state ones. Open source carve-outs are being discussed, but the carve-outs are usually narrow and rarely protect the projects they were meant to protect.
Standards bodies are also working on content provenance (a way to label content with a verifiable origin, often through cryptographic signatures or watermarks) so that platforms do not need five different labeling schemes. The open source community has been engaged in these conversations earlier than usual, which matters because policy fights get ignored until the final version is locked. Showing up early is the difference between shaping a rule and reacting to one.
What to actually track
If you maintain a popular open source project, the transparency numbers are interesting but they are not the number that matters for your work. The numbers worth tracking are smaller and more specific:
- State bills in committee. Not the ones that already passed, but the ones still moving. A bill in committee can still be amended. A bill on the governor’s desk cannot.
- Open source carve-out language. Read the actual text of any carve-out. The carve-outs being proposed in 2026 are narrow enough that many projects do not qualify.
- Standards body publications. NIST, IETF, and W3C are all publishing drafts on provenance and labeling. The drafts become the default reference for what compliance looks like.
- Procurement language. Government contracts that require certain transparency practices pull vendors into specific technical choices. If you sell to government, the procurement documents matter.
- Your own user demographics. A project whose users skew young is in scope for age verification. A project whose users are professionals is not. Knowing which category you are in is half the work.
The number to ignore is the headline transparency jump. The jump is methodology. The work is in the policy details.
Trade-offs
Tracking all of this is not free in time. There are real costs that the “just stay informed” advice hides. The first cost is the attention budget. State legislature trackers, federal preemption news, standards body drafts, and procurement language each have their own mailing lists and their own jargon. Reading all of them well is a part-time job, and most maintainers cannot afford the time. The second cost is the political literacy floor. The policy work requires understanding legislative procedure, which is a different skill set from software engineering. Most engineers who try to engage without that literacy end up making arguments that miss the actual decision points. The third cost is the false certainty. After a few months of paying attention, the maintainer starts to believe they understand the policy landscape. That confidence is usually wrong, because policy moves faster than a part-time tracker can follow.
The honest reason to track the policy landscape is that the rules get written whether or not you show up. Showing up early is the difference between shaping a rule and reacting to one, and the projects that react are usually the ones that get squeezed by carve-outs they did not know were narrow. A maintainer who reads the actual text of a bill in committee spends an hour. A maintainer who has to migrate their project after a bill passes spends a quarter.
In our case, the project I would run today would set up two subscriptions in the first week and never lose sight of them. One is the state legislature tracker for any state whose users matter to the project. The other is the standards body publication feed for whichever provenance or labeling work is closest to the project’s domain. Everything else is secondary.
Bottom line
If you remember three things from this piece, make them these. The 7x jump is a methodology change, and the new denominator tells you the actual removal rate is much smaller than the headline suggests. The transparency report is a useful artifact but it is not the artifact that matters for open source maintainers, who need to track the policy bills in committee and the actual text of any standards body drafts. The policy work is moving faster than a part-time tracker can follow, and the projects that show up early are the projects that shape the rules instead of reacting to them.
If I could send a message back to the version of me that saw the headline and assumed the worst about platform moderation, I would say three things. Read the methodology footnote before you share a number on social media. Treat raw takedown counts as engagement signals, not censorship signals. And remember that the headline is the part of the story the press releases, and the actual removal rate is the part the takedowns repository shows.