GitHub published a September 29 update covering its H1 2026 transparency data and several policy issues affecting developers and open source projects. The update is useful because it separates a large increase in reported government requests from actual content removals and explains why developers are increasingly part of policy discussions around AI transparency and age assurance.
Why GitHub reported more government requests
GitHub says it received 708 government takedown requests in the first half of 2026, compared with 98 requests during all of 2025. That number should not be read as a direct measure of how much content GitHub removed.
GitHub says the increase is largely related to reporting methodology. Its reporting now includes all government takedown requests received, including requests that do not rely on local law or a Terms of Service violation. It also counts duplicate requests about the same content.
The company says takedowns processed under local law or its Terms of Service remain relatively rare. This distinction is important when using transparency numbers in research or reporting.
What developers should take from the transparency data
The practical lesson is to check the definition behind a transparency metric before comparing it with older reports. A change in counting rules can make two headline numbers look directly comparable when they are not.
For organizations that publish open source software, it is also useful to keep a record of repository ownership, licensing, takedown contacts and the legal basis for any removal request. That makes it easier to respond consistently if a project receives a request.
AI provenance is becoming a developer issue
GitHub's update also discusses content provenance and AI transparency. These rules are designed to help people understand whether digital content was created or changed with AI, but GitHub points out that broad definitions can create problems when applied to open source infrastructure.
One example is California's AI Transparency Act. GitHub says the legislation moved toward a narrower notice-and-response approach after concerns about conflicts with widely used open source licenses. GitHub also says implementation questions remain.
The important point for developers is that provenance rules can affect software infrastructure even when the original policy goal is focused on consumer-facing AI systems. Repository operators, package maintainers and open source projects may need to watch how final definitions are applied.
Age assurance and open source software
GitHub also discussed age-assurance proposals in several U.S. states. Its concern is that laws aimed at consumer-facing services can unintentionally cover developer tools, operating systems or open source infrastructure because of broad technical definitions.
For developers, the issue is less about choosing a side in a policy debate and more about understanding scope. A law that defines an online service broadly can have very different implementation effects depending on whether the service is a social network, code repository, package registry or development tool.
Why this matters for AI projects
AI projects sit across several of these boundaries. A model repository may contain generated assets. A developer platform may host AI-generated code. A project may use provenance metadata while also relying on open source licenses that were designed for modification and redistribution.
Teams should therefore track the policy requirements that apply to their actual product, rather than assuming that a rule aimed at an AI chatbot automatically applies in the same way to an API, code repository or open source library.
A practical policy-review workflow
- Identify the jurisdictions that matter to your product and users.
- Read the final law or official guidance rather than relying on summaries.
- Check definitions for repositories, developer tools, platforms and AI systems.
- Map each requirement to the technical component that would implement it.
- Record unresolved implementation questions before changing production systems.
- Recheck the policy after final rules or agency guidance are published.
What remains unresolved
GitHub's post describes policy developments and the company's position on how some rules could affect open source. It is not a legal interpretation for every project. Developers should use the primary legislation and applicable legal guidance for decisions that affect compliance.
Sources
- GitHub: Developer policy update — transparency, state policy, and what's ahead
- GitHub Government Takedowns repository