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 the Senate concurred with the House amendments 25-8. Governor Polis signed it on June 3, 2026, and it is now codified as Chapter 343 of the 2026 session laws [Updated June 2026] (Colorado Politics). Buried in the House amendments is the language that drew open-source maintainers in: an exemption for software distributed under licenses that let anyone “copy, redistribute, and modify” it without restriction, alongside carve-outs for code repositories and apps shipped from 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 enacted text does soften the edges: OS providers and app stores that make a good-faith effort to comply are shielded from liability for an erroneous age signal or for a third-party developer’s downstream conduct [Updated June 2026]. That safe harbor matters for the platforms doing the implementation work, but it does nothing for a maintainer trying to decide whether the statute reaches their project at all.
The compliance timeline is delayed and staggered. The operative date is July 1, 2028, when the age-signal obligations begin to apply to new users; existing users get folded in by January 1, 2029 [Updated June 2026] (Colorado Politics). An earlier draft floated a January 1, 2028 start; the enacted version pushed the headline date back six months (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. The result is not one exemption but a stack of them [Updated June 2026]. The broadest exempts any operating-system provider or developer that distributes software under license terms letting recipients “copy, redistribute, and modify the software without restrictions.” That is a license test, and it tracks the free-software definition closely enough to cover Linux distributions and OSI-licensed apps as a class without naming a single project (The Register). Layered on top are structural carve-outs: code-repository providers like GitHub and GitLab, apps shipped from a “free, publicly available code repository,” and containerized distribution through Docker or Podman are all kept out of the “covered application store” definition (Slashdot).
The license test is the cleaner of the two, and it does most of the analytical work. A project whose license actually permits unrestricted copy, redistribution, and modification is covered no matter where it is hosted. A project whose license restricts any of those three is not, no matter how public its repository looks. That distinction matters more than the repository wording, because it is the part that maps onto how licenses are written rather than where bytes happen to live.
The word “free” in the repository clause is still 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 pressure was not only anonymous forum traffic [Updated June 2026]. Carl Richell, the founder of Linux PC vendor System76 and the steward of Pop!_OS, spent weeks lobbying Colorado lawmakers and testified before the House Business Affairs and Labor committee on April 23, 2026. His argument was less about penalties than about access: an age-attestation layer that can block app interaction or gate root access would, in his framing, undermine the way people learn computing, since open source is “the best way to learn” by reading and modifying real systems (OpenSourceForU). When the committee adopted the amendments, Richell posted on Fosstodon that the result was “a strong exemption for open source distros and apps.” That a hardware vendor with a paid lobbying effort, rather than the median HN commenter, moved the language is worth keeping in mind when reading how the exemption is scoped.
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.” Here the enacted license test cuts against them more cleanly than the repository wording would [Updated June 2026]. SSPL and BSL both restrict redistribution or modification (BSL gates production use until a change date; SSPL attaches conditions to offering the software as a service), so they fail the “copy, redistribute, and modify without restrictions” standard on its face. The repository clause might have let a source-available project argue it was hosted in a “free, publicly available code repository” and therefore exempt. The license clause closes that door. A source-available vendor that wants Colorado’s exemption would have to relicense, not just rehost.
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.
The nearest comparison is California’s Digital Age Assurance Act (AB 1043), the bill SB051 was modeled on, which takes effect January 1, 2027, a full eighteen months before Colorado’s obligations begin. California’s version has no equivalent open-source language: there is no license test and no repository carve-out, so the age-signal obligation attaches to an OS or app store regardless of revenue model or license. For a maintainer who ships nationally, that earlier and stricter California deadline is the one that bites first, and Colorado’s exemption offers no cover for it. A separate reading of the same Colorado statute notes that even within SB051 the protection for non-commercial projects leans on an untested “commercial basis” qualifier rather than a clean open-source definition; the two analyses, the license-and-repository carve-out covered here and the commercial-basis reading, are best read together, because the statute contains both kinds of language and a court could lean on either.
The license test also raises a question that source-available vendors already know well: a “copy, redistribute, and modify without restrictions” standard is exactly the boundary that separates an OSI-approved license from the SSPL/BSL family, the same fault line that governs self-hosting and redistribution rights for model weights. Statutes that pin compliance to a license’s redistribution terms are, in effect, importing decades of license-taxonomy arguments into regulatory law, and the people best equipped to litigate them are the same ones who spend their time arguing about license compatibility on mailing lists.
What maintainers should do before 2028
Obligations begin July 1, 2028 for new users, with existing users folded in by January 1, 2029 [Updated June 2026]. 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 against the actual test. The enacted exemption turns on whether your license lets recipients copy, redistribute, and modify without restriction, so a permissive or copyleft OSI license is the safe case [Updated June 2026]. SSPL, BSL, and custom source-available licenses restrict at least one of those three and fail the test on its face; rehosting will not fix that, only relicensing will.
Treat the law as live. Governor Polis signed SB051 on June 3, 2026, so the veto question is settled and the 2028 timeline is no longer hypothetical [Updated June 2026]. The window now is for relicensing, restructuring distribution, or documenting non-commercial status, not for waiting to see whether the bill becomes law.
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 open-source exemption in SB051 is a genuine concession extracted by maintainer pushback, and the license-based version that made it into law is better drafted than the repository sentence that started the fight. It is also one state’s law, now signed but untested, with no controlling interpretation of where “without restrictions” or “free” actually bites. Treat it as a signal that legislatures will listen to technical communities when a credible advocate shows up, not as a guarantee that the next bill will carry the same language.
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.
