The Problem
California’s AB-1043 (effective January 1, 2027), Colorado’s SB26-051, and New York’s S8102A all share a common enforcement mechanism: they require operating system providers to collect age information at setup and transmit it via API to apps and services. Several other states and jurisdictions are moving in the same direction.
The Linux community’s response so far has been largely reactive — objecting to the laws, pointing out they won’t work, and hoping courts strike them down. Those are valid positions. But they are not a solution. Courts move slowly. Legislatures move faster. We need an architectural answer that works regardless of how the legal landscape evolves.
I want to propose one.
The Core Observation
Every one of these laws targets operating systems that connect to the internet. The enforcement mechanism — transmitting an age signal via API — requires network connectivity. Without a network stack, the entire compliance framework has nothing to grab onto.
So the question becomes: what if the base OS ships without one?
The Proposal
Remove all networking code from the Linux kernel base distribution. Make network capability an optional patch that users install separately.
This is not as radical as it sounds. Network interfaces as loadable kernel modules is already how Linux works architecturally. This proposal makes that separation explicit, intentional, and legally meaningful.
Phase 1: Installation
- The base OS ships with zero network stack code. No drivers, no interfaces, no TCP/IP. It is, by definition, an offline operating system.
- During installation, the user is presented with a simple opt-in choice: install the networking patch now, or skip it and remain offline. The default is no networking.
- If the user opts in to networking at install time, the networking patch installs. If the jurisdiction requires age verification for networked OS installs, an age verification patch can install alongside it as a separate component.
- If the user skips networking at install, no age verification is required because the installed OS has no network capability. It does not meet the definition of an internet-connected OS under any of the current laws.
Phase 2: Post-Install
- A user who installed without networking can change their mind at any time. They download the networking patch on another device, transfer it via USB or other local media, and install it manually.
- This works because the manufacturer never shipped a network-connected OS. The user independently chose to add network capability after the fact.
- An age verification patch is made available separately for users in jurisdictions that require it. Users who want it can install it. It is not bundled with the networking patch.
Why This Works Legally
The laws regulate what an OS is, not what it could become.
A laptop is not a database server because MySQL could be installed on it. A car is not a taxi because Uber could be installed on it. Capability is not function. Potential is not actuality.
A kernel shipped without network code is an offline OS at the point of distribution. That is what the manufacturer shipped. That is what the law sees. What a user chooses to install afterward — on their own hardware, with software they obtained independently — is the user’s decision and the user’s responsibility.
The manufacturer’s compliance obligation attaches to what they distribute. They distributed an offline OS. The legal obligation for the network-connected state belongs to the user who created that state, not the manufacturer who shipped hardware and software that was not in that state.
An attorney would need to confirm the specifics against each jurisdiction’s exact statutory language. But the structural argument is sound: you cannot regulate a device for what it might become after a user modifies it. If you could, every computer would qualify as an internet-enabled device under New York’s proposed language, because every computer could have a NIC installed. That interpretation collapses its own regulatory intent.
The Opt-In Checkbox Is Not the Key
One might argue that offering a networking opt-in at install still implicates the OS provider in enabling connectivity. This may or may not hold up legally depending on jurisdiction — it is a question worth putting to attorneys.
But the more important point is Phase 2: the user installs networking after the fact, on a device that shipped offline, using a patch they obtained and installed themselves. In that scenario, the manufacturer shipped an offline OS. Full stop.
The opt-in at install is a convenience. Phase 2 is the architectural foundation.
What This Is Not
This is not a way to help minors evade age verification. A user who wants to be verified can install the age verification patch. It is available. The proposal does not remove that option — it just makes it opt-in rather than mandatory for users who have no use for it.
This is not an argument that these laws are good policy. They are not. They are unenforceable, technically naive, and create surveillance infrastructure that will be abused for purposes beyond their stated intent. But those arguments belong in courtrooms and legislatures. This proposal is for the engineering community that needs to keep Linux free while those fights play out.
The Immediate Ask
This proposal needs legal review against the specific statutory language of AB-1043, SB26-051, S8102A, and equivalent laws in other jurisdictions. It needs kernel developers to evaluate the feasibility and implications of the architectural separation. And it needs the broader community to stress-test the argument before the January 2027 deadline in California makes the question urgent.
The window to get ahead of this is now. Reactive compliance after the fact will look very different from a proactive architectural decision made on principle.
If anyone is already working on this or has legal analysis to share, I would like to hear it.
