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.
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.
mechoman444@lemmy.world 2 weeks ago
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.
BartyDeCanter@lemmy.sdf.org 2 weeks ago
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.
mechoman444@lemmy.world 2 weeks ago
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.
BartyDeCanter@lemmy.sdf.org 2 weeks ago
From TFB: First, there are some definitions: Section 1798.500
There are no business threshold, network capabilities 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.
PyPI, a Debian mirror, crates.io and GitHub qualify as a “covered application store”. Pip, 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.