On August 27, 2026, the California State Legislature finished deliberating AB 1856, a bill that would exempt distributors of open-source operating systems from device-level age-signal obligations. The State Senate passed it 39–0 the day before, on the 26th, and the State Assembly concurred with the Senate's amendments 69–0. However, its official status is a passed bill—it is not yet a law signed by Governor Gavin Newsom. What currently has legal force is AB 1043, whose main obligations take effect on January 1, 2027.
This distinction matters. AB 1856 does not name "Linux" or any specific license; instead, it narrows the scope of who qualifies as an OS provider based on conditions about who distributes what. Meanwhile, obligations for app stores and developers remain intact. Open-source software as a whole does not disappear from the age-verification framework.
The Exemption Is Defined by License Terms, Not by "Linux"
The clause AB 1856 adds is straightforward: it excludes from the definition of "OS provider" any person or entity that distributes an OS or app under license terms that allow recipients to copy, redistribute, and modify it. Neither product names like the Linux kernel or Debian, nor license names like GPL or MIT, appear in the text.
In other words, the criterion for exemption is not a list of products but three rights held by the user. Distributors of community OSes that meet these conditions fall outside the definition of OS provider. This resolves the strain of forcing a system—where users can obtain an ISO image, create their own modified version, and redistribute it—into the same "provider" category as a commercial OS whose accounts and device settings are managed by a single company.
That said, the technical fact of using Linux alone does not determine exemption. For products that bundle proprietary software into an OS image, or where a company manages device accounts and app stores, a separate determination must be made about what role that company plays. The bill's text alone cannot definitively say whether something like SteamOS or Android is automatically exempt or remains subject to the law.
How Do the Four Age-Signal Categories Flow?
AB 1043, enacted on October 13, 2025, established the Digital Age Assurance Act within the California Civil Code. OS providers must have account holders enter the primary user's date of birth, age, or both when setting up a device account. Age signals fall into at least four categories: under 13, 13 to under 16, 16 to under 18, and 18 and over.
Covered app stores request signals from the OS and pass them along at the request of app developers. Developers, too, must request the signal when an app is downloaded to and launched on a device. A developer who receives this signal is deemed, within a specified scope, to actually know the user's age category and may use it to comply with applicable law. However, if there is clear and convincing internal information indicating a different age, that information takes precedence.
The age verification referred to here is not a scheme requiring government-issued ID or facial recognition mandated by the state. The entry point specified in the law text is the input of age or date of birth by the account holder. What is sent to the app is not the date of birth itself, but, per the statutory text, age-category data that does not identify the individual. AB 1856 explicitly states that only the minimum information necessary for compliance should be sent, and that signals should not be requested in situations where they are not required under this or any other law.
The deadlines and liabilities are significant. For devices already set up before January 1, 2027, a screen for entering age information must be provided by July 1 of that same year. For apps updated on or after January 1, 2026, and installed before January 1, 2027, a signal must be requested by July 1, 2027, if it has not already been requested. Civil penalties for violations run up to $2,500 per affected child per violation for negligent violations, and up to $7,500 for willful violations.
Not a Blanket Pardon for Open-Source Apps in General
Summarizing AB 1856's exemption as "open-source software is exempt" erases the boundaries between distinct roles. Comparing the old and new statutory text, the changes break down as follows:
| Role | What AB 1856 Changes | Obligations/Boundaries That Remain |
|---|---|---|
| OS provider | Excludes from the definition any entity distributing an OS or app under terms allowing copying, redistribution, and modification | Non-exempt OS providers must still provide an age-entry screen and real-time API |
| Covered app store | Codifies the role of requesting signals from the OS and passing them to developers | No blanket exemption based on being open source is written into the text |
| App developer | Narrows the definition to those who own an app within a covered store, or who maintain and manage its hosting | Must request the signal upon download and launch, and use it to comply with applicable law |
| Software component | Excludes from the app definition any component not offered as a standalone consumer-facing app within a covered store | If offered as a standalone app, being a "component" does not exempt it |
In other words, this is not a provision that lets you sidestep the entire framework simply by making your code public. AB 1856's open-source clause narrows the definition of OS provider, but it does not blanket-exempt the role-specific obligations of covered app stores and developers who offer apps through those covered stores. Even an entity excluded from being an OS provider will have its role separately evaluated if the same company or organization also operates a covered app store.
AB 1856 also adjusted liability for erroneous signals. An OS, store, or developer that made a good-faith attempt at compliance—given available technology, reasonable technical constraints, or failures—is shielded from liability for erroneous signals. This is not a provision guaranteeing the accuracy of age signals; it is a provision limiting liability for entities that attempted a reasonable implementation.
Why Treat Decentralized OSes Differently?
In May 2026, System76 explained that it worked with the community and stakeholders within the state to adjust the wording, aiming to extend to California an open-source exemption modeled on one it had helped create in Colorado. The company has also stated it will not add age-verification or age-declaration features to Pop!_OS or the COSMIC Desktop Environment.
The pushback centered on more than just the cost of building an age-entry field. Open-source OSes often lack a single point of distribution, a unified account system covering all users, or administrative authority to stop modification. Anyone can copy the software and redistribute a modified version with features removed—yet requiring a specific entity to maintain a real-time age API creates a gap between legal liability and actual capacity for control.
In a joint statement on May 27, 2026, four organizations including the Apereo Foundation and the Open Source Initiative argued that imposing age-information features at the OS level risks squeezing small or volunteer-driven projects, potentially creating an environment where only well-resourced proprietary vendors can participate. AB 1856's license-based criterion is an attempt to translate this decentralized development and distribution model into statutory language.
Three Boundaries That Remain Even After Signing
The first thing to confirm is the governor's decision. Even though AB 1856 has passed the legislature, it will not amend AB 1043 until it is signed. When Governor Newsom signed AB 1043, he cited concerns from video-streaming and gaming businesses about accounts shared by families or profiles used across multiple devices, and called on the legislature to make amendments during 2026. However, that signing statement did not indicate a position for or against an open-source exemption.
Next is the treatment of products with multiple layers. Even if the distribution terms for the Linux kernel or the OS portion meet the exemption, separate roles arise for entities that manage proprietary accounts, commercial stores, or app distribution. How the state Attorney General or the courts will apply the definitions to individual products on a case-by-case basis has not yet been made public.
And there is an implementation question: when age signals do not arrive from an exempted OS, how will covered app stores and developers fulfill their remaining obligations? If AB 1856 is enacted, the Linux community will find it easier to avoid the responsibility of providing a centralized age API. Whether the system actually functions in practice will depend on how stores and developers outside the exempted layer handle the absence of a signal.