Colorado SB051 requires operating-system providers to build an age-signal API that categorizes every user at account setup into one of four brackets (under 13, 13-15, 16-17, 18+). Covered applications must query that API in real time and restrict features accordingly. The bill passed the Senate 28-7, the House 40-23, and was sent to Governor Polis on May 12, 2026. Buried in the House amendments is a sentence that has open-source maintainers paying attention: an exemption for apps distributed through a “free, publicly available code repository.”
What SB051 actually requires
The core mechanism is an age-attestation interface built into the operating system itself. When a user creates or logs into an account, the OS transmits an age bracket to any “covered application” that requests it via a real-time API. Covered applications must then enforce age-appropriate design rules based on the bracket they receive.
The enforcement teeth are real. Negligent violations carry civil penalties up to $2,500 per affected minor; intentional violations up to $7,500 per minor, enforced by the state Attorney General (SB051 bill text).
The compliance timeline is staggered. The bill takes effect January 1, 2028. Existing devices must expose the age-attestation interface by July 1, 2028. Applications updated after July 1, 2027 on pre-2028 hardware must request age signals by January 1, 2029 (VulcanBills timeline).
Not everything is covered. The bill exempts apps that do not process personal data, enterprise software, internal business communication tools, broadband and telecommunications services, and technical support applications (BillTrack50 summary). These are the expected carve-outs for software that never touches a consumer in a social context.
How the open-source exemption works, and where it doesn’t
House amendments L.004, L.005, and L.006 moved through the House Business Affairs and Labor committee on April 23, 2026; L.008 passed on the floor April 29. Among them was language excluding apps distributed through a “free, publicly available code repository” from the definition of “covered application” (SB051 bill text).
The word “free” is doing unexamined work. Does it modify “repository” (GitHub is free to use), “code” (the source is gratis), or the project’s entire distribution model? The statute does not clarify. The practical difference matters.
A project hosted on GitHub under the SSPL or BSL license is source-available, not open source by the OSI definition. It is free to read and may be free to use under some conditions, but the license restricts deployment. Whether that project qualifies for the SB051 exemption depends on how a court reads “free” in the statutory text, and the bill provides no guidance (Mindbento HN aggregation).
What the maintainer backlash was about
The Hacker News discussion that prompted the amendment language centered on a straightforward concern: if you ship a consumer-facing app and publish the source, are you covered by age-verification law or not?
Maintainers pointed out that most open-source projects have no mechanism to verify user age, no appetite to build one, and no legal budget to interpret compliance. The idea that a solo maintainer’s side project could face $2,500-per-minor penalties for lacking an age gate struck commenters as both disproportionate and technically infeasible for volunteer-run software.
The Colorado legislature responded with the repository exemption. But the response was shaped by the loudest version of the concern: the GitHub-hosted, volunteer-maintained, no-revenue project. Projects that do not fit that profile were not the focus of the backlash, and the exemption language reflects that.
The dual-license and donation-funded gray zone
The exemption’s ambiguity creates three categories of projects that should not assume they are covered.
Dual-licensed projects. A project that offers a community edition under an OSI-approved license and a commercial edition behind a paid license lives on the same repository. The community edition looks “free.” The commercial edition does not. If the repository is the unit of exemption, the whole project might be covered. If the distribution channel is the unit, only the commercial channel is exposed. The bill does not say which reading controls.
Donation-funded projects. A project that accepts sponsorships, Patreon contributions, or GitHub Sponsors payments may be “free” in the software sense but commercial in the revenue sense. The statute does not define “non-commercial,” and state AG enforcement decisions are not known for their nuance around maintainer donation boxes.
Source-available projects. Projects under SSPL, BSL, or similar licenses that restrict deployment without restricting access to source code sit in the gap between “free” and “open.” They are not covered by the OSI definition of open source, but they are distributed through publicly available repositories. Whether they qualify depends on whether “free” is read as “no cost” or “unrestricted.”
SB051 in context
Colorado is not the first state to pass age-verification legislation, but SB051 appears to be the first to explicitly name code repositories in an exemption clause. Most state-level age-gating bills apply to “covered applications” or “social media platforms” in broad terms, with exemptions carved for specific industries (telecom, enterprise) rather than distribution models.
The open-source carve-out is notable precisely because it is unusual. If other states adopt similar bills without equivalent language, maintainers who ship consumer-facing software could face a patchwork of compliance obligations. Colorado’s exemption sets a precedent that open-source projects can cite in legislative comment periods elsewhere, but it does not bind any other jurisdiction.
What maintainers should do before 2028
The effective date is January 1, 2028, with a staggered compliance window extending to January 1, 2029 for updated apps on older devices. That is a long runway, but the compliance questions are architecture questions, and architecture decisions made now determine exposure later.
Audit your distribution model. If your only distribution channel is a public Git repository and you charge no fees, you likely qualify for the exemption. If you also distribute through app stores, package managers with telemetry, or paid channels, map each channel against the bill’s definition of “covered application.”
Check your license. OSI-approved licenses are the safest reading of “free.” If you use SSPL, BSL, or a custom license, the exemption’s coverage is uncertain until case law develops.
Watch for Governor Polis’s signature. The bill was sent on May 12, 2026 but has not been signed as of the available sources. If vetoed, the exemption dies with it. If signed, the 2028 timeline is live.
Track other state bills. Colorado’s language is not self-executing elsewhere. If you maintain software used nationally, one state’s exemption does not protect you from another state’s enforcement. The legislative session calendars for 2027 will matter more than Colorado’s 2026 text.
The repo-exemption sentence in SB051 is a genuine concession extracted by maintainer pushback. It is also a single sentence in a single state’s law, with ambiguous syntax and no controlling interpretation. Treat it as a signal that legislatures will listen to technical communities, not as a guarantee that the next bill will do the same.
Frequently Asked Questions
Does SB051 allow private lawsuits, or is enforcement limited to the Attorney General?
Enforcement is exclusively through the Colorado Attorney General. The bill creates no private right of action, which means individual users cannot sue over age-gating failures. That is narrower than several other state privacy statutes that permit both AG enforcement and private suits, and it limits the practical threat for maintainers to state-initiated action rather than class-action exposure.
Would distributing through npm, PyPI, or other package registries count as a ‘code repository’ under the exemption?
The statute does not define ‘code repository,’ and package registries occupy a different structural role than Git-hosting platforms. Registries like npm distribute packaged artifacts rather than necessarily exposing source code, and most require an account to publish. Whether a court would treat a registry as a ‘free, publicly available code repository’ is unresolved by the bill’s text.
How did the Senate vote on the House amendments that added the repository exemption?
The Senate concurred with the House amendments 25-8, a margin seven votes narrower than the original 28-7 Senate passage. The shift indicates some senators who supported the base bill did not back the amended version, though the legislative record does not isolate whether the OSS language or other House changes drove the dissent.
Who bears the technical burden: device manufacturers, OS vendors, or app developers?
The bill places the implementation burden on operating-system providers, requiring them to build and expose the age-signal interface. Covered apps must query that API but are not required to build independent age-verification systems. This is architecturally distinct from most other state age-gating bills, which place the verification obligation on each covered platform individually.