DoesItAgeVerify: an OS by OS ledger of age verification law compliance

Two files, no build, nothing to install

The repository contains exactly two entries at the top level: `LICENSE` and `README.md`. There is no source directory, no package manifest, no test suite, no CI configuration and no release history. The project declares no primary language and has no homepage.

That means the usual adoption questions have no answers. There is no install command to copy, because there is nothing to install. There is no API, no CLI, no configuration file and no data format beyond Markdown tables. The README does not describe a machine readable version, a JSON export, a schema for new entries or a contribution process.

So the honest framing is this: it is a published document inside a Git repository, licensed under BSD-2-Clause and versioned through Git history. If you want to track it, the entire workflow is clone it and read the file, or watch the repository and read the diff when it changes. The value of the Git substrate is real but narrow: you can see who changed a row, when, and what the previous claim was.

The last push was on 2026-08-03. The page describes itself as "a running list", and that word choice sets the expectation correctly. It is updated when someone has reason to update it, which is driven by legislative and developer news rather than by a schedule.

The four status categories do most of the work

The taxonomy is the actual contribution here, and it is more careful than a binary compliant or not compliant split would be. The README sorts operating systems into four states, each with a different icon in the first table column so the list scans quickly.

The first category is operating systems not implementing age verification. It is the largest group, and the entries are mostly Linux distributions plus a few adjacent systems: Omarchy Linux, Devuan Linux, Slackware Linux, Zorin OS, Lunduke Computer OS, Vendefoul Wolf Linux, GrapheneOS, FreeDOS, Artix Linux, DB48X, Arch Linux 32, Ageless Linux, Garuda Linux, Void Linux, EndeavorOS Linux, GhostBSD and Parrot OS. The stated reason is either a developer decision not to implement, or a decision to restrict access in regions where such laws exist.

The second is planning to implement, which is explicitly not the same as implemented. The README states that these publishers have made plans or statements of intent, but that the functionality is not fully implemented as yet. Microsoft Windows, Google Android and Google ChromeOS sit here alongside Ubuntu, Pop!_OS, elementary OS, Fedora and Debian. Pop!_OS is the most nuanced entry, noted as a System76 statement opposing the requirement but planning to implement it anyway.

The third category is an uncertain future, described as statements that are confusing, nebulous, or that suggest a distribution may or may not ship with age verification. CachyOS, MX Linux, Solus and AlmaLinux sit in that bucket.

The fourth is what has actually shipped: Apple macOS, Apple iOS, and Midnight BSD, which is noted as having added age attestation by default while its licence temporarily forbids use in Brazil and California.

The law list is as contested as the OS list

Above the operating system tables, the README tracks legislation in three states, each linking out rather than describing.

Passed laws listed are Brazil, California, Illinois and Colorado. Proposed are two U.S. federal bills and New York. Withdrawn is Michigan.

Every one of those entries is a link to a post on x.com rather than to a statute, a bill number or a legislative page. The README does not give bill identifiers, section numbers, effective dates or any legal text, and it offers no link to the withdrawn Michigan measure beyond the post that mentions it.

This matters for how you use the page. A reader who needs to know whether a duty actually applies to a particular distribution cannot resolve it from this document, because the citations are social media posts rather than primary sources, and the README makes no attempt to distinguish a enacted statute from a signed executive action or an amendment to existing code.

The same citation pattern runs through the operating system tables. Rows link to "Developer statement" posts, one mailing list archive for Ubuntu devel, one System76 blog post, one Mastodon post from the elementary OS founder, and one GitHub repository for Lunduke Computer OS. So the underlying evidence is public statements by identifiable people, which is a reasonable basis for a tracker, and it is also the kind of evidence that ages badly and is easy to misquote.

Where this tracker is the wrong tool

If you need to make a compliance decision, this page is not sufficient. It does not cite statutory text, it does not define what "age verification" or "age attestation" must technically do, and it does not distinguish an operating system feature from an application layer service that happens to run on it. A distribution that does not implement an OS level check may still ship a browser that performs one, and the README does not address that at all.

If you need software, there is none. There is no way to query this data, no way to subscribe to a feed of changes through anything other than the Git hosting platform's notifications, and no way to detect a stale row. Every consumer must scrape Markdown tables.

If you are a distribution maintainer listed as planning to implement, the workflow for getting your status corrected is undocumented. The repository has no CONTRIBUTING file, no issue template and no stated contact. Corrections appear to rely on the author finding a statement and editing the README, and since nearly every source is a social post, a deleted post would silently invalidate a row.

There is also a question of completeness that the page cannot answer about itself. The absence of a distribution from the list is not evidence that it has taken no position. Some well known systems appear and others do not, and no selection criteria are given.

How it compares to reading the statements yourself

The alternative is not another tracker, it is the primary material: the developer statements, the System76 blog post, the Ubuntu devel mailing list thread, and the text of the legislation in each jurisdiction.

That route gives you accuracy and costs you aggregation. Reading a hundred social posts and reconciling them into "which distributions have taken what position" is exactly the work this repository has already done, and doing it once a month by hand is a poor use of anyone's time. The tracker earns its place by doing the tedium and by keeping a dated record in Git of when each row last changed.

A third option, closer in spirit, is tracking the legislation itself rather than vendor responses. Jurisdictional trackers exist that carry bill numbers, committee stage and effective dates. Those answer the prior question, whether a duty exists, with far better sourcing than a list of x.com posts. What this repository adds is the layer above: what each vendor says they will do about it.

Used that way the two are complementary, and the failure mode is treating the vendor layer as if it had the legal layer's authority.

Licence, licence, and what BSD-2-Clause buys you here

The repository is under BSD-2-Clause, a permissive licence with two clauses and the standard disclaimer of warranty. For a Markdown document that means you may copy the content, modify it, and redistribute it, including inside a commercial product, subject to the applicable notice obligations.

Two practical consequences follow. First, you can take the tables and fold them into your own documentation, a slide, or an internal wiki page, and keep using them, as long as the BSD notice travels with the material. Second, the licence says nothing about the truth of the content. Anyone republishing these claims inherits no warranty from the author, which matters more than usual here because the claims are attributed statements about real named projects.

Note also that one row in the implemented table is about a licence restriction: Midnight BSD is described as having a licence that temporarily forbids usage in Brazil and California while age attestation was added by default. That is a different kind of legal change from anything the BSD-2-Clause licence of this tracker covers, and it is the kind of detail that a list format handles poorly since one row is carrying both a technical implementation and a legal restriction.

If you maintain a downstream copy of this list, expect to prune. A tracker whose rows depend on social posts ages in months, and the Git history is the only mechanism here for noticing that a row went stale.

Editorial conclusion

Adopt this repository as a research starting point if you need to know which distributions have taken a position on OS level age verification and who published that position, and expect to verify every entry yourself before relying on it. Do not treat it as software, do not automate anything from it, and do not use it as compliance evidence, because the licence covers a Markdown file and nothing enforces the accuracy of the entries. Verify first that the row you care about still has a live citation, since the list only changes when someone edits the README and the last push was on 2026-08-03.

Frequently asked questions

Official sources

1. BryanLunduke/DoesItAgeVerify on GitHub
2. Issues
3. License: BSD-2-Clause
4. README