Re: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states
Marcia Wilbur <[email protected]> Mon, 6 Apr 2026 13:39:52 -0400
| Newsgroups | gmane.linux.debian.devel.legal,gmane.linux.xdg.devel,gmane.linux.debian.devel.general,gmane.linux.redhat.fedora.devel,gmane.linux.ubuntu.devel,gmane.linux.redhat.fedora.legal |
|---|---|
| Message-ID | <CADp_D1_Qj4td4_NxAk2JpjO7WcDebG2HRtAJxetqZO4=qEWAmg@mail.gmail.com> |
--000000000000265535064ece2836 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, regarding the Operating system provider definition, if I have software that creates backups and creates custom distros, am I considered an operating system provider? I Maintain a tool that enables people to create their own operating systems and become an operating system provider, but in and of itself, I am not an =E2=80=9Coperating system provider=E2=80=9D. That being said, of course, I am interested in this discussion so I may relay information to those operating system providers. Marcia Wilbur On Sun, Mar 1, 2026 at 3:44=E2=80=AFPM Aaron Rainbolt <[email protected]= > wrote: > On Sun, 1 Mar 2026 15:12:09 -0500 > "Vincent F. Heuser Jr." <[email protected]> wrote: > > > On 2026/03/01 14:48 PM, Aaron Rainbolt 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", ">=3D 13 and < 16", ">= =3D > > > 16 and < 18", and ">=3D 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=3D"/org/freedesktop/AgeVerification1"> <interface > > > name=3D"org.freedesktop.AgeVerification1"> <method name=3D"SetAge"> > > > <arg type=3D"s" name=3D"User" direction=3D"in"/> > > > <arg type=3D"u" name=3D"YearsOfAge" direction=3D"in"/> > > > </method> > > > <method name=3D"SetDateOfBirth"> > > > <arg type=3D"s" name=3D"User" direction=3D"in"/> > > > <arg type=3D"s" name=3D"Date" direction=3D"in"/> > > > </method> > > > <method name=3D'GetAgeBracket'> > > > <arg type=3D"s" name=3D"User" direction=3D"in"/> > > > <arg type=3D"u" name=3D"AgeBracket" direction=3D"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=3D2= 02520260AB1043 > > > [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/ > > > > > > > By definition, not a Debian or Ubuntu problem: > > https://www.merriam-webster.com/dictionary/vendor > > I may have been incorrectly imprecise; the law linked says that "an > operating system provider shall" do the things needed to comply with > the title, and defines an operating system provider as "a person or > entity that develops, licenses, or controls the operating system > software on a computer, mobile device, or any other general purpose > computing device." "Vendor" is a term I mistakenly used, as far as I > can tell the law does not exclude operating systems that are offered > for free. Again though, as I stated, I am not a lawyer, so perhaps I'm > misunderstanding the meaning of the definition of "operating system > provider". > > -- > Aaron > --000000000000265535064ece2836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">So, regarding the Operating system provider definition, i= f I have software that creates backups and creates custom distros, am I con= sidered an operating system provider?=C2=A0</div><div dir=3D"auto"><span st= yle=3D"font-family:-apple-system,sans-serif">I Maintain a tool that enables= people to create their own operating systems and become an operating syste= m provider, but in and of itself, I am not an =E2=80=9Coperating system pro= vider=E2=80=9D.</span><br></div><div dir=3D"auto"><br></div><div dir=3D"aut= o">That being said, of course, I am interested in this discussion so I may = relay information to those operating system providers.</div><div dir=3D"aut= o"><br></div><div dir=3D"auto">Marcia Wilbur=C2=A0</div><div><br><div class= =3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr= ">On Sun, Mar 1, 2026 at 3:44=E2=80=AFPM Aaron Rainbolt <<a href=3D"mail= to:[email protected]">[email protected]</a>> wrote:<br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex">On Sun, 1 Mar 2026 15:12:09 -0500<br> "Vincent F. Heuser Jr." <<a href=3D"mailto:vheuser@heuserlawof= fice.com" target=3D"_blank">[email protected]</a>> wrote:<br> <br> > On 2026/03/01 14:48 PM, Aaron Rainbolt wrote:<br> > > Given that this is related to legal stuff, I should preface this = by<br> > > saying I am not a lawyer.<br> > ><br> > > Recently, a new law was passed in California that requires OS<br> > > vendors to provide some limited info about a user's age via a= n API<br> > > that application distribution websites and application stores can= <br> > > use. [1] Colorado seems to be working on a similar law. [2] The l= aw<br> > > will go into effect January 1, 2027, it is no longer a draft. I d= o<br> > > quite a bit of work with an OS vendor (working with the Kicksecur= e<br> > > [3] and Whonix [4] projects), and we aren't particularly inte= rested<br> > > in blocking everyone in California and Colorado from using our<br= > > > OSes, so we're currently looking into how to implement an API= that<br> > > will comply with the laws while also not being a privacy disaster= .<br> > > Given that other distributions are also investigating what to do<= br> > > with this, and the law requires us to make a "good faith eff= ort to<br> > > comply with [the] title, taking into consideration available<br> > > technology", I figured it would be a good idea to bring the = issue<br> > > here.<br> > ><br> > > At its core, the law seems to require that an "operating sys= tem"<br> > > (I'm guessing this would correspond to a Linux distribution, = not an<br> > > OS kernel or userland) request the user's age or date of birt= h at<br> > > "account setup". The OS is also expected to allow users= to set the<br> > > user's age if they didn't already provide it (because the= OS was<br> > > installed before the law went into effect), and it needs to provi= de<br> > > an API somewhere so that app stores and application distribution<= br> > > websites can ask the OS "what age bracket does this user fal= l<br> > > into?" Four age brackets are defined, "< 13", &= quot;>=3D 13 and < 16", ">=3D<br> > > 16 and < 18", and ">=3D 18". It looks like t= he API also needs to not<br> > > provide more information than just the age bracket data. A bunch = of<br> > > stuff is left unclear (how to handle servers and other CLI-only<b= r> > > installs, how to handle VMs, whether the law is even applicable i= f<br> > > the primary user is over 18 since the law ridiculously defines a<= br> > > user as "a child" while also defining "a child&quo= t; as anyone under the<br> > > age of 18, etc.), but that's what we're given to deal wit= h.<br> > ><br> > > The most intuitive place to put this functionality would be, IMO,= <br> > > AccountsService. The main issue with that is that stable-release<= br> > > distributions, and distributions based upon them, would be faced<= br> > > with the issue of how to get an updated version of AccountsServic= e<br> > > integrated into their software repositories, or how to backport t= he<br> > > appropriate code. The law goes into effect on January 1, 2027,<br= > > > Debian Bookworm is going to be supported by ELTS until July 30,<b= r> > > 2033, and we don't yet know if Debian will care enough about<= br> > > California's laws to want to backport a new feature in<br> > > AccountsService into Debian Bookworm (or even Trixie).<br> > > Distributions based on Debian (such as Kicksecure and Whonix) may= <br> > > still want to comply with the law though, so something using<br> > > AccountsService-specific APIs would be frustrating. Requiring a<b= r> > > whole separate daemon for the foreseeable future just for an age<= br> > > verification API would also be annoying.<br> > ><br> > > Another place the functionality could go is xdg-desktop-portal. T= his<br> > > one is a bit non-ideal for a couple of reasons; for one, the easi= est<br> > > place to put the call would be in the Account portal, which retur= ns<br> > > more information than the account's age bracket. This could<b= r> > > potentially be considered non-compliant with the law, as it state= s<br> > > that the operating system shall "[s]end only the minimum amo= unt of<br> > > information necessary to comply with this title". This also = comes<br> > > with the backporting disadvantages of an AccountsService-based<br= > > > implementation.<br> > ><br> > > For this reason, I'd like to propose a "hybrid" app= roach; introduce<br> > > a new standard D-Bus interface, `org.freedesktop.AgeVerification1= `,<br> > > that can be implemented by arbitrary applications as a distro see= s<br> > > fit. AccountsService could implement this API so that newer versi= ons<br> > > of distros will get the relevant features for free, while distros= <br> > > with an AccountsService too old to contain the feature can<br> > > implement it themselves as a stop-gap solution.<br> > ><br> > > Taking inspiration from the File Manager D-Bus interface [5], I<b= r> > > think something like the following might work:<br> > ><br> > >=C2=A0 =C2=A0 =C2=A0 <!DOCTYPE node PUBLIC "-//freedesktop= //DTD D-BUS Object<br> > > Introspection 1.0//EN"<br> > > "<a href=3D"http://www.freedesktop.org/standards/dbus/1.0/in= trospect.dtd" rel=3D"noreferrer" target=3D"_blank">http://www.freedesktop.o= rg/standards/dbus/1.0/introspect.dtd</a>"><br> > > <node name=3D"/org/freedesktop/AgeVerification1">= <interface<br> > > name=3D"org.freedesktop.AgeVerification1"> <metho= d name=3D"SetAge"><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <arg type=3D"s&q= uot; name=3D"User" direction=3D"in"/><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <arg type=3D"u&q= uot; name=3D"YearsOfAge" direction=3D"in"/><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </method><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <method name=3D"SetDate= OfBirth"><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <arg type=3D"s&q= uot; name=3D"User" direction=3D"in"/><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <arg type=3D"s&q= uot; name=3D"Date" direction=3D"in"/><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </method><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <method name=3D'GetAgeBr= acket'><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <arg type=3D"s&q= uot; name=3D"User" direction=3D"in"/><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <arg type=3D"u&q= uot; name=3D"AgeBracket" direction=3D"out"/><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </method><br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </interface><br> > >=C2=A0 =C2=A0 =C2=A0 </node><br> > ><br> > > * The 'User' argument would, in all instances, be expecte= d to be the<br> > >=C2=A0 =C2=A0 UNIX account username of the user in question. This = user account<br> > > must not be a system account (i.e. its UID must fall between<br> > > UID_MIN and UID_MAX as defined by /etc/login.defs). If a user is<= br> > > specified that does not exist or whose UID is out of range, these= <br> > > methods will return the error<br> > > 'org.freedesktop.AgeVerification1.Error.NoSuchUser'. If t= he<br> > > specified user is not the same as the user making the method call= ,<br> > > and the user making the method call is not root, these methods wi= ll<br> > > return the error<br> > > 'org.freedesktop.AgeVerification1.Error.PermissionDenied'= .<br> > > * The 'YearsOfAge' argument of the 'SetAge' metho= d should be an<br> > >=C2=A0 =C2=A0 unsigned integer specifying the age of the user in y= ears at the<br> > > time of the method call. (The law specifically allows providing<b= r> > > simply an age value rather than a birth date if desired.)<br> > > * The 'Date' argument of the 'SetDateOfBirth' met= hod should be a<br> > > string in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on<= br> > > which the user was born. If the argument is invalid, the method<b= r> > > will return the error<br> > > 'org.freedesktop.AgeVerification1.Error.InvalidDate'.<br> > > * The 'AgeBracket' output argument of the 'GetAgeBrac= ket' method<br> > > will be an unsigned integer between 1 and 4 inclusive, where 1<br= > > > indicates that the user is under 13 years old, 2 indicates that t= he<br> > > user is at least 13 and under 16 years old, 3 indicates that the<= br> > > user is at least 16 and under 18 years old, and 4 indicates that<= br> > > the user is 18 years old or older. If no age has been configured<= br> > > for the user yet, the method will return the error<br> > >=C2=A0 =C2=A0 'org.freedesktop.AgeVerification1.Error.AgeUndef= ined'.<br> > ><br> > > I propose that the exact way in which age information is stored b= y<br> > > the daemon should be left implementation-defined. For Kicksecure,= <br> > > the way we implement it will almost certainly store only the age<= br> > > bracket and require users to explicitly reconfigure their age onc= e<br> > > they are old enough to move from one age bracket to another. Othe= r<br> > > implementations may choose to store the date of birth or the age<= br> > > and date on which the age was set so that they can automatically<= br> > > update the age bracket as time passes. This interface will be<br> > > provided *on the system bus* (NOT the session bus!), and the D-Bu= s<br> > > service that provides these services should run as root. The file= <br> > > containing the user-to-age mappings should be owned by root and<b= r> > > should not be world-readable, to prevent leaking the user's<b= r> > > specific age to malicious applications.<br> > ><br> > > Some things I did think about when writing the above but ultimate= ly<br> > > decided to not propose:<br> > ><br> > > * Detailed permission gating for the 'GetAgeBracket' meth= od. The<br> > > only reason to do this would be for additional privacy, and<br> > >=C2=A0 =C2=A0 privacy-conscious users can simply lie about their a= ge or the<br> > > age of the intended user. There isn't anything in the law (th= at I<br> > > can tell) that prevents the user from just saying "I'm 1= 8" when the<br> > > prompt appears and going with it. This would also be really<br> > > difficult to implement outside of the context of<br> > > xdg-desktop-portal, and would probably only work with sandboxed<b= r> > > apps if it was implemented that way.<br> > > * UX for actually requesting the age from the user. IMO this is o= ut<br> > > of scope for FreeDesktop; individual distros should see to it tha= t<br> > > they prompt for the user's age or birth date at "account= setup"<br> > > (whatever that happens to be defined as for the distro in<br> > > question), nudge the user to provide the information later on for= <br> > > existing installations, etc. Furthermore, this mechanism needs to= <br> > > work even on CLI-only installs and maybe even on server installs,= <br> > > depending on how one defines "general purpose computing devi= ce" (as<br> > > specified by the law in question), so defining any specific UX is= <br> > > likely infeasible. (If this is required on servers, end-users wil= l<br> > > probably want to auto-provision the age information somehow, and<= br> > > specifying how to do that in a distribution-agnostic way is<br> > > impossible given that Ubuntu uses cloud-init, Fedora uses Kicksta= rt<br> > > and Ignition, etc.)<br> > > * Omitting the 'SetDateOfBirth' method. It can be lived w= ithout<br> > >=C2=A0 =C2=A0 legally, but without the method, it becomes difficul= t for<br> > > software that already records the user's date of birth to<br> > > accurately implement automatic age bracket adjustment as time<br> > > passes. This isn't a feature Kicksecure would use, but it'= ;s a<br> > > feature some projects might be interested in.<br> > ><br> > > Thanks for taking a look at this.<br> > ><br> > > --<br> > > Aaron<br> > ><br> > > [1]<br> > > <a href=3D"https://leginfo.legislature.ca.gov/faces/billTextClien= t.xhtml?bill_id=3D202520260AB1043" rel=3D"noreferrer" target=3D"_blank">htt= ps://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=3D202520= 260AB1043</a><br> > > [2] <a href=3D"https://leg.colorado.gov/bill_files/110990/downloa= d" rel=3D"noreferrer" target=3D"_blank">https://leg.colorado.gov/bill_files= /110990/download</a> [3]<br> > > <a href=3D"https://www.kicksecure.com/" rel=3D"noreferrer" target= =3D"_blank">https://www.kicksecure.com/</a> [4] <a href=3D"https://www.whon= ix.org/" rel=3D"noreferrer" target=3D"_blank">https://www.whonix.org/</a><b= r> > > [5]<br> > > <a href=3D"https://www.freedesktop.org/wiki/Specifications/file-m= anager-interface/" rel=3D"noreferrer" target=3D"_blank">https://www.freedes= ktop.org/wiki/Specifications/file-manager-interface/</a><br> > >=C2=A0 <br> > <br> > By definition, not a Debian or Ubuntu problem: <br> > <a href=3D"https://www.merriam-webster.com/dictionary/vendor" rel=3D"n= oreferrer" target=3D"_blank">https://www.merriam-webster.com/dictionary/ven= dor</a><br> <br> I may have been incorrectly imprecise; the law linked says that "an<br= > operating system provider shall" do the things needed to comply with<b= r> the title, and defines an operating system provider as "a person or<br= > entity that develops, licenses, or controls the operating system<br> software on a computer, mobile device, or any other general purpose<br> computing device." "Vendor" is a term I mistakenly used, as = far as I<br> can tell the law does not exclude operating systems that are offered<br> for free. Again though, as I stated, I am not a lawyer, so perhaps I'm<= br> misunderstanding the meaning of the definition of "operating system<br= > provider".<br> <br> --<br> Aaron<br> </blockquote></div></div> --000000000000265535064ece2836--