If you maintain a Linux distro or an open source application and you have been worried about California’s age verification law, there is good news from Sacramento that does not always make the headline. A recent amendment carved out most open source projects from the rule that would have forced installers to ask for birth dates. The exemption is short, it is written in plain English, and it is starting to look like a template other states will copy.
This article is for distro maintainers, open source app developers, and anyone who wants to understand what just changed and what it means for projects shipping today.
What the law originally required
California’s age assurance act was signed in October 2025 and takes effect on January 1, 2027. The basic rule is that an operating system vendor has to ask for the user’s date of birth during setup and pass an age band label to app stores and developers who need one. For phones and consoles, where the vendor controls setup and runs the account system, this is mostly a software update. For Linux distributions, where there is no single setup moment and no central account system, the requirement would have forced a fundamental rebuild of the install experience.
A two-person distro project with a GitHub repo would suddenly be expected to run an age verification pipeline. That was the threat as written.
What the amendment actually changed
The October 2025 amendment did not soften the underlying requirement. It narrowed the definition of who counts as an operating system provider. Under the new wording, anyone who distributes an operating system or application under license terms granting the recipient the right to copy, modify, and redistribute the software is exempt. That is the standard open source license test phrased in plain language.
Three things matter about this wording:
- Mainstream Linux distributions qualify because the licenses they ship under (GPL, MIT, BSD, Apache, the rest of the standard catalog) all grant those rights.
- Most open source applications qualify for the same reason: the same test applies to application distribution.
- Android does not qualify, even though its kernel is Linux. Android is shipped primarily as a proprietary product by Google and original equipment manufacturers. The license test fails. That carve-out does not extend here.
That last point was the surprise for me when I read the bill text. A lot of energy in the Linux community went into worrying about phones, and the carve-out does nothing for the world’s most popular Linux-based mobile platform. ChromeOS sits in the same gap.
Why two states landing on the same language is the bigger story
Earlier in 2026, System76 CEO Carl Richell pushed Colorado lawmakers to exempt open source operating systems, open source applications, code hosts like GitHub and GitLab, and tools like Docker, Podman, and other container runtimes. Colorado’s language excludes any software whose license grants the recipient the right to copy, modify, and redistribute it. California’s recent amendment uses essentially identical wording.
Two large states landing on effectively the same exemption within a few months is a pattern. Other states writing their own age assurance laws are likely to adopt similar language, because the test fits in a paragraph, the wording describes a class of software instead of naming specific projects, and it maps onto a legal definition of “open source” that lawyers already understand.
For maintainers, the practical test is now easy to remember. If the license you ship under grants recipients the right to copy, modify, and redistribute the software, you are almost certainly covered by every bill that uses the Colorado-California template.
What changes for everyday Linux users
If you run Ubuntu, Fedora, Linux Mint, Pop!_OS, or any distro in the long tail of community-maintained projects, the practical impact is mostly that nothing changes. Your install process will not suddenly request your date of birth. Linux app stores will not be required to age-gate downloads.
A few edges worth knowing about:
- Chromebook users with Linux apps enabled are still on ChromeOS, which falls outside this exemption. Google handles ChromeOS age signals on its own.
- People dual-booting Linux alongside Windows or macOS will see age checks on the proprietary side regardless of what is happening on the Linux partition.
- Closed-source applications distributed through Linux package repos occupy a gray area. The protection covers the open source application itself, but a paid closed-source binary sold through a Linux storefront might still need to comply. Talk to a lawyer if that is your business model.
- Flatpak and snap distribution adds another wrinkle. The storefront (Flathub or the Snap Store) is the entity the bill talks to, and the storefront’s license for the package itself does not always match the upstream project’s license. Check what the storefront actually ships before assuming the exemption follows.
Trade-offs the bill does not solve
The carve-out is good news. Good news still has costs worth naming.
Borderline projects will produce lawsuits. A custom license that allows modification but requires attribution is probably fine. A “source available” license that lets you read the code but forbids redistribution is probably not. The line follows the Open Source Initiative’s definition of open source, and not every lawyer in every state will read that line the same way on day one.
State law is not federal law. A future federal age assurance bill could pre-empt (override) state carve-outs. If you maintain a long-lived project, plan for the assumption that the legal landscape will shift again, because it almost certainly will.
The user side has no signal. The bill still expects app stores and developers to receive an age range from somewhere. For Linux, “somewhere” is now nobody. App stores that integrate with Linux distros will need a fallback for users who never produced a signal. Most will default to “adult” for the Linux path, but that default is not in the bill text and could be challenged in court.
A short history of how this exemption got written
The shape of this fix did not come out of nowhere. The conversation in California started when the original Digital Age Assurance Act was first written up in early 2025, and open source maintainers realized the bill’s definition of “operating system provider” was broad enough to pull in distro projects that had never operated any kind of identity service. Letters from the Software Freedom Conservancy, the Linux Foundation, and a handful of distro leads reached the legislature over the summer.
By the time the bill was signed, the language still had not been narrowed, which is why the October 2025 amendment became necessary. Colorado went through a parallel process a few months later. System76’s outreach there produced the first version of what is now the shared template, and California’s drafters borrowed the same test rather than reinventing it.
That borrowing is the most interesting part of the story for anyone who watches how policy travels. It means future state bills are likely to follow the same blueprint: define the exemption by license behavior rather than by a list of approved projects. That approach survives forks, rebrands, and acquisitions, which is exactly what an evergreen software definition needs to do.
What to do this week as a maintainer
The interesting story is not that open source won a fight. It is that two states converged on effectively identical legal wording for what counts as open source, which is what makes the wording starting to look like a template for the rest of the country. Track your own state’s age verification bills with the same attention you give kernel release notes. The exact phrasing matters far more than the headline.
If you maintain a project, the practical checklist is short: confirm your license grants the rights the bill cares about, document that fact in your README, and you are almost certainly covered by every bill that uses the Colorado-California template. If your license does not grant those rights, you have a longer conversation ahead, and it should probably happen with a lawyer in the loop.