How is Linux going to do this? There’s no server for the os to send the information to report the age of its users, no way of forcing its user base to comply and no single person or entity to fine, arrest or otherwise force into compliance.
It’s just software that’s freely available. There’s no one corporate entity that controls Linux. Anybody can literally make a distro for it make notation for it illegal for California and be done with it.
But they can fine every single developer of every single application. Sure, a lot of people won’t be in the jurisdiction of the state of California, but there are a hell of a lot of developers who are.
Linux is not a company. There is no CEO of Linux sitting in Sacramento waiting for instructions. It is a decentralized, global, open source ecosystem. If one U.S.-based distro tried to bolt on age verification, someone would fork it almost immediately and strip it out.
You cannot age gate software that people can freely download, modify, compile, and redistribute.
From a technical standpoint, what would this even look like? Government ID verification at the kernel level? A biometric scan before you can run apt update? A centralized identity server for Arch users? That runs directly against how Linux is designed. The ecosystem prioritizes privacy, user control, and minimal centralized telemetry. Age verification requires centralized identity services, persistent user binding, and logging. Those models do not align.
Even if someone tried, it would be trivial to bypass. VPN, foreign mirror, alternative distro. Done. You cannot meaningfully regulate something that is globally mirrored and open source.
And this law is aimed at online services and platforms anyway. The harms legislators are worried about do not originate in your bootloader. They happen on social media platforms and content services. The operating system is simply the wrong choke point.
The only places where age verification is realistically enforceable are platforms, app stores, and tightly controlled commercial device ecosystems. Not a globally distributed kernel maintained by volunteers across multiple jurisdictions.
The idea that Linux is going to meaningfully comply in a way that changes outcomes is technologically naive. At best you get some compliance language from U.S. commercial vendors. At worst you get symbolic features that any moderately technical user can remove in minutes.
That is not how open systems work. Pretending otherwise just advertises a lack of understanding of the architecture being regulated.
I am fully aware of the open source ecosystem. I have contributed to dozens of projects, including the linux kernel, CPython, Perl, and others.
It’s astonishingly obvious that you haven’t bothered to read the bill at all and are just spewing nonsense. Take ten minutes and then pull your head out of your ass.
Sections 1798.501.b, 1798.502.a and b. Every developer of every application that can be downloaded from every website, platform and package system MUST request your age bracket every time it is downloaded. And every time it is launched.
Thats every application, from ‘ls’ to World of Warcraft. Thats every place on the internet that hosts software packages. It doesn’t matter if you feel like it is only aimed at “online services and platforms “ or “social media platforms and content services”.
It is written to cover everything that runs on a computer that can be downloaded and the places that host them. PyPI, crates.io, flathub, Debian mirrors, everything.
And that’s every individual developer who lives in or visits CA.
You’re invoking contributions to the Linux kernel, CPython, and Perl as if that settles the matter, but you have been conspicuously vague about what that actually means. Those projects accept everything from typo fixes to deep subsystem work. If you want that credential to carry argumentative weight, specify what you worked on. Kernel networking stack? Filesystems? A CPython PEP? Core interpreter changes? Because right now it reads like résumé seasoning, not authority.
More importantly, your statutory interpretation is maximalist to the point of implausibility.
You are asserting that Sections 1798.501(b) and 1798.502(a)-(b) require every application binary, including local utilities like ls, to request an age bracket at download and at launch. That is an extraordinary claim. If true, it would not just affect “platforms.” It would upend global software distribution infrastructure including mirrors, package repositories, container registries, and academic hosts.
Where in the definitions does the statute eliminate business thresholds?
Where does it explicitly define a standalone executable with no network component as a regulated “online service”?
Where does it impose a per-launch runtime obligation on locally executed software?
Statutory scope hinges on defined terms. If you are correct, quote the operative definitions that extend coverage to every distributed binary and every individual developer who merely visits California. Because that is not a narrow reading. That is a reading that would trigger immediate Commerce Clause litigation.
You may very well have contributed to major opens source projects. That does not make your legal interpretation automatically sound. Right now you are asserting universal coverage without walking through the definitional cross-references that would be required to sustain that position.
If the text truly says what you claim, show the definitional chain. Otherwise this looks less like careful statutory analysis and more like an overextended reading fueled by frustration.
The bill would require a developer to request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.
This bill would punish noncompliance with a civil penalty to be enforced by the Attorney General, as prescribed.
That’s not an encouraging start. Of course, that’s not the bill itself just the official summary, so we will need to dig in deeper.
At the beginning of the bill proper, there are some definitions, emphasis mine.
There are no business threshold or network capability requirements for the application (though there is one for the computer, sorta). It’s simply anything that may run on a computer. ‘ls’ definitely qualifies as an application per this definition. This is a pretty reasonable definition of ‘application’, even if it is a bit circular. We could also have quite a conversation about what counts as a “other general purpose computing device”, but it isn’t defined here.
(e) (1) “Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application.
(2) “Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application.
PyPI, a Debian mirror, crates.io and GitHub qualify as a “covered application store”. Pip and cargo are an “software application” that “distributes and facilitates the download of applications from third-party developers to users of a computer” so they are as well. Depending on case law curl, rsync and scp might also, though the ‘distributes’ qualifier may exempt them. Oddly, browser add-ons are probably exempt due to (e)(2). And there may be a grey area around things like VMs. A purely personal website that only has software developed by that person probably doesn’t qualify due to the ‘third-party’ qualifier. Again, there is no business threshold listed.
(f) “Developer” means a person that owns, maintains, or controls an application.
Again, a fairly straightforward definition, that would apply to anyone who maintains any “software application that may be run or directed by a user on a computer, a mobile device” per 1798.500.c.
So, we’ve got that developer is a simple definition that basically matches what one would expect, as does application. Covered application store is probably broader than one would expect, and has an odd carve out, but covers most modern software distribution channels. I guess it might not cover sending CDs in the mail.
Then we get to a single simple sentence:
Section 1798.501
(b) (1) A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.
It’s a really simple sentence that can be really easy to gloss over. But read it again. Maybe you could argue that it only applies the first time an application is run. But it absolutely applies when it is downloaded. There are no exceptions listed, no threshold tests, no “social media applications only”. This applies to all applications, all developers, and all “covered application stores”. Now CA jurisdiction doesn’t cover downloads from outside of CA, but it does cover anyone downloading something inside of CA, or someone living in CA. So if a kid in CA downloads something from a outside of CA, the developer is in violation even if they are outside of CA. CA may not have the resources or desire to track down every developer outside of the state, but if they so choose they would be able to file a claim in the same way that CA can file claims on foreign people who violate other laws that involve CA victims, such as fraud.
Finally, there is this bit:
1798.504
(f) This title does not apply to any of the following:
(3) The delivery or use of a physical product.
So, it looks like it doesn’t apply to CDs in the mail.
Edit:
Of course, I forgot to talk about the penalty. Maybe there is something in there?
1798.503
(a) A person that violates this title shall be subject to an injunction and liable for a civil penalty of not more than two thousand five hundred dollars ($2,500) per affected child for each negligent violation or not more than seven thousand five hundred dollars ($7,500) per affected child for each intentional violation, which shall be assessed and recovered only in a civil action brought in the name of the people of the State of California by the Attorney General.
Nope, no exceptions or commercial clauses. It just applies to anyone. And paragraph b?
(b) An operating system provider or a covered application store that makes a good faith effort to comply with this title, taking into consideration available technology and any reasonable technical limitations or outages, shall not be liable for an erroneous signal indicating a user’s age range or any conduct by a developer that receives a signal indicating a user’s age range.
Well, an OS provider or covered application store isn’t responsible for someone lying to them, tech failures, or the actions of a rogue developer. But developers have no such waiver.
Yes it fucking does. Go read the bill, particularly section 1798.501.b, 1798.502.a and b. Every developer of every application that can be downloaded from every package system MUST request your age bracket every time it is downloaded. And possibly every time it is launched. Basic utilities like ‘ls’ and ‘cat’, that pong example I pushed as a test, everything.
The law doesn’t require anything of users, it requires something of OS providers.
For a FOSS OS, any user with root access would be considered an “OS Provider” under the definitions provided in this law. With FOSS, there is no real distinction between “user” and “developer”.
You are right, it just says whoever “controls the OS”, which is very vague. Even without going to open source, a user still controls the OS even on Windows or macOS. To a lesser degree of course, but in the same way a driver controls a car even if they can’t or won’t try to modify it.
The windows user uses the OS. The windows user does not control the OS. They only have access to the functions that Microsoft has provided. The Attorney General of California won’t be able to argue that the sysadmin is the OS Provider of a Windows installation. The OS Provider of Windows is Microsoft.
The Attorney General of California would easily be able to argue that the OS Provider of a particular Linux instance is the sysadmin of that instance.
They only have access to the functions that Microsoft has provided.
And a user of Ubuntu only has access to the functions that Canonical has provided.
Unless they have root access and modify the OS. Or they have administrator access on Windows and modify the OS. Which is the case for both by default. I don’t really see the distinction. There is clearly a provider company behind both, and in both cases the user could add this age check functionality by themselves by installing an utility that provides it.
And a user of Ubuntu only has access to the functions that Canonical has provided.
That is not at all accurate.
Administrator access to Windows is not at all comparable to root access on Linux. Windows “root” access is held solely by Microsoft, and granted only to Microsoft employees and contractors. They are the only ones with the capability of changing Microsoft’s binary blobs.
Canonical doesn’t restrict root access. Everyone who installs Ubuntu has root access by default.
Suppose Canonical adds this capability to Ubuntu. Suppose I take an Ubuntu install, and remove this capability. Who is the provider of the resulting OS, Canonical, or me? Obviously, I am responsible for the changes; I am obviously the OS Provider in this scenario. What I am saying is that I was the OS provider before I made the changes. For FOSS software, the end user fits the OS Provider definition that California creates with this law.
What does the comparability of root/admin access change in this situation?
Suppose Microsoft adds this capability to Windows, and you edit the registry to disable it. How is that any different?
I can see the argument for something like iOS. But on Windows you would be able to add or remove such functionality. What is the difference that makes the user the OS Provider on Ubuntu but not on Windows, in your eyes?
Let’s say you own a computer store in California, you sell Windows laptops, and you setup your preinstalled Windows image with the registry edit made, because customers don’t like the silly age prompt. How are you not the OS Provider?
Suppose Microsoft adds this capability to Windows, and you edit the registry to disable it. How is that any different?
By allowing the end user to change it instead of locking it down, they are not making a good faith effort to comply, and they lose their liability protection. To maintain their immunity, at the very least they will need to prohibit Californians from disabling the feature.
Canonical is prohibited from adding comparable terms.
I can see the argument for something like iOS.
How is iOS any different from Windows here?
Let’s say you own a computer store in California, you sell Windows laptops, and you setup your preinstalled Windows image with the registry edit made, because customers don’t like the silly age prompt. How are you not the OS Provider?
Again, to maintain their immunity under this law, they would have to prohibit me from doing this in their licensing agreement. My violation is what protects Microsoft. I would, indeed, be the OS provider in that scenario.
But in the scenario you describe, I’m not the end user.
Neither Canonical nor I can include the same restrictive terms in our OS offerings. We can simply inform our users that the OS is not California compliant. Our users become their own OS Providers as soon as they decide to use them in California.
Great, but how does that help? 99.9% Linux users use a Linux distro that has, ay the very least, a website behind it, with a domain name, that has a registration info.
That the 0.01% of people that use an OS only hosted by anonymous devs on a Russian website does not make this law any better for the rest of us.
How do you want to do this? Linux is a kernel the world relies on. It powers your car, your fridge, your satellite, your phone, the entire Internet, the army, etc. Nothing comes close to Linux in market share. The distros are built upon the kernel. System76 may have to comply, but the other maintainers don’t give a flying fuck. They could even write a small line somewhere on their repo that says “this distro is not allowed in California” and call it a day.
Terms of Use / Terms of Service are different from Licenses. That said, even if it was compatible that would be a good thing, as the impression I’ve got is that the “hard-liner” Free Software licenses are becoming a thing of the past now that what is needed is “Ethical Source” licenses, that eg.: restrict usage in AI.
You guys are asking the wrong questions.
How is Linux going to do this? There’s no server for the os to send the information to report the age of its users, no way of forcing its user base to comply and no single person or entity to fine, arrest or otherwise force into compliance.
They made a law they cannot enforce.
Or they made a law to attempt to ban operating systems with free software licenses.
But that’s the thing you can’t ban them.
It’s just software that’s freely available. There’s no one corporate entity that controls Linux. Anybody can literally make a distro for it make notation for it illegal for California and be done with it.
But they can fine every single developer of every single application. Sure, a lot of people won’t be in the jurisdiction of the state of California, but there are a hell of a lot of developers who are.
Linux is not a company. There is no CEO of Linux sitting in Sacramento waiting for instructions. It is a decentralized, global, open source ecosystem. If one U.S.-based distro tried to bolt on age verification, someone would fork it almost immediately and strip it out. You cannot age gate software that people can freely download, modify, compile, and redistribute.
From a technical standpoint, what would this even look like? Government ID verification at the kernel level? A biometric scan before you can run apt update? A centralized identity server for Arch users? That runs directly against how Linux is designed. The ecosystem prioritizes privacy, user control, and minimal centralized telemetry. Age verification requires centralized identity services, persistent user binding, and logging. Those models do not align. Even if someone tried, it would be trivial to bypass. VPN, foreign mirror, alternative distro. Done. You cannot meaningfully regulate something that is globally mirrored and open source.
And this law is aimed at online services and platforms anyway. The harms legislators are worried about do not originate in your bootloader. They happen on social media platforms and content services. The operating system is simply the wrong choke point.
The only places where age verification is realistically enforceable are platforms, app stores, and tightly controlled commercial device ecosystems. Not a globally distributed kernel maintained by volunteers across multiple jurisdictions. The idea that Linux is going to meaningfully comply in a way that changes outcomes is technologically naive. At best you get some compliance language from U.S. commercial vendors. At worst you get symbolic features that any moderately technical user can remove in minutes.
That is not how open systems work. Pretending otherwise just advertises a lack of understanding of the architecture being regulated.
I am fully aware of the open source ecosystem. I have contributed to dozens of projects, including the linux kernel, CPython, Perl, and others.
It’s astonishingly obvious that you haven’t bothered to read the bill at all and are just spewing nonsense. Take ten minutes and then pull your head out of your ass.
Sections 1798.501.b, 1798.502.a and b. Every developer of every application that can be downloaded from every website, platform and package system MUST request your age bracket every time it is downloaded. And every time it is launched.
Thats every application, from ‘ls’ to World of Warcraft. Thats every place on the internet that hosts software packages. It doesn’t matter if you feel like it is only aimed at “online services and platforms “ or “social media platforms and content services”.
It is written to cover everything that runs on a computer that can be downloaded and the places that host them. PyPI, crates.io, flathub, Debian mirrors, everything.
And that’s every individual developer who lives in or visits CA.
You’re invoking contributions to the Linux kernel, CPython, and Perl as if that settles the matter, but you have been conspicuously vague about what that actually means. Those projects accept everything from typo fixes to deep subsystem work. If you want that credential to carry argumentative weight, specify what you worked on. Kernel networking stack? Filesystems? A CPython PEP? Core interpreter changes? Because right now it reads like résumé seasoning, not authority.
More importantly, your statutory interpretation is maximalist to the point of implausibility.
You are asserting that Sections 1798.501(b) and 1798.502(a)-(b) require every application binary, including local utilities like ls, to request an age bracket at download and at launch. That is an extraordinary claim. If true, it would not just affect “platforms.” It would upend global software distribution infrastructure including mirrors, package repositories, container registries, and academic hosts.
Where in the definitions does the statute eliminate business thresholds? Where does it explicitly define a standalone executable with no network component as a regulated “online service”?
Where does it impose a per-launch runtime obligation on locally executed software?
Statutory scope hinges on defined terms. If you are correct, quote the operative definitions that extend coverage to every distributed binary and every individual developer who merely visits California. Because that is not a narrow reading. That is a reading that would trigger immediate Commerce Clause litigation.
You may very well have contributed to major opens source projects. That does not make your legal interpretation automatically sound. Right now you are asserting universal coverage without walking through the definitional cross-references that would be required to sustain that position.
If the text truly says what you claim, show the definitional chain. Otherwise this looks less like careful statutory analysis and more like an overextended reading fueled by frustration.
From TFB:
First, from the LEGISLATIVE COUNSEL’S DIGEST
That’s not an encouraging start. Of course, that’s not the bill itself just the official summary, so we will need to dig in deeper.
At the beginning of the bill proper, there are some definitions, emphasis mine.
Section 1798.500
There are no business threshold or network capability requirements for the application (though there is one for the computer, sorta). It’s simply anything that may run on a computer. ‘ls’ definitely qualifies as an application per this definition. This is a pretty reasonable definition of ‘application’, even if it is a bit circular. We could also have quite a conversation about what counts as a “other general purpose computing device”, but it isn’t defined here.
PyPI, a Debian mirror, crates.io and GitHub qualify as a “covered application store”. Pip and cargo are an “software application” that “distributes and facilitates the download of applications from third-party developers to users of a computer” so they are as well. Depending on case law curl, rsync and scp might also, though the ‘distributes’ qualifier may exempt them. Oddly, browser add-ons are probably exempt due to (e)(2). And there may be a grey area around things like VMs. A purely personal website that only has software developed by that person probably doesn’t qualify due to the ‘third-party’ qualifier. Again, there is no business threshold listed.
Again, a fairly straightforward definition, that would apply to anyone who maintains any “software application that may be run or directed by a user on a computer, a mobile device” per 1798.500.c.
So, we’ve got that developer is a simple definition that basically matches what one would expect, as does application. Covered application store is probably broader than one would expect, and has an odd carve out, but covers most modern software distribution channels. I guess it might not cover sending CDs in the mail.
Then we get to a single simple sentence:
Section 1798.501
It’s a really simple sentence that can be really easy to gloss over. But read it again. Maybe you could argue that it only applies the first time an application is run. But it absolutely applies when it is downloaded. There are no exceptions listed, no threshold tests, no “social media applications only”. This applies to all applications, all developers, and all “covered application stores”. Now CA jurisdiction doesn’t cover downloads from outside of CA, but it does cover anyone downloading something inside of CA, or someone living in CA. So if a kid in CA downloads something from a outside of CA, the developer is in violation even if they are outside of CA. CA may not have the resources or desire to track down every developer outside of the state, but if they so choose they would be able to file a claim in the same way that CA can file claims on foreign people who violate other laws that involve CA victims, such as fraud.
Finally, there is this bit: 1798.504
So, it looks like it doesn’t apply to CDs in the mail.
Edit:
Of course, I forgot to talk about the penalty. Maybe there is something in there?
1798.503
Nope, no exceptions or commercial clauses. It just applies to anyone. And paragraph b?
Well, an OS provider or covered application store isn’t responsible for someone lying to them, tech failures, or the actions of a rogue developer. But developers have no such waiver.
The law doesn’t require sending the data anywhere, so that’s not a problem.
The law doesn’t require anything of users, it requires something of OS providers. OS providers have addresses and entities to fine.
Yes it fucking does. Go read the bill, particularly section 1798.501.b, 1798.502.a and b. Every developer of every application that can be downloaded from every package system MUST request your age bracket every time it is downloaded. And possibly every time it is launched. Basic utilities like ‘ls’ and ‘cat’, that pong example I pushed as a test, everything.
For a FOSS OS, any user with root access would be considered an “OS Provider” under the definitions provided in this law. With FOSS, there is no real distinction between “user” and “developer”.
You are right, it just says whoever “controls the OS”, which is very vague. Even without going to open source, a user still controls the OS even on Windows or macOS. To a lesser degree of course, but in the same way a driver controls a car even if they can’t or won’t try to modify it.
The windows user uses the OS. The windows user does not control the OS. They only have access to the functions that Microsoft has provided. The Attorney General of California won’t be able to argue that the sysadmin is the OS Provider of a Windows installation. The OS Provider of Windows is Microsoft.
The Attorney General of California would easily be able to argue that the OS Provider of a particular Linux instance is the sysadmin of that instance.
And a user of Ubuntu only has access to the functions that Canonical has provided.
Unless they have root access and modify the OS. Or they have administrator access on Windows and modify the OS. Which is the case for both by default. I don’t really see the distinction. There is clearly a provider company behind both, and in both cases the user could add this age check functionality by themselves by installing an utility that provides it.
That is not at all accurate.
Administrator access to Windows is not at all comparable to root access on Linux. Windows “root” access is held solely by Microsoft, and granted only to Microsoft employees and contractors. They are the only ones with the capability of changing Microsoft’s binary blobs.
Canonical doesn’t restrict root access. Everyone who installs Ubuntu has root access by default.
Suppose Canonical adds this capability to Ubuntu. Suppose I take an Ubuntu install, and remove this capability. Who is the provider of the resulting OS, Canonical, or me? Obviously, I am responsible for the changes; I am obviously the OS Provider in this scenario. What I am saying is that I was the OS provider before I made the changes. For FOSS software, the end user fits the OS Provider definition that California creates with this law.
What does the comparability of root/admin access change in this situation?
Suppose Microsoft adds this capability to Windows, and you edit the registry to disable it. How is that any different?
I can see the argument for something like iOS. But on Windows you would be able to add or remove such functionality. What is the difference that makes the user the OS Provider on Ubuntu but not on Windows, in your eyes?
Let’s say you own a computer store in California, you sell Windows laptops, and you setup your preinstalled Windows image with the registry edit made, because customers don’t like the silly age prompt. How are you not the OS Provider?
By allowing the end user to change it instead of locking it down, they are not making a good faith effort to comply, and they lose their liability protection. To maintain their immunity, at the very least they will need to prohibit Californians from disabling the feature.
Canonical is prohibited from adding comparable terms.
How is iOS any different from Windows here?
Again, to maintain their immunity under this law, they would have to prohibit me from doing this in their licensing agreement. My violation is what protects Microsoft. I would, indeed, be the OS provider in that scenario.
But in the scenario you describe, I’m not the end user.
Neither Canonical nor I can include the same restrictive terms in our OS offerings. We can simply inform our users that the OS is not California compliant. Our users become their own OS Providers as soon as they decide to use them in California.
No addresses or entities tied to the distro respins I’ve made.
That was not a requirement in the software license.
Great, but how does that help? 99.9% Linux users use a Linux distro that has, ay the very least, a website behind it, with a domain name, that has a registration info.
That the 0.01% of people that use an OS only hosted by anonymous devs on a Russian website does not make this law any better for the rest of us.
What if banning Linux is part of the Agenda? And what will they do for the servers? I am declaring my pc a server as of right now…
How do you want to do this? Linux is a kernel the world relies on. It powers your car, your fridge, your satellite, your phone, the entire Internet, the army, etc. Nothing comes close to Linux in market share. The distros are built upon the kernel. System76 may have to comply, but the other maintainers don’t give a flying fuck. They could even write a small line somewhere on their repo that says “this distro is not allowed in California” and call it a day.
I wonder if that “this distro is not allowed in California” approach is even compatible with the various free software licenses.
Terms of Use / Terms of Service are different from Licenses. That said, even if it was compatible that would be a good thing, as the impression I’ve got is that the “hard-liner” Free Software licenses are becoming a thing of the past now that what is needed is “Ethical Source” licenses, that eg.: restrict usage in AI.
Which is why we all should aspire to join linux, and reject newsome and other greasy california politicians cynically playing us for the billionaires.
From what I understood, it’s a requirement for a local API (for apps to use) and could be implemented during user creation.
It will be a slippery slope and IANAL, just my interpretation.