California’s Digital Age Assurance Act (AB 1043), approved by Governor Newsom in October 2025, sets out a statewide age assurance framework for operating systems and app stores. It requires operating system providers to present an age and date-of-birth declaration interface during account setup and to provide an API that can return an age bracket signal to applications that request it. The statutory effective date is January 1, 2027, with additional timelines for devices already in the field.

As someone who tracks the intersection of intellectual property law and Open Source, I find it striking that the Open Source community has not produced much public analysis of how AB 1043 could collide with decentralized software distribution. Some civil liberties organizations have raised general concerns about age assurance mandates, but the specific consequences for Linux distributions, package repositories, and volunteer-maintained tooling remain under-discussed.

This is not merely a missed opportunity. It is a structural gap that may have lasting consequences for Open Source ecosystems.

  1. How Platform Politics Can Hide Open Source Risk
  2. What the Statute Actually Says
    1. A Possible Limiting Construction
  3. The Committee Noted Overbreadth, but No One Spoke for Open Source
  4. Enforcement Is Hard, but the Chilling Effect Is Real
  5. Constitutional and Structural Questions Remain Open
  6. The Window for Fixes Is Tight Unless the Community Acts
  7. Sources

How Platform Politics Can Hide Open Source Risk

AB 1043 moved unusually smoothly through California’s legislature. The recorded floor votes were unanimous at multiple stages, including 76 to 0 in the Assembly (Third Reading, June 2, 2025), 38 to 0 in the Senate (September 12, 2025), and 77 to 0 in the Assembly (Concurrence, September 13, 2025).

A key reason is that the bill largely assigns compliance to the application layer. Operating system providers and covered application stores are directed to provide an interface and an age bracket signal, and the statute offers liability protections for good-faith efforts. Developers, meanwhile, face obligations to request signals when an application is downloaded and launched, and to treat the signal as a gating input for access.

That structure reduces direct liability pressure on the largest platform operators. It also changes the political dynamic that often surfaces Open Source concerns. When the main debate is framed around app stores and commercial child safety policy, the downstream impact on Open Source distribution can get missed.

Press coverage around AB 1043 included positive reactions from major platforms. For example, Google characterized the bill as a thoughtful approach to child safety. Even if those commercial actors were not the primary registered supporters in early committee analyses, the overall legislative trajectory was not shaped by a visible Open Source-focused constituency.

What the Statute Actually Says

The problems begin with the statutory definition of “application” in Section 1798.500(c):

“Application” means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.

The critical ambiguity lies in the relative clause “that can access a covered application store or download an application.” If it modifies “general-purpose computing device,” the nearest antecedent and the most natural grammatical reading, then any software running on a device capable of accessing a covered application store could fall within the definition. On a Linux system with “apt“, “flatpak“, or “snap” installed, that potentially includes a vast portion of the system, including command-line utilities such as “ls” and “grep“.

This is not merely academic. Section 1798.501(b)(1) imposes a mandatory obligation on developers:

A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.

If “application” is read broadly, and “launched” is interpreted to include ordinary execution, then a maintainer of a small command-line tool could be framed as a “developer” obligated to integrate age assurance signal requests. The absurdity is obvious, but the enacted text does not clearly foreclose the reading.

A Possible Limiting Construction

There is a narrower interpretation available. Section 1798.501(a)(1) ties the operating system provider’s obligation to providing age bracket signals for applications available in a covered application store. A “covered application store” is defined as “a publicly available website, software application, online service, or platform that distributes and facilitates the download of applications from third party developers.”

Under this construction, only applications distributed through a “covered application store” would be in scope. Software installed outside such a store, for example compiled from source, might fall outside the law’s reach.

But this interpretation raises its own unresolved questions. Does “apt” constitute a “covered application store”? It is a publicly available software application that distributes and facilitates the download of applications from third party developers. Similar arguments could be made for Flatpak, Snap, the Arch User Repository, and even some ecosystem package managers such as “pip” or “npm”, depending on how “store” and “facilitates” are interpreted.

The statute provides little guidance on where that line should be drawn, and there is not yet a developed body of case law on AB 1043.

The Committee Noted Overbreadth, but No One Spoke for Open Source

The Assembly Committee on Privacy and Consumer Protection’s analysis of AB 1043, prepared for the April 22, 2025 hearing, explicitly flagged an overbreadth risk. The committee recommended that the author consider:

Narrowing the types of applications. As the opposition noted, the current definition of “application” includes every application and computer program, including those that have no discernible harmful impact. The current definition in the bill would include functional applications such as calendars, to-do-lists, simple games, keyboards, clocks, maps, and weather apps. The author may wish to specifically define which types of applications, computer programs, and websites the bill is intended to cover.

The committee also recommended defining “device” more precisely, noting that the language could extend beyond smartphones and tablets to televisions, gaming consoles, fitness devices, and other household items.

These are exactly the kinds of definitional issues that Open Source advocates would likely expand upon. If calendars and weather apps are called out as a problem case, what about the thousands of packages in a typical Linux distribution? What about server software? What about developer tooling? What about the kernel and core userland utilities that are prerequisites for everything else?

The registered supporters and opponents listed in the committee analysis do not include major Open Source advocacy organizations. The overbreadth risk was visible in the legislative materials, but the Open Source distribution model and its unique constraints do not appear to have been pressed as a distinct constituency issue.

Enforcement Is Hard, but the Chilling Effect Is Real

The practical difficulty of enforcing AB 1043 against global Open Source projects does not eliminate legal risk. There is a structural mismatch:

No central authority: Many Linux distributions have no mandatory account infrastructure. Users can download images from mirrors worldwide, install offline, and modify code or packages. That makes it unclear who could implement the “accessible interface at account setup” requirement in a way that maps to typical Open Source distribution.

Global development, local regulation: Linux distributions and package ecosystems are maintained by contributors across the world. Jurisdiction and service of process are nontrivial, but the legal uncertainty can still deter participation and distribution.

Disproportionate penalties: AB 1043 provides for civil penalties up to $2,500 per affected child for negligent violations and $7,500 for intentional violations, with additional enforcement mechanisms in the statute. For volunteer-run projects with no revenue, even a single enforcement action could be existential.

Tension with Open Source licensing: Geographic usage restrictions conflict with the Open Source Definition. Clause 5 prohibits discrimination against persons or groups, and Clause 6 prohibits discrimination against fields of endeavor. If a project reacts to AB 1043 by excluding California residents, that license is not Open Source under OSI criteria.

In early 2026, MidnightBSD publicly stated that it planned to exclude California residents from desktop use beginning January 1, 2027, as a risk mitigation step. Even if such reactions remain rare, the fact that projects are considering geography-based exclusions is a warning sign.

Constitutional and Structural Questions Remain Open

AB 1043 is framed as technical infrastructure: an age bracket signal returned by operating systems and covered application stores, rather than content moderation mandates. That design may reduce exposure to some of the constitutional arguments that have been raised against other state age gating schemes.

For Open Source software, compelled speech arguments can still surface. Requiring developers to integrate age assurance signal requests or gating logic into code can be framed as compelled expression, especially given precedent recognizing source code as protected speech. Whether courts would treat an infrastructure mandate the same way as a content mandate is an open question.

The Dormant Commerce Clause is another pressure point. AB 1043 can be read as pushing global software projects to change behavior to satisfy a single state’s regulatory preferences, even when distribution is decentralized and not designed around state-level identity gates.

It is entirely possible that the legislature did not intend to regulate global Open Source development. The legislative record shows a focus on commercial app ecosystems. But intent does not itself narrow enacted statutory language, and ambiguous definitions can create real litigation and compliance risk.

The Window for Fixes Is Tight Unless the Community Acts

The law takes effect on January 1, 2027. For existing devices, operating system providers generally have until July 1, 2027 to implement required user interface changes. In his signing message, Governor Newsom explicitly called for follow-up work in the 2026 session to address identified issues and reduce unintended impacts.

Some sectors have professional lobbying capacity. Volunteer maintained Open Source projects usually do not.

I have not found public materials that focus specifically on AB 1043’s interaction with decentralized Open Source distribution from several major Open Source organizations, including OSI, the Free Software Foundation, the Software Freedom Conservancy, and the Linux Foundation. The Electronic Frontier Foundation has discussed broader age assurance and surveillance concerns, but focused Open Source distribution analysis appears limited.

If any of these organizations have issued detailed AB 1043 focused analysis on Linux distributions, package managers, and volunteer-maintained software, I welcome correction. What I can confirm is that the committee analysis for AB 1043 lists no Open Source organization among the registered supporters or opponents, even while highlighting definitional overbreadth.

This should change quickly. The Open Source community needs to engage with California lawmakers to draft amendments that clearly exclude community maintained Open Source software that is distributed outside the commercial app store ecosystem, and to tighten definitions so that core operating system components and general-purpose package ecosystems are not swept in by accident.

The committee that reviewed the bill saw the definitional problem. The Open Source ecosystem has not yet, in public, explained why that problem is existential for decentralized distribution. The window for meaningful legislative correction is narrowing.

Sources

AB 1043 bill text: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB1043
AB 1043 vote history: https://leginfo.legislature.ca.gov/faces/billVotesClient.xhtml?bill_id=202520260AB1043
Committee Analysis, ASSEMBLY COMMITTEE ON PRIVACY AND CONSUMER PROTECTION: https://apcp.assembly.ca.gov/system/files/2025-04/ab-1043-wicks-apcp-analysis.pdf
Signing message PDF: https://www.gov.ca.gov/wp-content/uploads/2025/10/AB-1043-Signing-Message.pdf
California’s age verification bill for app stores and operating systems takes another step forward, Engadget: https://www.engadget.com/big-tech/californias-age-verification-bill-for-app-stores-and-operating-systems-takes-another-step-forward-214339759.html
The Year States Chose Surveillance Over Safety: 2025 in Review, EFF: https://www.eff.org/deeplinks/2025/12/year-states-chose-surveillance-over-safety-2025-review

Tracing Creative Commons Licenses Across AI: Training Data, Models, Outputs

Copyright issues in AI model training and generated outputs are widely discussed, but less attention is paid to how copyright licenses, the actual mechanism for granting permission, shape these workflows. Unlike traditional software, which is often described as a one-to-one relationship between source code and executable code, AI involves three interlocking layers: input data, the…

The Hidden Risks of NVIDIA’s Open Model License

Recently, regarding the open-weights AI model “Nemotron 3” released by NVIDIA, there are scattered media reports mistakenly describing it as open source. Because there is concern that these reports encourage ignoring the usage risks of the NVIDIA Open Model License Agreement (version dated October 24, 2025; hereinafter referred to as the NVIDIA License), which is…

The Current State of the Theory that GPL Propagates to AI Models Trained on GPL Code

When GitHub Copilot was launched in 2021, the fact that its training data included a vast amount of Open Source code publicly available on GitHub attracted significant attention, sparking lively debates regarding licensing. While there were issues concerning conditions such as attribution required by most licenses, there was a particularly high volume of discourse suggesting…

The Legal Hack: Why U.S. Law Sees Open Source as “Permission,” Not a Contract

In Japan, the common view is to treat an Open Source license as a license agreement, or a contract. This is also the case in the EU. However, in the United States—the origin point for almost every aspect of Open Source—an Open Source license has long been considered not a contract, but a “unilateral permission”…

Evaluating OpenMDW: A Revolution for Open AI, or a License to Openwash?

Although the number of AI models distributed under Open Source licenses is increasing, it can be said that AI systems in which all related components, including training data, are open are still in a developmental stage, even as a few promising systems have emerged. In this context, this past May, the Linux Foundation, in collaboration…

A Curious Phenomenon with Gemma Model Outputs and License Propagation

While examining the licensing details of Google’s Gemma model, I noticed a potentially puzzling phenomenon: you can freely assign a license to the model’s outputs, yet depending on how those outputs are used, the original Terms of Use might suddenly propagate to the resulting work. Outputs vs. Model Derivatives The Gemma Terms of Use distinguish…

Should ‘Open Source AI’ Mean Exposing All Training Data?

DeepSeek has had a major global impact. This appears to stem not only from the emergence of a new force in China that threatens the dominance of major U.S. AI vendors, but also from the fact that the AI model itself is being distributed under the MIT License, which is an Open Source license. Nevertheless,…

Significant Risks in Using AI Models Governed by the Llama License

Although it has already been explained that the Llama model and the Llama License (Llama Community License Agreement) do not, in any sense, qualify as Open Source, it bears noting that the Llama License contains several additional issues. While not directly relevant to whether it meets Open Source criteria, these provisions may nonetheless cause the…