Global age assurance laws aimed at protecting minors online are reaching into operating systems, app stores, and developer tooling, with unclear scope that could burden open source maintainers and volunteer-driven projects. Here’s what developers need to know about the evolving legislation, how it impacts the open source ecosystem, and how to engage with policymakers to avoid unintended restrictions.
Margaret Tucker · @margaret-tucker May 8, 2026 | 9 minute read
Policymakers around the world are advancing age assurance proposals to protect children and teens online. Some approaches restrict minors’ access to certain services or content, while others require devices, operating systems, or app stores to collect age information and pass age signals to apps and websites. These proposals address real, serious concerns, but without appropriate scoping, they risk imposing burdensome requirements on open source software and developer infrastructure services that don’t present the same risks to minors as consumer-facing platforms.
Let’s break down what developers need to know, why this matters for the open source ecosystem, and how you can engage with policymakers to shape these laws.
What’s new: The current wave of age assurance legislation
The harms these laws aim to address are serious and deserve attention. Grooming for sexual purposes, exposure to violent content, and online bullying are common risks young people face online. At the same time, participating in online communities, including open source software development, is often a key part of a young person’s education and social life. When balancing freedom and protection, policymakers don’t always understand how their proposals affect developers or how the open source ecosystem operates.
First, a quick definition: “age assurance” covers a range of methods to determine or estimate a user’s age. It’s sometimes used interchangeably with “age verification,” which typically refers to high-confidence methods like photo ID matching or checks against financial or identity systems. Age assurance also includes self-attestation (users report their own age) and age estimation (age inferred from signals like facial scanning or behavior). These approaches have tradeoffs between accuracy, privacy, security, interoperability, and accessibility, and proposals vary widely in age thresholds, parental consent requirements, and access restrictions.
We won’t dig into every individual approach here, but it’s worth engaging with legislation directly, considering different technical and policy perspectives, and thinking about how to protect young people online while preserving access to learning opportunities, including coding education and participation in the global open source ecosystem.
A poorly designed age assurance law can have major unintended impacts for open source projects. For example, requirements that operating systems centrally collect and manage user data, or restrict users from installing software outside of centralized app stores, conflict with the decentralized, user-controlled norms of the open source ecosystem. Another pitfall is placing age assurance requirements on “publishers” of operating systems, regardless of whether they’re individuals or companies. Open source operating systems are frequently iterated on, reused, and redistributed by individual contributors and small communities with limited resources and small user bases. The same applies to package registries and developer tooling: a volunteer maintaining a small Linux distribution doesn’t have the same capacity to implement age verification as a Fortune 500 tech company.
The diversity of the software ecosystem is worth preserving. GitHub has engaged with governments on age-related online safety proposals for several years. In some cases, including Australia’s Social Media Minimum Age legislation, we worked with policymakers to explain why open source code collaboration platforms should not be in scope. Similar exemptions appear elsewhere: France’s current Social Media Minimum Age proposal includes exclusions for open source code collaboration sites and online encyclopedias, matching language from the EU Copyright Directive.
Many policymakers recognize that access to the open source software development ecosystem delivers significant public benefits, including education, innovation, and security, and that the risks young people face from participating in open source development communities are materially different from consumer-facing platforms. At the same time, a growing number of laws are pushing child safety goals at lower levels of the tech stack, including operating systems and application distribution layers. This raises new questions for developers about how these requirements apply in practice, and whether open source operating systems and developer infrastructure like GitHub could be impacted.
Below are the key pieces of legislation to track:
US State Legislation
- California AB 1043 Digital Age Assurance Act and 2026 amending bill AB 1856: Requires operating system providers (in coordination with covered app stores) to collect self-declared age at account setup and transmit an age-range signal to applications via a real-time API.
- Colorado SB 26-051 Age Attestation on Computing Devices: Requires operating systems and covered app stores to generate and share an age-bracket signal with applications via a real-time interface, with evolving definitions of “covered application” and “covered application store” shaping scope.
- Illinois HB 4140 Digital Age Assurance Act: Applies to operating system providers and requires collection of age data and transmission of an age-category signal to developers via a real-time API, closely mirroring California’s model.
- New York S 8102/A 8893 Device-Level Age Assurance: Applies broadly to device manufacturers, operating systems, and app stores, requiring “commercially reasonable” age assurance (not just self-reporting) at device activation and transmission of a verified age signal to apps and websites.
- Related app store-focused laws have passed in Texas (SB 2420), Louisiana (HB 570), and Utah (SB 142).
These proposals are actively evolving. In Colorado, SB 26-051 had a committee hearing on April 23, 2026, reflecting the complexity of balancing child safety, privacy, and feasibility, with strong engagement from open source developers and organizations. Committee members signaled that the intent is not to bring open source operating systems or developer infrastructure into scope, and the latest amended text clarifies that software installed outside of app stores, including software downloaded from public repositories, is not in scope.
Brazil’s Digital ECA
Brazil’s Digital Statute for Children and Adolescents (Digital ECA), enforceable as of March 2026, applies broadly to digital services “likely to be accessed by children and adolescents” including operating systems, app stores, and platforms. It excludes essential internet functionalities such as open technical protocols and standards. Although the Brazilian National Data Protection Agency (ANPD) has not yet formally clarified whether or how the law applies to free and open source software, its regulatory agenda has initially prioritized “app stores and proprietary operating systems.” Recent draft guidance under public consultation indicates that systems based on collaborative models and free software should not be subject to the same obligations as proprietary services.
Despite this, legal uncertainty has already driven some open source projects to restrict access in Brazil, as volunteer maintainers worry about compliance feasibility for non-commercial, volunteer-driven ecosystems. While the law was primarily designed for commercial actors, key questions about scope remain unresolved. It’s critical for open source developers to participate in the ongoing public consultation to ensure implementation reflects decentralized development models and avoids unintended restrictions on access and innovation.
EU and Other Regions
Australia and France have already included exemptions for open source collaboration platforms in their proposals, as noted earlier. The EU’s approach to age assurance is still evolving, but the EU Cyber Resilience Act set a positive precedent for iterative engagement with open source communities to refine scope.
Why this matters for developers
A key point of confusion in these proposals is the definition of “app store.” While much of the open source community’s concern has focused on risks to open source operating systems, an equally important question is how “application store” and “application” are defined. As drafted, some definitions of “application store” are broad enough to capture developer infrastructure such as code collaboration platforms, package managers, and open source indexing services, simply because they allow users to access or download software.
Making software available for download is not the same as operating a centralized, consumer-facing marketplace that most people would recognize as an app store. It’s also critical to define “application” precisely: downloading software components like source code, libraries, frameworks, models, and utilities is fundamentally different from offering a standalone executable application through a consumer app marketplace. These components are upstream building blocks, not end-user products, and the services that host or index them do not control consumer distribution or presentation in the way traditional app stores do.
Recent amendments and discussions across jurisdictions suggest regulators intend to focus on consumer-facing distribution and services that control end-user access. Clear statutory distinctions are needed to ensure laws align with that intent. This reflects a familiar challenge in technology policymaking: frameworks aimed at youth safety and age assurance typically respond to risks associated with consumer-facing services that collect and monetize user data, distribute content at scale, and rely on engagement-driven systems to shape user behavior.
By contrast, platforms that support collaborative software development serve a fundamentally different function. They are built to help users create, share, and maintain code, not to attract mass audiences, amplify content, or drive passive or excessive consumption, resulting in a materially lower risk profile. Open source communities operating on services like GitHub are organized around shared technical goals and guided by norms of collaboration, reuse, and transparency, which is why these developer-focused services should be distinguished from consumer-facing platforms in regulatory design.
Open source software is also a key driver of economic development and innovation, and functions as critical digital infrastructure. Ensuring that policies accurately reflect how open source is built and maintained is essential to preserving these benefits. When policymakers engage directly with open source developers and civil society, they often refine definitions, clarify scope, and better align laws with technical realities.
Uncertainty around compliance requirements is especially challenging for open source developers, many of whom contribute on a voluntary basis. There are positive examples of this engagement: the EU Cyber Resilience Act was refined through an iterative process to balance requirements for open source, and U.S. state policymakers have shown willingness to engage with the open source community to align proposals with technical feasibility.
How to engage: Actionable steps for developers
The window for constructive engagement is still open, and developer voices make a measurable difference. Here are concrete ways to get involved:
- Contact elected representatives in states considering these proposals, including California, Colorado, Illinois, and New York. Share specific examples of how broad age assurance requirements would impact your work, whether you maintain an open source OS, run a package registry, or contribute to developer tooling.
- Participate in Brazil’s Digital ECA public consultation to advocate for clear exemptions for collaborative open source models.
- Engage with organizations that represent open source interests, including the Open Source Initiative, FreeBSD Foundation, and Debian. These groups track legislation and coordinate community responses.
- Stay informed about upcoming policy discussions. GitHub will continue working with policymakers and the open source community to support balanced approaches that protect young people while preserving open development. Reach out to us with questions or concerns.
We’ll continue this conversation with a Maintainer Month livestream on May 22 featuring panelists from the FreeBSD Foundation and the Open Source Initiative. We’ll discuss the broader issues raised by these proposals and how to design technology policy with open source in mind. You can register for the livestream here.
Tags: maintainers, open source, policy
Related Posts
- News & Insights: How researchers are using GitHub Innovation Graph data to reveal the “digital complexity” of nations — Researchers share how they used GitHub Innovation Graph data to predict GDP, inequality, and emissions in ways that traditional economic data misses, along with our Q4 2025 data release.
- Company News: An update on GitHub availability — Here’s what we’ve done, and what we’re still doing, to improve our availability and reliability.
- Company News: GitHub Copilot is moving to usage-based billing — Starting June 1, your Copilot usage will consume GitHub AI Credits.
We also publish a biweekly newsletter for developers with tips, technical guides, and best practices. Sign up here to get it in your inbox.
Comments
Please log in or register to join the discussion