⏱️ Lectura: 10 min
The California Senate unanimously approved, 39 votes to 0, exempting Linux and all open source software from the state’s digital age verification law. The vote took place on August 26, 2026, and the Assembly ratified the changes a day later.
📑 En este artículo
The bill, identified as AB 1856, now sits with Governor Gavin Newsom. The decision closes nearly a year of uncertainty over whether distributions like Debian, Fedora, or Arch would have to ask every user for their age, the way Windows, macOS, iOS, and Android already must under the same rule.
TL;DR
- The California Senate passed AB 1856 on August 26, 2026, by 39 votes to 0.
- The Assembly ratified the amendment on August 27, 2026, and the bill moved to Governor Gavin Newsom.
- The original Digital Age Assurance Act, signed by Newsom in October 2025, takes effect January 1, 2027.
- AB 1856 excludes from the term ‘operating system provider’ any software licensed under GPL, MIT, BSD, or Apache.
- Debian, Fedora, Ubuntu, Arch, and the BSD family fall outside the law’s scope under that licensing criterion.
- A second provision exempts components distributed through package managers like apt and pacman.
- The amendment removes the original definition of ‘user,’ which classified every device owner as a minor.
- A third change excludes browser extension stores from the law’s scope.
What happened with AB 1856
AB 1856 doesn’t create a new law: it amends the Digital Age Assurance Act to redefine who counts as an ‘operating system provider.’ The amended text excludes any person or entity that distributes an operating system or application ‘under license terms that allow the recipient to copy, redistribute, and modify the software.’
That technical criterion, taken almost verbatim from the classic definition of free software, matches the four most widely used licenses in the ecosystem: GPL, MIT, BSD, and Apache. Any project licensed under one of them satisfies the test and falls outside the law’s scope.
In practice, that removes Debian, Fedora, Ubuntu, Arch, and the entire BSD family from regulatory radar. Until now they sat in a gray area: the original law never named them specifically, but it never explicitly excluded them either.
Context and history of the Digital Age Assurance Act
Newsom signed the Digital Age Assurance Act in October 2025. The law takes effect January 1, 2027, and requires operating system providers to collect an age signal during account setup, then pass it along to app stores and developers.
Windows, macOS, iOS, and Android fit that definition without much debate: each has a single provider controlling the account setup process. Linux doesn’t work that way. There’s no single entity behind ‘Linux’: there are hundreds of distributions maintained by foundations, companies, and volunteers, and many don’t even require creating an account to install.
That ambiguity fueled nearly a year of concrete doubts: would every distribution have to build an age verification screen into its installer? And what about SteamOS, the Linux-based operating system that runs on Valve’s Steam Deck? The law’s original text named that exact case as part of the uncertainty the amendment sought to resolve.
Technical details of AB 1856
AB 1856 isn’t limited to the licensing exemption. It adds two more carve-outs to the law’s scope and fixes a drafting error that had gone unnoticed for months.
The second carve-out touches the definition of ‘application.’ The law excludes from that category any component that isn’t offered to consumers ‘as a standalone executable application through a covered app store.’ That removes libraries and dependencies installed through package managers like apt or pacman from the law’s scope.
The logic is simple: a store’s main obligation under the law is to request an age signal from the operating system provider and pass it to the developer. An open, exempt operating system doesn’t produce that signal, so there’s nothing for stores to forward.
The third carve-out excludes stores that distribute extensions or add-ons that run exclusively within another host application, which leaves browser extension stores outside the law’s scope.
💭 Key point: the legal test doesn’t ask whether software ‘is open source’ in the abstract, but whether its license allows copying, redistributing, and modifying it. It’s an objective, verifiable test, not a marketing label.
The oddest detail is a different one. The law’s original version defined ‘user’ as ‘a minor who is the primary user of a device.’ The law’s signaling framework depends on adults declaring their age when setting up an account, so the device gets flagged as belonging to someone over 18. But under that original definition, no one could be flagged as an adult: every device owner in California technically qualified as a minor.
⚠️ Heads up: the error wasn’t cosmetic. Under the original text, any system implementing the law to the letter would have had to treat every user, without exception, as a minor.
AB 1856 removes that broken definition. It also adds a new restriction barring anyone from requesting an age signal from an operating system provider or app store outside the cases the law itself requires, closing the door on age-data requests outside the regulated framework.
| Category | Scope before AB 1856 | Scope after AB 1856 |
|---|---|---|
| Windows, macOS, iOS, Android | Covered, no change | Covered, no change |
| Debian, Fedora, Ubuntu, Arch, BSD | Ambiguous, no explicit exemption | Exempt under GPL/MIT/BSD/Apache licensing |
| SteamOS | Cited as a case of uncertainty | Exempt to the extent the licensing criterion applies |
| Packages via apt or pacman | Gray area under the ‘application’ definition | Excluded as they aren’t standalone apps in a covered store |
| Browser extension stores | Not explicitly addressed | Excluded from the law’s scope |
flowchart TD
A["Software distributed in California"] --> B{"Does the license allow copying, redistributing, and modifying?"}
B -->|"Yes: GPL, MIT, BSD, or Apache"| C["Exempt as an operating system provider"]
B -->|"No"| D{"Is it distributed as a standalone app in a covered store?"}
D -->|"No, via apt or pacman"| E["Exempt as an application"]
D -->|"Yes"| F["Subject to AB 1856"]How to check if your project would qualify
If you maintain a project distributed in California and want to know whether it would fall under the AB 1856 exemption, the first step is confirming the exact license, not just assuming it ‘is open source.’
curl -s https://api.github.com/repos/torvalds/linux | jq -r '.license.spdx_id'
# Expected output: GPL-2.0That command queries the GitHub API and returns the repository’s SPDX license identifier. If the result is GPL-2.0, MIT, BSD-3-Clause, or Apache-2.0, the project meets the first exemption criterion.
To audit several dependencies at once, for example if you maintain a distribution or a product that bundles third-party software, a simple script can loop through the list and filter for permissive licenses:
#!/usr/bin/env bash
# audit-licenses.sh: checks whether each package uses a license recognized by AB 1856
for pkg in $(cat package-list.txt); do
license=$(npm view "$pkg" license 2>/dev/null)
echo "$pkg: $license"
done | grep -E "MIT|BSD|Apache-2.0|GPL"This script uses npm view to read the license field from each package’s published package.json and filters for matches against the recognized licenses. For Python packages, the equivalent is pip show <package> | grep License; for a local repository, checking the LICENSE file at the root is enough.
The second criterion, distribution through a package manager, doesn’t depend on the license but on the channel. A proprietary library distributed only via apt or pacman, with no standalone executable in a covered store, could also fall outside the law’s scope this way, though it’s worth checking the final signed text before treating that as a legal guarantee.
Impact and analysis
The AB 1856 case matters beyond California. The state typically sets the regulatory pace for the rest of the United States, and several state legislatures have been advancing age verification laws focused on social media and adult content.
What’s different here is the level at which the obligation was applied: not to a single app, but to the entire operating system. Extending that logic to Linux without the exemption would have meant, in practice, asking every volunteer-maintained distribution to implement an age verification mechanism, something without precedent in the open development model.
The amendment also sets an interesting legal precedent: it uses the functional definition of free software (a license that allows copying, redistributing, and modifying) as an objective test within a consumer law, rather than a self-declared label from the project. It’s a criterion other states might copy if they draft similar laws.
What’s next
The bill now sits with Governor Newsom, who had already signed the original Digital Age Assurance Act in October 2025. The unanimous vote in both chambers suggests signing the amendment is the most likely outcome, though the process is formally not yet closed.
The original law takes effect January 1, 2027, leaving room for the signature to happen before that date. If for some reason AB 1856 isn’t signed in time, Linux and SteamOS would fall back into the same gray area that fueled nearly a year of debate.
📖 Summary on Telegram: View summary
Try it yourself: run curl -s https://api.github.com/repos/torvalds/linux | jq -r '.license.spdx_id' on your own project and confirm in two seconds whether your license would qualify for an exemption like the one in AB 1856.
Frequently Asked Questions
What is AB 1856?
It’s an amendment passed by the California legislature that excludes software distributed under GPL, MIT, BSD, or Apache licenses from the definition of ‘operating system provider’ within the Digital Age Assurance Act.
What is the Digital Age Assurance Act?
It’s the California law, signed by Newsom in October 2025, that requires operating system providers to collect an age signal during account setup and share it with app stores and developers starting January 1, 2027.
Which licenses qualify for the exemption?
GPL, MIT, BSD, and Apache, since they allow copying, redistributing, and modifying the software freely. Any project under those licenses satisfies the legal criterion.
Does the package manager exemption depend on the license?
Not necessarily. That carve-out is based on the distribution channel: if the software isn’t offered as a standalone executable application in a covered store, as is the case with packages installed via apt or pacman, it falls outside the law’s definition of ‘application.’
Is SteamOS exempt?
The law’s original text cited SteamOS as part of the uncertainty that motivated the amendment. Under AB 1856, it would be exempt to the extent its components satisfy the licensing or distribution criterion.
When does the law take effect?
The Digital Age Assurance Act takes effect January 1, 2027. AB 1856 is still awaiting Governor Newsom’s signature.
References
- Tom’s Hardware: original coverage of AB 1856’s passage and the amendment’s text.
- California Legislative Information: official portal for tracking the status and text of bills like AB 1856.
- GNU General Public License: full text of the GPL license, one of the four recognized by the exemption.
- Open Source Initiative: list of approved licenses, including MIT, BSD, and Apache 2.0.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
Imagen destacada: Foto de Zac Nielson en Unsplash
0 Comments