legal March 2026

legal@lists.fedoraproject.org

16 participants
17 discussions

BSD-3-Clause vs CMU
by sagitter＠fedoraproject.org 19 May '26

19 May '26

Hi all. Checking the license of next psblas3 release, `licensecheck` tool recognizes this license file [1] as CMU Upstream confirmed that psblas3 is distributed under a BSD-3-Clause instead [2]. Why does it look like `licensecheck` is confused with this license? [1] https://github.com/sfilippone/psblas3/blob/development/LICENSE [2] https://github.com/sfilippone/psblas3/issues/37 --- Antonio Trande Fedora Project, User:Sagitter Website: antoniotrande.blog mailto: sagitter(a)fedoraproject.org GPG key: 0x6ea362cc4c1aeac10b3a5c5402b0e70b4933065a GPG keys server: https://pgp.mit.edu/

8 14

Relicensing controversy in python-chardet
by Ben Beasley 29 Mar '26

29 Mar '26

The current upstream maintainer of python-chardet recently used the Claude Code LLM to completely rewrite the library for version 7.0.0[1]. The source code now has no obvious direct relationship with previous versions. The maintainer used the LLM-based rewrite as justification to unilaterally relicense the project from LGPL-2.1-or-later to MIT. This has prompted a debate about whether or not the maintainer truly has the right to do so, given their deep familiarity with the LGPL code and other considerations. The original author of the library feels that the relicensing was improper[2]. There is no great rush to make a decision about how to handle this particular situation. I can keep python-chardet at 6.0.0 in Fedora for quite a while. However, we in Fedora may end up having to make a decision sooner or later on what to do about cases like this. Even if the question can be somehow sidestepped for chardet, we can expect to be faced with an increasing number of similar situations. [1] https://github.com/chardet/chardet/pull/322 [2] https://github.com/chardet/chardet/issues/327

3 5

License of XSD package
by sagitter＠fedoraproject.org 24 Mar '26

24 Mar '26

Hi all. Please, help me to correctly recognize the license of XSD package [¹] I have attached the files provided by source archive. It looks like a "GPL-2.0-only WITH Universal-FOSS-exception-1.0" [¹] https://src.fedoraproject.org/rpms/xsd --- Antonio Trande Fedora Project, User:Sagitter Website: antoniotrande.blog mailto: sagitter(a)fedoraproject.org GPG key: 0x6ea362cc4c1aeac10b3a5c5402b0e70b4933065a GPG keys server: https://pgp.mit.edu/

2 1

Software origin
by Benson Muite 19 Mar '26

19 Mar '26

Hi, Is it possible to get clarfication whether software of any origin under a license approved to be included in Fedora can be included in Fedora? It applies in particular to: https://bugzilla.redhat.com/show_bug.cgi?id=2425235 See also https://forge.fedoraproject.org/council/tickets/issues/528 Regards, Benson

2 1

On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states
by Aaron Rainbolt 18 Mar '26

18 Mar '26

Given that this is related to legal stuff, I should preface this by saying I am not a lawyer. Recently, a new law was passed in California that requires OS vendors to provide some limited info about a user's age via an API that application distribution websites and application stores can use. [1] Colorado seems to be working on a similar law. [2] The law will go into effect January 1, 2027, it is no longer a draft. I do quite a bit of work with an OS vendor (working with the Kicksecure [3] and Whonix [4] projects), and we aren't particularly interested in blocking everyone in California and Colorado from using our OSes, so we're currently looking into how to implement an API that will comply with the laws while also not being a privacy disaster. Given that other distributions are also investigating what to do with this, and the law requires us to make a "good faith effort to comply with [the] title, taking into consideration available technology", I figured it would be a good idea to bring the issue here. At its core, the law seems to require that an "operating system" (I'm guessing this would correspond to a Linux distribution, not an OS kernel or userland) request the user's age or date of birth at "account setup". The OS is also expected to allow users to set the user's age if they didn't already provide it (because the OS was installed before the law went into effect), and it needs to provide an API somewhere so that app stores and application distribution websites can ask the OS "what age bracket does this user fall into?" Four age brackets are defined, "< 13", ">= 13 and < 16", ">= 16 and < 18", and ">= 18". It looks like the API also needs to not provide more information than just the age bracket data. A bunch of stuff is left unclear (how to handle servers and other CLI-only installs, how to handle VMs, whether the law is even applicable if the primary user is over 18 since the law ridiculously defines a user as "a child" while also defining "a child" as anyone under the age of 18, etc.), but that's what we're given to deal with. The most intuitive place to put this functionality would be, IMO, AccountsService. The main issue with that is that stable-release distributions, and distributions based upon them, would be faced with the issue of how to get an updated version of AccountsService integrated into their software repositories, or how to backport the appropriate code. The law goes into effect on January 1, 2027, Debian Bookworm is going to be supported by ELTS until July 30, 2033, and we don't yet know if Debian will care enough about California's laws to want to backport a new feature in AccountsService into Debian Bookworm (or even Trixie). Distributions based on Debian (such as Kicksecure and Whonix) may still want to comply with the law though, so something using AccountsService-specific APIs would be frustrating. Requiring a whole separate daemon for the foreseeable future just for an age verification API would also be annoying. Another place the functionality could go is xdg-desktop-portal. This one is a bit non-ideal for a couple of reasons; for one, the easiest place to put the call would be in the Account portal, which returns more information than the account's age bracket. This could potentially be considered non-compliant with the law, as it states that the operating system shall "[s]end only the minimum amount of information necessary to comply with this title". This also comes with the backporting disadvantages of an AccountsService-based implementation. For this reason, I'd like to propose a "hybrid" approach; introduce a new standard D-Bus interface, `org.freedesktop.AgeVerification1`, that can be implemented by arbitrary applications as a distro sees fit. AccountsService could implement this API so that newer versions of distros will get the relevant features for free, while distros with an AccountsService too old to contain the feature can implement it themselves as a stop-gap solution. Taking inspiration from the File Manager D-Bus interface [5], I think something like the following might work: <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> <node name="/org/freedesktop/AgeVerification1"> <interface name="org.freedesktop.AgeVerification1"> <method name="SetAge"> <arg type="s" name="User" direction="in"/> <arg type="u" name="YearsOfAge" direction="in"/> </method> <method name="SetDateOfBirth"> <arg type="s" name="User" direction="in"/> <arg type="s" name="Date" direction="in"/> </method> <method name='GetAgeBracket'> <arg type="s" name="User" direction="in"/> <arg type="u" name="AgeBracket" direction="out"/> </method> </interface> </node> * The 'User' argument would, in all instances, be expected to be the UNIX account username of the user in question. This user account must not be a system account (i.e. its UID must fall between UID_MIN and UID_MAX as defined by /etc/login.defs). If a user is specified that does not exist or whose UID is out of range, these methods will return the error 'org.freedesktop.AgeVerification1.Error.NoSuchUser'. If the specified user is not the same as the user making the method call, and the user making the method call is not root, these methods will return the error 'org.freedesktop.AgeVerification1.Error.PermissionDenied'. * The 'YearsOfAge' argument of the 'SetAge' method should be an unsigned integer specifying the age of the user in years at the time of the method call. (The law specifically allows providing simply an age value rather than a birth date if desired.) * The 'Date' argument of the 'SetDateOfBirth' method should be a string in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on which the user was born. If the argument is invalid, the method will return the error 'org.freedesktop.AgeVerification1.Error.InvalidDate'. * The 'AgeBracket' output argument of the 'GetAgeBracket' method will be an unsigned integer between 1 and 4 inclusive, where 1 indicates that the user is under 13 years old, 2 indicates that the user is at least 13 and under 16 years old, 3 indicates that the user is at least 16 and under 18 years old, and 4 indicates that the user is 18 years old or older. If no age has been configured for the user yet, the method will return the error 'org.freedesktop.AgeVerification1.Error.AgeUndefined'. I propose that the exact way in which age information is stored by the daemon should be left implementation-defined. For Kicksecure, the way we implement it will almost certainly store only the age bracket and require users to explicitly reconfigure their age once they are old enough to move from one age bracket to another. Other implementations may choose to store the date of birth or the age and date on which the age was set so that they can automatically update the age bracket as time passes. This interface will be provided *on the system bus* (NOT the session bus!), and the D-Bus service that provides these services should run as root. The file containing the user-to-age mappings should be owned by root and should not be world-readable, to prevent leaking the user's specific age to malicious applications. Some things I did think about when writing the above but ultimately decided to not propose: * Detailed permission gating for the 'GetAgeBracket' method. The only reason to do this would be for additional privacy, and privacy-conscious users can simply lie about their age or the age of the intended user. There isn't anything in the law (that I can tell) that prevents the user from just saying "I'm 18" when the prompt appears and going with it. This would also be really difficult to implement outside of the context of xdg-desktop-portal, and would probably only work with sandboxed apps if it was implemented that way. * UX for actually requesting the age from the user. IMO this is out of scope for FreeDesktop; individual distros should see to it that they prompt for the user's age or birth date at "account setup" (whatever that happens to be defined as for the distro in question), nudge the user to provide the information later on for existing installations, etc. Furthermore, this mechanism needs to work even on CLI-only installs and maybe even on server installs, depending on how one defines "general purpose computing device" (as specified by the law in question), so defining any specific UX is likely infeasible. (If this is required on servers, end-users will probably want to auto-provision the age information somehow, and specifying how to do that in a distribution-agnostic way is impossible given that Ubuntu uses cloud-init, Fedora uses Kickstart and Ignition, etc.) * Omitting the 'SetDateOfBirth' method. It can be lived without legally, but without the method, it becomes difficult for software that already records the user's date of birth to accurately implement automatic age bracket adjustment as time passes. This isn't a feature Kicksecure would use, but it's a feature some projects might be interested in. Thanks for taking a look at this. -- Aaron [1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=20252… [2] https://leg.colorado.gov/bill_files/110990/download [3] https://www.kicksecure.com/ [4] https://www.whonix.org/ [5] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/

3 4

Re: On the need for a censorship API for legal compliance reasons in some countries and U.S. states
by Jamie Null 17 Mar '26

17 Mar '26

I'm going to hope that this is all satire. -- Jamie On 2026-03-17 14:00, Adenix NPSP wrote: > Will there be a way for developers of "ageless" linux distros (linux > distros without age verification) to handle such a plan while still being > able to opt out of age verification? > > On Tue, Mar 17, 2026, 12:48 PM Marco Trevisan <marco.trevisan(a)canonical.com> > wrote: > >> On decryption, I don't think we've to create another specific >> implementation for this. >> >> What we all need (pretty desperately TBH, and for many things that >> goes from authentication systems up to proper keyrings and password >> managers) it's a proper secure enclave in the linux systems using >> Virtualization-Based Security (VBS). >> >> There are already some implementations for the Linux kernel on which >> both MS and Amazon are working, and I feel that we should ensure that >> the ecosystem is ready for that. >> >> See: >> https://www.iinuwa.xyz/blog/linux-passkeys-update/#hardening-platform-authe… >> >> Cheers >> >> Il giorno dom 8 mar 2026 alle ore 16:21 Personal (disroot.org) via >> ubuntu-devel <ubuntu-devel(a)lists.ubuntu.com> ha scritto: >>> >>> 4 Mar 2026 05:12:31 FloofyWolf <debian-devel-list(a)floofywolf.net>: >>> >>>> Recently, a proposal has been made to implement an API for a new >>>> California censorship regulation, “On the unfortunate need for an "age >>>> verification" API for legal compliance reasons in some U.S. states” by >>>> Aaron Rainbolt. I believe the approach outlined to be very >>>> short-sighted, in that creating a bespoke API for each of the hundreds >>>> of government censorship requirements that debian will presumably now >>>> be following will result in much duplication of effort and an >>>> unreliable user experience in which important censorship restrictions >>>> may be missed and not implemented. As such, with people now supporting >>>> the idea that debian should implement government censorship requests, >>>> even creating new standards if needed, I propose the creation of a >>>> censorship framework to speed implementation of current and future >>>> censorship regulations. >>>> >>>> On installation, the user will be required to enter their location. >>>> This information may be pre-filled if device location (GPS) or other >>>> sources of location data (IP geolocation, selected timezone, etc) are >>>> available. If the user enters a location that does not match any >>>> gathered location data, this will be immediately stored and sent to >>>> authorities in both the detected location and the entered location to >>>> alert them of a citizen potentially trying to evade censorship >>>> regulations. If the location entered requires further information, >>>> such as whether an encryption license has been acquired, the user’s >>>> age, etc, it will be requested at this point. This process will also >>>> be repeated every time a user account is created, and will require >>>> implementation in both graphic and text-based account management >>>> utilities, such as adduser. >>>> >>>> This location and user data will be managed by a new daemon, >>>> systemd-censord, and stored in an encrypted form and otherwise >>>> protected so as not to be readable or modifiable by any user on the >>>> system. To ensure privacy, great care must be taken to prevent a user >>>> from being able to access other users’ personal information, and to >>>> ensure compliance with censorship regulations, no user may be able to >>>> change their location in any fashion which bypasses dedicated >>>> utilities, which will perform the required location validation and >>>> discrepancy authority notice functions when the user requests to change >>>> their location, such as for moving house or travel. >>>> >>>> Systemd units will be created for every desired censorship function, >>>> and will be started based on the user’s location. For example, a unit >>>> for Kazakhstan will implement the government-required backdoor, a unit >>>> for China will implement keyword scans and web access blocks (more on >>>> this later), a unit for Florida will ban all packages with “trans” in >>>> the name (201 packages in current stable distribution), a unit for >>>> Oklahoma will ensure all educational software is compliant with the >>>> Christian Holy Bible, a unit for the entire United States will prevent >>>> installation of any program capable of decoding DVD or BluRay media, >>>> and a unit for California will provide the user’s age to all >>>> applications and all web sites from which applications may be >>>> downloaded. As can be seen, multiple units may be started for a given >>>> location. >>>> >>>> All communication will be over D-Bus, with each application proactively >>>> asking systemd-censord for permission to perform any operations which >>>> may foreseeably be restricted anywhere in the world. A standardized >>>> list of permissions will need to be developed, as well as standard >>>> personal data fields, such as user age. Blobs for the storage of media >>>> player keys and digital rights management content could also be added >>>> as additional functionality. >>>> >>>> Since keyword scanning and web filtering are extremely common >>>> government interests, a dedicated daemon for this function should be >>>> created, with kernel hooks to allow inspection of all internal program >>>> structures as well as internet traffic. This daemon can then be >>>> started with different filter configuration files for each systemd unit >>>> triggered by the user’s location. To comply with book bans common in >>>> many US states, such as those restricting access to books on >>>> LGBTQ[[:alnum:]]* topics or having non-white characters, this module >>>> should also automatically search the filesystem for prohibited ebook >>>> files. >>>> >>>> Many packages will need to be altered to include specific functionality >>>> relevant to censorship, including dpkg. For example, installing tor >>>> will be prohibited in many countries, and some packages, like >>>> fortunes-off, will be restricted based on the user’s age, as will most >>>> games. Web browsers will have to be patched to send the user’s age to >>>> all websites hosting applications for download. Encryption packages >>>> will have to check if a systemd unit limiting encryption strength is >>>> running, and set their maximum key length, disable features, or send >>>> private keys to a specified IP address determined by the unit. >>>> >>>> To prevent users from bypassing censorship requirements, debian will >>>> need to switch to being a binary-only distribution with signed >>>> binaries, signed kernel, and signed kernel modules, with mandatory >>>> secureboot, and controls to prevent any non-signed software from being >>>> installed, written, or compiled, as any foreign sources of software may >>>> fail to query systemd-censord or may fail to respect the permissions it >>>> returns. >>>> >>>> On the non-software side, the debian licenses will need to be modified >>>> to disallow removal or alteration of any of these features by >>>> derivative distributions – for example, no distribution will be allowed >>>> to ship without systemd because then systemd-censord may not work >>>> correctly. In addition, the licenses for all packaged software will >>>> need to be amended to disallow removal of censorship functionality. >>>> >>>> As I’m sure is obvious, if debian is going to comply with government >>>> censorship regulations, a universal framework allowing easy addition of >>>> new rules will greatly reduce developer time over individual ad-hoc >>>> implementations of each new freedom restriction. Complying with only >>>> one regulation, such as California’s attempts to prevent minors from >>>> accessing unapproved information, makes no sense when there’s hundreds >>>> or thousands of other regulations not currently being complied with. >>>> This framework should ensure all users get to experience their full >>>> censorship regime no matter where they are in the world. >>>> >>>> Thanks for reading, and I hope we can work together to help Linux >>>> implement as much censorship as possible! >>>> --Floofy Wolf >>> >>> Nice work! >>> >>> I would agree with encrypting systemd-censord, but *how* to decrypt it, I >>> have an idea for. It requires /etc/machine-id, AppArmor or SELinux, FDE, >>> and a new *specially* compiled kernel module. Feel free to critique it >>> and give me new ideas. >>> >>> Starting off, /etc/machine-id is generated upon new installations with >>> systemd-firstboot, and it is unique to all systems. This means it can be >>> used as a shared key along with a unique salt to prevent rainbow table >>> attacks. This would be pretty bad for anyone to see publicly, so now we >>> have to come up with a solution. >>> >>> My solution to this is FDE with TPM2, a kernel module, and an MAC. >>> Firstly, all systems must have FDE with TPM2 from hereon. Any system that >>> hasn't had it before is now an unsupported configuration. Secondly, the >>> new kernel module is included in the initramfs so that it can start >>> reading /etc/machine-id after root is mounted, but before any MAC can do >>> anything to prevent it from being seen. Finally, the kernel module >>> decrypts systemd-censord using the machine-id and salt, runs it, and >>> encrypts it again. For good measure, AppArmor or SELinux would hide >>> systemd-censord and the kernel modules. >>> >>> This is not fully concrete, but I believe this is a starting point. I am >>> fully open to other ideas. >>> >>> Cheers, >>> >>> -- >>> Artur Manuel >>> amadaluzia >>> >>> -- >>> ubuntu-devel mailing list >>> ubuntu-devel(a)lists.ubuntu.com >>> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> >> > -- Jamie Null (They/Them) E: Lav(a)lavender.earth Attn: Key EC31 8C72 C7CB 900E A0FC is revoked as of 2026-01-29T08:30Z. "A person cannot be made to suffer a grossly disproportionate punishment simply to send a message to discourage others from offending." — R v. Nur, 2015 SCC 15, [2015] 1 S.C.R. 773, per McLachlin CJ, at para 45

1 0

13yo kids contribution to Fedora project
by Sandro Bonazzola 12 Mar '26

12 Mar '26

Hi, I sent initially to legal(a)fedoraproject.org but then I saw this list so perhaps it was the wrong address. My daughter is 13 years old, based in Italy, and would like to collaborate with Fedora Design team on the wallpapers design. She is already 13 so she should be fine according to https://docs.fedoraproject.org/en-US/legal/privacy/#_our_commitment_to_chil… But when she tried to register for her Fedora account, the system is asking to confirm she's at least 16yo. There's no indication that the checkbox is going to have legal implications and the hint there is that you must check the box if you want to continue. The temptation to just check the box and go ahead without asking has been pretty high but then she stopped and asked me. Is there a way for me as her parent to approve the creation of a Fedora account allowing her to contribute directly? I can proxy her contributions and give her credit on the submissions but will be more motivating for her being recognized directly for her work. Thanks,

4 3

Re: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states
by Aaron Rainbolt 10 Mar '26

10 Mar '26

On Mon, 09 Mar 2026 19:39:52 -0600 "Jeremy Soller" <jeremy(a)system76.com> wrote: > Hello everyone, > > My name is Jeremy Soller, and I am Principal Engineer at System76. We > released a statement on Age Verification laws last Thursday that you > can read here: > > https://blog.system76.com/post/system76-on-age-verification > > Our Founder and CEO, Carl Richell, was able to get a meeting with > Senator Matt Ball today to discuss the Colorado version of the > California bill, SB26-051. His statements after the meeting are as > follows: > > https://floss.social/@carlrichell@fosstodon.org/116201429734101067 Wow, this is great to see! Thank you (both you and Carl) for doing this, and for letting us know! -- Aaron > > Today, I met with Colorado Senator Matt Ball, co-author of Colorado > > OS Age Attestation Bill SB26-051. > > > > Sen. Ball suggested excluding open source software from the bill. > > This appears to be a real possibility. > > > > Amendments are expected for the CA age attestation bill. It's my > > hope we can move fast enough to influence excluding open source in > > the CA bill amendments. > > > > No illusions, it's an uphill battle, but we have an open door to > > advocate for the open source community. > > At this time, we are seeing what kinds of changes might be made to > these laws before they become effective. I would not generally advise > working on any technical solution when the laws are ambiguous and > likely to be amended. In the best case, although I believe it is > unlikely, open-source operating systems would not have any work to do > at all. In the worst case, different jurisdictions may have > conflicting laws. > > We and our users greatly value our privacy, and I would hope not to > see over-eager work on a technical implementation that is heavy > handed and potentially jurisdiction specific. We at System76 are also > awaiting the legal opinions of other operating systems, like Ubuntu, > and those would likely be valuable to all potentially affected > operating systems. > > Thank you, >

1 0

go-tpm-tools, TCGL, and concatenated upstream LICENSE
by Stuart D Gathman 06 Mar '26

06 Mar '26

Submitting smallstep ACME CA, a go project, https://bugzilla.redhat.com/show_bug.cgi?id=2418762 I ran into a license problem/question. A dependency is https://github.com/google/go-tpm-tools This module concatenates several submodule licenses into a single LICENSE file: https://github.com/google/go-tpm-tools/blob/main/LICENSE There is a divider, and it includes the LICENSE for a submodule, simulator/ms-tpm-20-ref I have two questions at the end. Here is the background. This submodule is NOT included in the vendored code for the Fedora package. But naturally, askalono objects to the concatenated license file. I split the LICENSE file up into the parts marked by dividers. The license it labels proprietary is the Trusted Computing Group License. It seems innocuous to me, but IANAL. The Microsoft BSD license says "no patent licenses are granted", but askalono doesn't object. It gets more complicated. There are several dividers. The first divider says -------- Microsoft simulator code (in simulator/ms-tpm-20-ref) uses the following licenses: -------- To me, this says ALL the following licenses are for simulator/ms-tpm-20-ref - and since that submodule is not included, we should be legally able to ignore them. However the plain English reading doesn't always apply with lawyers. Later on, another divider says -------- A portion of the source code is derived from the TPM specification, which has a TCG copyright. It is reproduced here for reference. -------- So, MAYBE "the source code" refers to ms-tpm-20-ref, or MAYBE to the go-tpm-tools module as a whole. It depends on whether the divider grammar is left associative or right associative. Questions: 1. Is the TCGL possibly an ok license that could be approved, and thus make the next question moot? 2. If lawyers agree that TCGL applies to the ms-tpm-20-ref submodule (which is NOT included in the vendored source or package), then what is the best way to allow this and document why? Modifying the upstream LICENSE is frowned upon.

2 2

Re: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states
by Aaron Rainbolt 04 Mar '26

04 Mar '26

On Tue, 3 Mar 2026 15:56:03 +0100 Aigars Mahinovs <aigarius(a)gmail.com> wrote: > There is more. A casual look around the legal landscape also uncovers > this law in Brazil: > https://www.planalto.gov.br/ccivil_03/_ato2023-2026/2025/Lei/L15211.htm > and France also has some related laws: > https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000045287677 > > IANAL, but IMHO the requirements from Debian/Ubuntu side *could* be > fulfilled if there is a package implementing the requested > functionality (setting of age/birth year for specific accounts and > then communicating relevant age brackets to the app requesting that). > That package would be "part of" the operating system, even if the > installer chooses not to download full installation images or chooses > not to install ALL available Debian packages. As long as the > installation and configuration is easy enough to do for a concerned > parent from packages *in the main package archive*, then it could be > argued that compliance is provided. In the end it is up to the > admin/installer of the device to configure it correctly for the > users. This also solves the privacy concerns as the admin of the > system opts in to using these restrictions explicitly when adding age > setting to the new user accounts. Also privacy laws typically are > expected to step aside to the explicit requirements of other laws to > function. So if a child protection law says that the age bracket of > the child *must* be provided/transmitted, then privacy law can not > forbid doing so (unless stated in that law explicitly). > > Naturally this API needs to be agreed on on a cross-distribution > layer, for example in the Freedesktop.org context. > > However, these questions are IMHO more important in contexts where > there is already a large exposure to system users in the affected age > brackets and also in the affected jurisdictions. And that is why I > added the Debian-Edu mailing list to the CC here. A typical > school-wide Debian Edu installation would have thousands of accounts > for individual children attending the school, they'd be in different > age brackets and they'd graduate from one bracket to the next really > often. Too often for manual actions at those stages to be viable. > Additionally, if there is an actual policy attention to Debian > installation in the context of such laws, then installations in > schools are likely to be among the first to be looked at. > > With the above in mind, thinking technically, IMHO the correct way > would be to have a field for date of birth for user accounts > (potentially shortened down to MM-YYYY or YYYY) and an API that (on > request) reads that value, reads the pre-configured jurisdiction (or > jurisdiction configuration) and returns the age bracket value. Keep > in mind that this date of birth information may already be coming > into the system from LDAP, MS Active Directory or similar external > account management systems. It *might* be acceptable to have the API > only work if users are authenticated via a supported account > management system with a defined dateOfBirth attribute, but then > distributions should really provide an easy way for a parent to be > able to set up and maintain such a system locally. I think the idea you're thinking of may make sense for Debian, however I would like to reinforce that for Whonix in particular, storing an exact birth date anywhere on the system (encrypted or otherwise, locked to the root account or not) is unacceptable because of its potential use in fingerprinting the user of an infected system. Our goals and an educational institution's goals in this regard are going to be diametrically opposed, so there is no way to work at this "depth" and come up with a solution that works for everyone. That isn't to say your idea is bad at all; it's a great idea for one implementation of an eventual specification. The specification simply needs to leave room for implementations that do the exact opposite. That's why I was using org.freedesktop.FileManager1 as a sort of "base" - the spec for it defines an API that anyone can implement, and implementations can (and in practice do) provide services via that spec that behave in all manner of different ways under the hood, some of which result in different user-facing behavior. That's the kind of spec I think will work best here, since it means schools can have an age tracking system that allows for automatic age bracket updates and harvesting of information from existing sources, and Whonix can save the age bracket somewhere and then never touch it again unless the user chooses to update it. -- Aaron > So a question to Debian EDU developers - are you aware of the > age-reporting laws and maybe of the work already in progress to > address the concerns these laws raise? > > > On Sun, 1 Mar 2026 at 20:48, Aaron Rainbolt <arraybolt3(a)gmail.com> > wrote: > > > Given that this is related to legal stuff, I should preface this by > > saying I am not a lawyer. > > > > Recently, a new law was passed in California that requires OS > > vendors to provide some limited info about a user's age via an API > > that application distribution websites and application stores can > > use. [1] Colorado seems to be working on a similar law. [2] The law > > will go into effect January 1, 2027, it is no longer a draft. I do > > quite a bit of work with an OS vendor (working with the Kicksecure > > [3] and Whonix [4] projects), and we aren't particularly interested > > in blocking everyone in California and Colorado from using our > > OSes, so we're currently looking into how to implement an API that > > will comply with the laws while also not being a privacy disaster. > > Given that other distributions are also investigating what to do > > with this, and the law requires us to make a "good faith effort to > > comply with [the] title, taking into consideration available > > technology", I figured it would be a good idea to bring the issue > > here. > > > > At its core, the law seems to require that an "operating system" > > (I'm guessing this would correspond to a Linux distribution, not an > > OS kernel or userland) request the user's age or date of birth at > > "account setup". The OS is also expected to allow users to set the > > user's age if they didn't already provide it (because the OS was > > installed before the law went into effect), and it needs to provide > > an API somewhere so that app stores and application distribution > > websites can ask the OS "what age bracket does this user fall > > into?" Four age brackets are defined, "< 13", ">= 13 and < 16", ">= > > 16 and < 18", and ">= 18". It looks like the API also needs to not > > provide more information than just the age bracket data. A bunch of > > stuff is left unclear (how to handle servers and other CLI-only > > installs, how to handle VMs, whether the law is even applicable if > > the primary user is over 18 since the law ridiculously defines a > > user as "a child" while also defining "a child" as anyone under the > > age of 18, etc.), but that's what we're given to deal with. > > > > The most intuitive place to put this functionality would be, IMO, > > AccountsService. The main issue with that is that stable-release > > distributions, and distributions based upon them, would be faced > > with the issue of how to get an updated version of AccountsService > > integrated into their software repositories, or how to backport the > > appropriate code. The law goes into effect on January 1, 2027, > > Debian Bookworm is going to be supported by ELTS until July 30, > > 2033, and we don't yet know if Debian will care enough about > > California's laws to want to backport a new feature in > > AccountsService into Debian Bookworm (or even Trixie). > > Distributions based on Debian (such as Kicksecure and Whonix) may > > still want to comply with the law though, so something using > > AccountsService-specific APIs would be frustrating. Requiring a > > whole separate daemon for the foreseeable future just for an age > > verification API would also be annoying. > > > > Another place the functionality could go is xdg-desktop-portal. This > > one is a bit non-ideal for a couple of reasons; for one, the easiest > > place to put the call would be in the Account portal, which returns > > more information than the account's age bracket. This could > > potentially be considered non-compliant with the law, as it states > > that the operating system shall "[s]end only the minimum amount of > > information necessary to comply with this title". This also comes > > with the backporting disadvantages of an AccountsService-based > > implementation. > > > > For this reason, I'd like to propose a "hybrid" approach; introduce > > a new standard D-Bus interface, `org.freedesktop.AgeVerification1`, > > that can be implemented by arbitrary applications as a distro sees > > fit. AccountsService could implement this API so that newer versions > > of distros will get the relevant features for free, while distros > > with an AccountsService too old to contain the feature can > > implement it themselves as a stop-gap solution. > > > > Taking inspiration from the File Manager D-Bus interface [5], I > > think something like the following might work: > > > > <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object > > Introspection 1.0//EN" > > "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> > > <node name="/org/freedesktop/AgeVerification1"> > > <interface name="org.freedesktop.AgeVerification1"> > > <method name="SetAge"> > > <arg type="s" name="User" direction="in"/> > > <arg type="u" name="YearsOfAge" direction="in"/> > > </method> > > <method name="SetDateOfBirth"> > > <arg type="s" name="User" direction="in"/> > > <arg type="s" name="Date" direction="in"/> > > </method> > > <method name='GetAgeBracket'> > > <arg type="s" name="User" direction="in"/> > > <arg type="u" name="AgeBracket" direction="out"/> > > </method> > > </interface> > > </node> > > > > * The 'User' argument would, in all instances, be expected to be the > > UNIX account username of the user in question. This user account > > must not be a system account (i.e. its UID must fall between > > UID_MIN and UID_MAX as defined by /etc/login.defs). If a user is > > specified that does not exist or whose UID is out of range, these > > methods will return the error > > 'org.freedesktop.AgeVerification1.Error.NoSuchUser'. If the > > specified user is not the same as the user making the method call, > > and the user making the method call is not root, these methods will > > return the error > > 'org.freedesktop.AgeVerification1.Error.PermissionDenied'. > > * The 'YearsOfAge' argument of the 'SetAge' method should be an > > unsigned integer specifying the age of the user in years at the > > time of the method call. (The law specifically allows providing > > simply an age value rather than a birth date if desired.) > > * The 'Date' argument of the 'SetDateOfBirth' method should be a > > string in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on > > which the user was born. If the argument is invalid, the method > > will return the error > > 'org.freedesktop.AgeVerification1.Error.InvalidDate'. > > * The 'AgeBracket' output argument of the 'GetAgeBracket' method > > will be an unsigned integer between 1 and 4 inclusive, where 1 > > indicates that the user is under 13 years old, 2 indicates that the > > user is at least 13 and under 16 years old, 3 indicates that the > > user is at least 16 and under 18 years old, and 4 indicates that > > the user is 18 years old or older. If no age has been configured > > for the user yet, the method will return the error > > 'org.freedesktop.AgeVerification1.Error.AgeUndefined'. > > > > I propose that the exact way in which age information is stored by > > the daemon should be left implementation-defined. For Kicksecure, > > the way we implement it will almost certainly store only the age > > bracket and require users to explicitly reconfigure their age once > > they are old enough to move from one age bracket to another. Other > > implementations may choose to store the date of birth or the age > > and date on which the age was set so that they can automatically > > update the age bracket as time passes. This interface will be > > provided *on the system bus* (NOT the session bus!), and the D-Bus > > service that provides these services should run as root. The file > > containing the user-to-age mappings should be owned by root and > > should not be world-readable, to prevent leaking the user's > > specific age to malicious applications. > > > > Some things I did think about when writing the above but ultimately > > decided to not propose: > > > > * Detailed permission gating for the 'GetAgeBracket' method. The > > only reason to do this would be for additional privacy, and > > privacy-conscious users can simply lie about their age or the age > > of the intended user. There isn't anything in the law (that I can > > tell) that prevents the user from just saying "I'm 18" when the > > prompt appears and going with it. This would also be really > > difficult to implement outside of the context of > > xdg-desktop-portal, and would probably only work with sandboxed > > apps if it was implemented that way. > > * UX for actually requesting the age from the user. IMO this is out > > of scope for FreeDesktop; individual distros should see to it that > > they prompt for the user's age or birth date at "account setup" > > (whatever that happens to be defined as for the distro in > > question), nudge the user to provide the information later on for > > existing installations, etc. Furthermore, this mechanism needs to > > work even on CLI-only installs and maybe even on server installs, > > depending on how one defines "general purpose computing device" (as > > specified by the law in question), so defining any specific UX is > > likely infeasible. (If this is required on servers, end-users will > > probably want to auto-provision the age information somehow, and > > specifying how to do that in a distribution-agnostic way is > > impossible given that Ubuntu uses cloud-init, Fedora uses Kickstart > > and Ignition, etc.) > > * Omitting the 'SetDateOfBirth' method. It can be lived without > > legally, but without the method, it becomes difficult for software > > that already records the user's date of birth to accurately > > implement automatic age bracket adjustment as time passes. This > > isn't a feature Kicksecure would use, but it's a feature some > > projects might be interested in. > > > > Thanks for taking a look at this. > > > > -- > > Aaron > > > > [1] > > https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=20252… > > [2] https://leg.colorado.gov/bill_files/110990/download > > [3] https://www.kicksecure.com/ > > [4] https://www.whonix.org/ > > [5] > > https://www.freedesktop.org/wiki/Specifications/file-manager-interface/ > > -- > > ubuntu-devel mailing list > > ubuntu-devel(a)lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > >

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal March 2026