this post was submitted on 02 Mar 2026
651 points (97.1% liked)
Technology
82252 readers
5564 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Let's remember that the law distinguishes between the OS and Applications running on that OS. They require that the signalling apparatus be included in the OS. Technologically, the distinction between OS and Application is somewhat arbitrary. For commercial OSes, it's pretty simple: The OS is what Microsoft declares to be part of "Windows" is the OS; everything else is an application.
Suppose Microsoft refuses to include this signaling apparatus. The end user cannot modify Windows, so does not become liable as the "OS Provider". The user can bolt on the functionality as an application, but cannot make it part of the OS. Microsoft is the one facing the fines under this law.
For FOSS software, the end user's root access gives them the ability to add this signaling capability to the OS running on their machines, even if Canonical refuses to distribute a compliant OS. The user's ability to make their own OS compliant with California law makes them the party liable for non-compliance.
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.
All right, then your argument relies on the licensing difference, not any technical differences between Linux root / Windows admin or source code access. Which makes sense, but it's all hypothetical since neither company addressed this yet, either in the product or in the licensing.