California and Colorado are moving to keep Linux distributions and similar open-source projects out of their new operating-system age-verification regimes. That is the important part: the exemptions were not there at first.
Both states started with bills that treated operating system providers as part of the age-assurance stack. In practice, that could have pulled community-run Linux distributions into a compliance model built around account setup, app stores, and real-time age signals to applications. That model fits large consumer platforms far better than it fits a volunteer-maintained distro mirror.
The newer language narrows the blast radius. California’s fix is still moving through the legislature. Colorado’s has already been added to its bill, with broader and more explicit protection for open-source software, code repositories, and container platforms.
What changed in California#
California’s Digital Age Assurance Act, AB 1043, was signed in October 2025. The original language did not make a clear exception for open-source operating systems.
That omission mattered. The bill required covered operating system providers to collect a user’s age or birth date during account setup and expose age-related information to apps through a real-time API. For commercial mobile and desktop platforms, that is a heavy but legible mandate. For Linux distributions, the fit is poor. Many do not control user identity in the same way. Many do not operate a centralized app store. Some are built and redistributed by communities that cannot realistically run an age-verification compliance program.
Assemblymember Buffy Wicks, the author of AB 1043, introduced follow-up legislation in February to address the issue. After several rounds of revision, the California language now rewrites the definition of an “operating system provider” to exclude distributors of operating systems under terms that allow recipients to copy, redistribute, and modify the software.
That should cover most Linux distributions under permissive or copyleft licenses. The source does not list every affected license, and it would be wrong to treat this as a universal exemption for anything that calls itself open source. But the policy direction is clear: software freedom terms are being used as the line between covered platform operators and open distribution projects.
California also adjusted the application side. Software that is not offered as a standalone executable through a covered app store is no longer treated the same way under the bill’s app-related provisions. That matters because open-source software often reaches users through repositories, package managers, source builds, or direct distribution rather than a platform-controlled consumer app store.
The California fix is not final yet. According to the source, the amended bill passed committee 11-0 on May 14, was ordered to third reading on May 19, and is awaiting an Assembly vote. That is progress, not enactment.
Colorado went further#
Colorado’s SB26-051 appears to have taken a more explicit route.
The source credits direct community work by System76 founder Carl Richell with Senator Matt Ball, one of the bill’s co-authors, to get open-source exclusions written into the bill. That detail matters because it shows the exemption did not emerge from abstract legislative caution. It took someone close to the Linux ecosystem explaining where the bill would break.
Colorado now exempts operating system providers and developers who distribute software under terms that permit copying, redistribution, and modification. It also adds an extra condition: exempt software must not have platform-imposed technical or contractual restrictions that block users from installing modified versions.
That clause is more than decorative. It tries to separate real software freedom from source-available branding. If a vendor publishes code but locks hardware or platform policy so modified versions cannot run, Colorado’s language is designed not to reward that as open-source distribution. The source frames this as aimed at cases where manufacturers make source code available while still blocking modified software on the actual device.
Colorado also names several categories directly. Code repository providers, containerized software distributions, and applications from free, publicly available code repositories are excluded. That is a cleaner signal to developer infrastructure than a narrow Linux-only carve-out would be.
The bill’s general scope is also narrower than California’s original framing. It applies to operating system providers that operate a covered app store or ship one pre-installed. An OS provider with no app store involvement does not come into scope at all, according to the source.
That distinction is practical. The age-verification logic is tied to app distribution and platform mediation. If a project is not operating that mediation layer, forcing it into the compliance chain would create paperwork without clear child-safety gain.
Why the exemption matters#
The policy problem is not that Linux should get special cultural treatment. The problem is that age-verification mandates often assume a centralized platform operator.
Linux distributions do not always have that shape. A distro may provide packages, repositories, installers, documentation, and community infrastructure without controlling the user’s account identity or the downstream application environment. A fork may redistribute the same software under the same license. A user may modify and rebuild the system. A company may ship Linux on hardware, while a community project maintains an independent version.
A law that says “OS provider” without handling those distinctions can misfire. It can make a small project legally responsible for a trust signal it cannot collect, verify, or transmit. Worse, it can pressure open software into adopting centralized account and app-store patterns just to survive compliance.
The Colorado language is notable because it treats distribution freedom and installation freedom together. That is the stronger model. Open code matters less if the platform still blocks modified versions from running. A source repository alone is not the same thing as a user-controllable system.
California’s language, at least as described, is narrower but still important. It moves the state away from treating open-source OS distribution as equivalent to a major commercial platform with account onboarding and app-store control.
What not to overclaim#
This is not a defeat of age verification as a policy category. California and Colorado are not abandoning their broader age-assurance plans. They are adjusting who must comply.
It is also not a blanket immunity shield for every company using Linux or open-source components. If a vendor operates a covered app store, ships one pre-installed, imposes platform controls, or distributes software through a regulated consumer channel, the facts will matter. The source material does not give enough detail to map every edge case.
Nor is California finished. Its open-source fix has advanced, but the source describes it as awaiting an Assembly vote. Until final passage and implementation, projects should treat the exemption as a live legislative development rather than settled law.
Colorado is further along in the source’s account. It has added explicit exclusions for repositories, container distributions, and apps from free public code repositories. Those details are useful because modern software distribution is not just “download an app.” It is Git repositories, package registries, containers, forks, and downstream rebuilds.
What open-source projects should check#
Projects affected by state age-verification laws should look at three points before assuming they are outside scope.
First, check the license and distribution terms. The carve-outs described here depend on rights to copy, redistribute, and modify. A source-available license with restrictions may not qualify.
Second, check platform control. Colorado’s language cares whether modified versions can actually be installed, not only whether source code is visible. Hardware locks, contractual limits, or app-store gatekeeping can change the analysis.
Third, check app-store involvement. The Colorado bill, as described, applies to OS providers that operate a covered app store or ship one pre-installed. That is a different risk profile from a community distro that provides repositories but does not run a consumer app store in the statutory sense.
The larger lesson is simple: open-source projects cannot rely on lawmakers to discover these differences on their own. In both California and Colorado, the exemptions arrived after pressure and direct outreach. The first drafts missed the issue. The later drafts started to recognize the software supply chain that actually exists.