|
|
Log in / Subscribe / Register

Existing user databases had this field for ages and nobody bats an eye

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 8:49 UTC (Wed) by taladar (subscriber, #68407)
In reply to: Existing user databases had this field for ages and nobody bats an eye by mb
Parent article: Objections to systemd age-attestation changes go overboard

But systemd is not forwarding the pressure to the users. They are just implementing a central way to store a piece of optional data that will likely be required by others who are forwarding the pressure (e.g. websites) in the near future in some jurisdictions.

I for one would not prefer the establishment of secondary alternate per account databases on Linux systems instead of adding a field like "date of birth" that has been in virtually any other account database for ages, to this particular central one.


to post comments

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 10:11 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (15 responses)

Please… they are contributing to the enforcement of terribly written laws. I encourage you to go and read them actually, to get a clear idea of how badly written they are.

Anyway I don't think that "I only implemented part of the feature, not all of it!" is a valid defence.

Plus in some places they forbid the user's birth date to be disclosed for privacy, so having it on a file is already wrong anyway. As I said, terribly written laws that aren't possible to enforce anyway.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:13 UTC (Wed) by pizza (subscriber, #46) [Link] (14 responses)

> Anyway I don't think that "I only implemented part of the feature, not all of it!" is a valid defence.

Following your argument, everyone that contributed to oh, the entire networking stack is also complicit.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:17 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (13 responses)

If they happen to be time travellers from the future who went back in time and implemented networking just so later on create age verification sure. Otherwise I doubt that they are guilty of anything related.

The systemd change is done specifically to comply with age verification laws (and in my opinion it violates some of them so it's not even a good idea to merge it whatever your opinions on the topic might be).

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:42 UTC (Wed) by pizza (subscriber, #46) [Link] (12 responses)

> If they happen to be time travellers from the future who went back in time and implemented networking just so later on create age verification sure

In other words, everyone going forward is automatically complicit, because they're continuing to implement+improve the overall system instead of immediately NOPEing out.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 13:13 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (11 responses)

This sounds like a parody of a lawyer. Intent matters.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 13:29 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> Intent matters.

Willfully ignoring the law rarely turns out well.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:14 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (4 responses)

Do you have any legal precedents to link here? I am very curious.

Remember that PGP was forbidden and then it wasn't. Now it's just subject to a campaign of "asymmetric signatures are too difficult for people to understand"

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 3:01 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> Remember that PGP was forbidden and then it wasn't

s/then/after three years of very expensive legal headaches for Zimmerman/

...headaches that he deliberately brought upon himself by intentionally violating the law and daring the government to go after him.

...It's okay to volunteer yourself for martyrdom, but what I see here is a whole lot of folks saying "not it, you do it instead"

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:55 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

It's not ok to remove privacy for everyone just to comply with the laws of some backward theocracy.

Moreover if you do go and read these laws, what they are doing is actually violating them, so if one wants to avoid all the punishments you're for some reason inventing, breaking these laws by action instead of inaction doesn't seem too helpful.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 15:25 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> It's not ok to remove privacy for everyone just to comply with the laws of some backward theocracy.

....Unless you live/operate in that backwards theocracy.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 16:33 UTC (Thu) by farnz (subscriber, #17727) [Link]

And this is why it needs to remain opt-in; people in that backwards theocracy may be compelled to opt-in by local laws (or may not - depending on the place's legal system, there may be no mechanism to compel individual admins to opt-in, only to compel businesses), but the rest of the world can simply fail to opt-in.

This is why my hard lines are "opt-in, not opt-out", and "if you didn't opt-in, you pass all age verification checks by default". That protects those unfortunate enough to be in the jurisdiction that has dumb laws from being an easy victim (you opt-in, and you comply, which means that you're not a soft target), without putting a burden on those outside those jurisdictions.

After all, when it comes to age attestation, the hard part is not "how old is the user?", but "how can I trust this attestation?". So far, all of these laws boil down to "you can trust the device to not lie" - but that is inherently in conflict with Free software and laws preventing you from being compelled to not lie.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 6:44 UTC (Thu) by ssmith32 (subscriber, #72404) [Link] (4 responses)

To some people more than others.

For me, intent, in open source in particular, really doesn't matter.

I don't really care why Linus created Linux, just that he did.

More controversially, I really, really don't care why Bill Gates donates billions to health, education, etc, just that he does. Whereas some people seem eager and ready to dismiss the massive positive impact with any number of ad hominem attacks.

https://duckduckgo.com/?t=fpas&q=deontology+vs+conseq...

To be honest, I find the deontological approach to judging actions pretty irrational, but it's there, I get it, and I use it as a nice short cut oft-times (as it's _really_ hard to do consequentialism fully and correctly, and done poorly, it all too often becomes some kind of perverse justification for being horrible, and this, unfortunate, consequence of consequentialism crops up a lot in the psuedo-tech, actual bro, crowd).

So blah, to sum up, yours is a personal viewpoint based on a particular ethical philosophy that isn't something that can be declared true by fiat. It's an opinion, not a fact.

Now a jury's or judge's (probably wrong) perception of your intent, yes, *that* can matter, and have real consequences. Most legal systems are dumb and irrational, but they serve a valuable role regardless.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:03 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

Intent is important as a way of predicting future behavior. Consider someone who contributes to a poorly maintained FOSS project. If they're doing it because they depend on the project and want it to be better maintained, that's great. If they're doing it because they're hoping to take it over and use it for a supply chain attack, not so much. Their intent 100% matters!

Similarly, if someone is adding a birthday field to protect compatibility with other software, that's very different from doing it because the government says you have to as part of a half-baked plan to protect children from porn. One of those improves the software by making it more compatible, and the other one helps to use the software against the user. Totally different things.

The reason to question judging actions based on intent is because it's so easy to get intent wrong. People can lie about why they're doing things, so you can't blindly trust their stated reasons. Nobody is going to tell you they're just contributing to a FOSS project as the early stage in a supply chain attack. That leaves you judging based on much murkier criteria, which makes is way too easy to let existing biases show through. In this case, I suspect some of the worry about this is coming from people who are already skeptical of the systemd project and its contributors. Anything coming from systemd is going to start with a base level of hostility because of existing mistrust.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:34 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> One of those improves the software by making it more compatible, and the other one helps to use the software against the user. Totally different things.

You left out "the other one protects the software author(s) from being subjected to ruinous legal expenses and/or jail time"

Expecting other folks to willfully violate the laws of the jurisdictions in which they operate is a breathtaking level of privilege.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:49 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (1 responses)

> You left out "the other one protects the software author(s) from being subjected to ruinous legal expenses and/or jail time"

LOL.

Why not torture and then a nice hanging in a public square, since we're making unrealistic stuff up…

I have faith in you; you can come up with some more original forms of made up scary punishment for the noble goal of removing privacy and creating churn for unpaid people.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 15:14 UTC (Thu) by pizza (subscriber, #46) [Link]

> Why not torture and then a nice hanging in a public square, since we're making unrealistic stuff up…

What's unrealistic? Look at Phil Zimmerman. Or Rosa Parks.

Sure, they ultimately prevailed in the end (to all our benefit) but they were put through hell along the way.

> I have faith in you; you can come up with some more original forms of made up scary punishment for the noble goal of removing privacy and creating churn for unpaid people.

I live in a jurisdiction that explicitly empowers private individuals to personally sue teachers and librarians (who then have to prove *innocence* rather than the other way around) should they even mention the existence of non-binary genders or give a child the "wrong" book, or doctors mentioning the "wrong" treatments, or one of several other culture-war issues, most of which were all sold under the guise of "protecting children".

I see which way the wind has been blowing, and I see the growing forces just itching to "make an example" of someone out of pure cruelty and spite. So no, I'm being _very_ realistic here. Folks with the most exposure (ie OS creators/vendors) are very wise to protect themselves (to avoid being among the first "easy" targets) while the legal fights over this stuff continue.

(And in full disclosure: I regularly donate to numerous organizations that are actively fighting these things)

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 10:27 UTC (Wed) by mb (subscriber, #50428) [Link] (21 responses)

>systemd is not...

Yeah. But you can say that about every part of a DRM system.
There is no single part which is *the* thing that does the restriction. It's the combination of everything, including the systemd part.

Every part in the DRM system is "just" doing this and that.
Seen in isolation they are probably all fine. The systemd age field included.

It's wrong to contribute small details to the system, if the system is wrong.
This feature was clearly added to enable the age DRM system. And that's why it was wrong.

And the argument that if we don't do it, somebody else will do it, is invalid and a straw man.
If somebody else does it, it's their problem.
Users will object to *both* solutions equally.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 13:08 UTC (Wed) by farnz (subscriber, #17727) [Link] (20 responses)

Just to be clear - you're saying that it's wrong to enable people to use Free Software in a jurisdiction that requires this, and that we should instead tell people that they must use proprietary software because it implements the restrictions required by law?

In other words, you want people to be told that they must use Android, Windows, iOS, macOS, Google Chrome etc instead of Debian, OpenBSD, MirBSD, Firefox etc precisely because it's legally mandated that they have a way in the OS to store the date of birth, and to attest your age to applications?

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:00 UTC (Wed) by mb (subscriber, #50428) [Link] (19 responses)

>you're saying that it's wrong to enable people to use Free Software

I'm sorry, but this is just silly. Read what I already wrote, please.
I'll stop here, because I already answered all of these "questions".

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:05 UTC (Wed) by farnz (subscriber, #17727) [Link] (18 responses)

I read what you already wrote.

Given that it is a legal requirement in some jurisdictions for OSes to provide this service, or else the OS is unlawful to sell or install, that is the only way I can read your position - you are saying that Free Software must not comply with the law in that jurisdiction, which implies that people in that jurisdiction must use proprietary software.

That is also the end case for your slippery slope argument - if you cannot legally watch Netflix with Free Software (to choose an actual DRM example), then you are implicitly saying that you expect people who want to watch Netflix legally to use proprietary software.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:09 UTC (Wed) by mb (subscriber, #50428) [Link] (17 responses)

I'll add one thing to make it really clear and then I'll shut up:
With this silly reasoning you are saying that we have to comply with North Korea rules and implement all their restrictions, because otherwise we would not enable these people to use Free Software.

It's pretty clear that: No we do not have to. We can say no. Neither US nor North Korea or any other country can issue laws that we *have* to listen to as a project. Yes, it would make the project less usable or maybe unusable in these countries. But the root cause is jurisdiction placing restrictions, not Free Software projects rejecting these rules.

We need to implement what helps people and not what restricts people (Digital Restrictions Management).

It is the problem of the jurisdiction, if it restricts people. It is not the problem of Free Software. And we cannot fix this by restricting Free Software, obviously.

Fix your country, the software ain't broken.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:13 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

No; I'm saying that if you don't comply with North Korean rules and restrictions, you are implicitly saying that North Koreans should use something else instead; and if you're saying that no Free Software can comply with those restrictions, then you're saying that North Koreans can't use Free Software.

This is a perfectly reasonable position to take - but you have to be clear that when you're saying that no software with an administrator controlled date of birth field (systemd-userdb, FreeIPA, OpenLDAP, 389-ds and more) can qualify as "Free" because of the risk of people using it to implement bad laws, you are inherently saying that people must use proprietary software to fill that niche.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:58 UTC (Wed) by somlo (subscriber, #92421) [Link] (6 responses)

OK, I'll bite :)

What, exactly, is the difference in end-result between (1) losing your actual freedom(s) by needing to use proprietary software, and (2) losing your actual freedoms by having them taken away by the "Free Software" implementations deciding to obsequiously comply with "freedom-challenged" legislation ?

And please don't tell me that "at least, obsequiously compliant free software allows you to patch out the obsequiously compliant bits" -- that is obviously not a scalable answer... :(

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:02 UTC (Wed) by dskoll (subscriber, #1630) [Link] (4 responses)

And please don't tell me that "at least, obsequiously compliant free software allows you to patch out the obsequiously compliant bits" -- that is obviously not a scalable answer... :(

I think it will be a scalable answer. I'm fairly confident that someone will provide patched versions of the software that patches out the obsequiously compliant bits, so it's not as if everyone who wants them gone will need to do it themselves.

I would hope and expect a constitutional challenge against these laws, at least in the United States. But I place no bets on the result, unfortunately.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:13 UTC (Wed) by somlo (subscriber, #92421) [Link]

> I'm fairly confident that someone will provide patched versions of the software that patches out the obsequiously compliant bits

And now we're arguing about the definition of "scalable" :) If the "serious" software maintainers become "obsequious", we get fragmentation and balkanization and "buyer-beware" wild-west environments in which we now have to decide which intermediary provider of patched software is NOT trying to scam us...

> I would hope and expect a constitutional challenge against these laws

And I would (have) hope(d) the Free Software "community at large" would (have) at least waited for that sort of process to run its course before tripping over itself to obsequiously comply, *preemptively* :(

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 4, 2026 12:32 UTC (Sat) by Rudd-O (guest, #61155) [Link] (2 responses)

Patch versions of that software already exist. What good will it do to you if apps and websites in the future refuse to provide you service unless you disclose that information, because you have a patched app that doesn't disclose it.

I will go on record to say again and again and again. The only solution that we have to avoid that dystopia of privacy invasion we are hurtling towards is to refuse to build the technical side of the dystopia. Sadly, key people in the Linux infrastructure space are gleefully collaborating with that dystopia today, and some even playing fools and pretending they don't know what they're doing.

We know what they're doing.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 7, 2026 8:42 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

The fundamental enabling technology for this, and the technical side that you need to stop people building, is user accounts.

Everything else is built on top of that enabling technology. Without it, this "dystopia of privacy invasion" cannot be built, because there isn't anything tied to an individual on a single system.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 7, 2026 10:42 UTC (Tue) by pizza (subscriber, #46) [Link]

> The fundamental enabling technology for this, and the technical side that you need to stop people building, is user accounts.

And refusing to build this on the client side just means that the accounts (and "verification mechanisms") will be implemented on the server side.

Given that those accounts _already_ exist on the server side, and routinely collect far, far more private information than one's age... you're attempting to fighting a battle that was lost literally decades ago.

This is a purely legal fight, not a technical one. It _must_ be fought in the legal [1] realm and cannot be solved/bypassed using technical means, because the agents of the state that will inevitably enforcing it simply do not care about "Free Software" or even "Freedom"... or any principle other than wielding pure, unadulterated power for its own sake.

(FWIW I think California's law was well-intentioned but did not consider any negative consequences, and at best will still end up being enforced unevenly. Whereas variations of those laws under consideration elsewhere, including federally and in my home state, will absolutely be used primarily against political opponents and the current culture war scapegoats. Because the ones pushing for these laws are already doing so with every other law at their disposal)

[1] and/or physical, ala pitchforks and guillotines. Which comes with a whole new set of problems.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:31 UTC (Wed) by farnz (subscriber, #17727) [Link]

Proprietary software may well not respect other freedoms that matter to you, beyond the freedoms that legislation prohibits. You can at least verify that Free Software is doing the minimum to respect your local laws, and not treating your privacy as an optional thing that it doesn't have to care about.

Additionally, because the implementation is fully Free, you can use it as evidence to a politician that the law is a donkey; whereas a proprietary implementation can pretend that their secret sauce is so good you'll never work out how to bypass the intentions behind the law, a Free implementation has no secret sauce, and you can thus show how to use it to bypass the legislative intent.

That's doubly true of this implementation, which is an optional field that can only be set by an admin. But if you install Fedora, Debian, Ubuntu, Arch, Bazzite or other Free OS yourself, you are the admin, and nothing prevents you filling in the field with (say) 14 May 1984, even if you are in fact younger than Mark Zuckerberg.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:56 UTC (Wed) by anselm (subscriber, #2796) [Link] (8 responses)

It is the problem of the jurisdiction, if it restricts people. It is not the problem of Free Software. And we cannot fix this by restricting Free Software, obviously.

That depends. We can still endeavour to give people the best possible experience within the restrictions that do exist.

For example, here in the EU, regulations limit the 5-GHz-band WLAN channels open to the public. While the WLAN modems in our computers can theoretically use all the WLAN channels available anywhere, the Linux kernel supports a mechanism that lets us stick to the ones we're actually legally allowed to access here. In your logic, the authors of the WLAN support in the kernel should simply refuse to implement such a mechanism because it caters to a “problem of the jurisdiction”, and WLAN users in the EU should either accept jeopardy if we're caught using the taboo channels or just not use 5-GHz WLAN with Linux at all until we can get the laws changed. Obviously, both those alternatives are inferior to the one we actually have, namely accepting the restrictions (which frankly aren't that onerous) and enjoying the use of 5-GHz WLAN without having to worry about radio measurement vans outside our houses.

For the time being, nobody knows what an “age-attestation” infrastructure should look like (and the requirements are likely to vary by jurisdiction , anyway). In the end, however, I would much rather have a free Linux system that gives me the best possible experience in the face of any requirement for “age attestation” in my jurisdiction, than no Linux system at all because some guy somewhere on the Internet has decreed that ideological purity makes Free Software incompatible with such a requirement and that therefore developers should desist from addressing the issue at all on pain of receiving death threats and other harassment. Given this, a way of specifying one's date of birth in a standardised and well-understood place like the systemd user database is obviously not the worst idea if the alternative is that every other program must come up with their own version of /etc/birthdays.

It would clearly be even better if the laws were such that Linux would not have to provide an age-attestation infrastructure in the first place, but given that various places in the world may well end up with that requirement, it makes sense to consider how best to help Linux users in such an environment. In addition, even in the continuing absence of age-attestation requirements, having the possibility to store one's date of birth in a standardised and well-understood place on the system might come in useful at times – as the authors of all sorts of non-systemd user database schemes have apparently already figured out for themselves long before the age-attestation issue even came up, so there should clearly be no problem with systemd merely catching up with the rest of the pack.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:31 UTC (Wed) by mb (subscriber, #50428) [Link] (7 responses)

>In your logic, the authors of the WLAN support in the kernel should simply refuse to implement such a mechanism

No. In my logic I set the subsystem to my country and it doesn't restrict me and doesn't needlessly store my private information.
Like how wireless-regdb did from the very beginning.

Storing private information and turning wireless on and off are completely different problems. Also by law, here in the EU. There are extremely strict rules when it comes to processing and storing private information. And we must stick to rules, right? Or does this only count, if these rules come from the US?

Also, I would be completely fine to leave wireless compliance entirely to the user.
I was actually involved in the discussions back when wireless-regdb was built. I did totally agree that we absolutely need that thing.

But that's about 20 years ago and opinions change.
Today I would not do it and just leave it up to the user instead.
Because at the end this whole thing is just a pretty useless compliance dance, that completely breaks down if the user doesn't set the country correctly or not at all.

>For the time being, nobody knows what an “age-attestation” infrastructure should look like

Well, we know what the database looks like apparently.
That's a significant part of it.

We shouldn't be building *any* part of it.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:33 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

Why is it OK to deal with the WiFi regulatory DB by setting the regulatory domain to your country, but not OK to deal with age verification by not setting your date of birth in your optional account metadata?

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:38 UTC (Wed) by dskoll (subscriber, #1630) [Link] (4 responses)

Because a WiFi regulatory domain is not personally-identifying information.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 16:21 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

Nor is a NULL value in a database field.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 16:45 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

Please read by comment again. I said that I would *not* participate in implementing such a thing again and I would actively argue against it, if I had today's knowledge 20 years ago. The world changed a lot since than.

I can live well with putting the country code into wireless-regdb config, because that is *much* less critical than putting an age into an age verification system, which this systemd database is designed to become part of.
But I do not like it anymore.

Also, if there's an age verification system in place, then putting a NULL value there will lock me out.
This is a fake choice.
Just like "It's free software, just patch it out" or "write your own system from scratch" also are fake choices.
In practice everybody in the world is limited to what some US lawyers say.

We should not participate in any part of establishing such a system.
The problem must be fixed at the political root instead of implementing technical restrictions. To my knowledge, no court has ruled that systemd must implement anything for an age verification system. That would be a minimum requirement for me to get active and even think about implementing such a thing. Before that I would do exactly nothing.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 17:07 UTC (Wed) by farnz (subscriber, #17727) [Link]

But your argument is "if there is an optional field, and someone makes it mandatory, then the optional field is a bad thing to have, and nobody should be allowed to participate in software development if they put in an optional field that could be misused if it's made mandatory".

And I simply don't agree with that - as long as it stays optional, I'm fine with it. The moment that a NULL value in there locks you out, I'm with you - a NULL value should always be taken as "the user is the correct age".

In that respect, a Free implementation that complies with the law as written, and is trivial to bypass, is in many ways better than refusing to implement it at all - it shows very strongly that the law as written does not work, and requires the legislators to engage with technical reality, even when engaging with it is politically unpopular.

After all, if there's an implementation that you can ignore by refusing to give your date of birth, they either have to criminalize refusing to give your correct date of birth, or find some way to make the implementation illegal - thus showing clear hostility to Free software (and, indeed, software as speech).

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 16:59 UTC (Wed) by farnz (subscriber, #17727) [Link]

And, to be clear, if someone was proposing that this field had to be mandatory, I'd be getting upset then.

But that's the line for me - if you're being given the tools to comply with the law, but can just opt out if you don't care about that particular law (e.g. because you're not in that jurisdiction, or because you're willing to commit crimes in the name of personal freedom), that's fine with me.

The hard line is when I can't choose to ignore your jurisdiction.

Taking the North Korea argument at face value, for example, I have no problem with a configuration option that only the system administrator (root in a traditional setup) can set that's "comply with North Korean law". That might even be useful if you're under North Korean jurisdiction - you can set this configuration option, and your users now have to live with the consequences.

I do, however, have a problem with "the North Korea compliance option must be forced on, even if you aren't in North Korean jurisdiction"; while, yes, that solves a problem for North Koreans (who now don't need to demonstrate that they've never set the option to the "wrong" setting), it creates a problem for the rest of us whenever what we want to do is in conflict with what North Korea wants.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 10:07 UTC (Thu) by paulj (subscriber, #341) [Link]

> Because at the end this whole thing is just a pretty useless compliance dance, that completely breaks down if the user doesn't set the country correctly or not at all.

Or... the user sets the correct country, but the driver then just completely ignores it and sets "USA", cause the wifi's EEPROM has a field with '00' burned into it. (Which seems to be common for cheap ath9k hardware, maybe others). Only way to get around this is to apply a trivial patch to ignore this override (e.g. OpenWRT has one) and recompile your kernel, so that the damn wireless regulatory framework can be allowed to work correctly.

Arg!


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds