The #1 mistake developers are making with the Colorado SB051 open source exemption: assuming that because their code is on GitHub, they’re automatically off the hook. They’re not. The exemption is tied to your license terms, not your hosting choice – and if your repo ships under a source-available license like BSL or SSPL, you may still be on the hook for up to $7,500 per Colorado minor who installs your app (per the enrolled bill text, May 2026).
This is the part nobody on Mastodon is explaining. The news drop is everywhere – System76 lobbied, the amendment landed, open source is “saved” – but very few posts walk through what the exemption clause actually says and how to check whether your project qualifies. So let’s reverse-engineer it.
What the Colorado SB051 exemption actually says
The bill, formally SB26-051 “Age Attestation on Computing Devices”, was sent to the Governor on May 12, 2026 after passing the Senate on House Amendments Concur 33-0. It focuses on operating system providers and application stores, requiring them to supply an age-related signal via an interface so applications can determine whether a user is a minor.
The amendment that’s blowing up right now does two distinct things, and they’re often conflated:
- OS / developer exemption. Article 30 does not apply to an operating system provider or developer that distributes software under license terms that let recipients copy, redistribute, and modify the software without restrictions from the provider or developer.
- Repo exemption. The amendment also excludes applications from free, public code repositories from being considered covered applications.
The amendment does not mention Linux by name – it’s a license test, not a brand list. That’s elegant, but it’s also where most devs get tripped up.
The license test, decoded
Strip away the legalese and the exemption asks one question: can anyone receiving your code legally copy it, redistribute it, and modify it without restrictions you impose? Three verbs, one qualifier. If you can answer yes to all three, you’re in.
| License | Copy | Redistribute | Modify w/o restriction | Likely exempt? |
|---|---|---|---|---|
| MIT, BSD, Apache 2.0 | Yes | Yes | Yes | Yes |
| GPL v2/v3, AGPL | Yes | Yes | Yes (copyleft is a condition, not a restriction on modification) | Yes |
| Business Source License (BSL) | Yes | Limited | Field-of-use restricted | No |
| SSPL, Elastic License v2 | Yes | Restricted commercial | Conditions on hosted use | No |
| Proprietary / EULA | No | No | No | No |
This is my reading of the text, not legal advice. The phrase “without restrictions” is doing heavy lifting here and a Colorado court hasn’t interpreted it yet. But if your license has a time-delay clause (BSL), a field-of-use clause (Elastic), or a “don’t compete with us” clause (SSPL), “without restrictions” is hard to argue with a straight face.
Think of the three-verb test like a building permit inspection – the inspector doesn’t care that you built a great structure. They check three boxes in order: foundation, wiring, plumbing. Fail one, fail all. Your license works the same way. You can pass “copy” and “redistribute” and still fail on “modify” the moment you add a field-of-use clause. The test isn’t complete; it’s sequential.
Step-by-step: figure out if your project qualifies
Here’s the walkthrough I wish someone had published instead of another news recap.
Step 1 – Find your actual LICENSE file
Not the README badge. The file. If you inherited a repo and there’s a mismatch between the badge, the package.json field, and the LICENSE file, that mismatch is your problem to fix before August.
Step 2 – Check it against the three-verb test
Copy, redistribute, modify – without restrictions. If you’re using one of the OSI-approved licenses, you’re almost certainly fine. The OSI’s own definition requires free redistribution and allowed modifications, which maps cleanly onto the bill’s language.
Step 3 – Check where you actually distribute
The second exemption – for apps from “free, public code repositories” – is what protects your binary downloads. Carl Richell of System76, who pushed for the amendment, named GitHub and GitLab as examples. But here’s the gotcha:
Pro tip: A Hacker News commenter pointed out that the GitHub Releases section might be argued to sit “outside the repository” itself. If you distribute compiled binaries only via Releases (and not via the source tree), a hostile reading could claim those binaries aren’t from a “free public code repository.” Until there’s case law, mirror your release artifacts somewhere unambiguous – your own download page and the repo, for example.
Step 4 – Audit your dependencies if you ship a bundled app
If your MIT-licensed app statically links a proprietary SDK, the bundled artifact you ship is not freely modifiable. The exemption is about what you distribute, not what’s upstream.
Common pitfalls devs are already hitting
I’ve been watching the threads since the amendment dropped, and the same misreadings keep coming up.
- “My repo is public on GitHub, so I’m exempt.” Public ≠ openly licensed. A public repo with an All Rights Reserved LICENSE file (or no LICENSE file at all, which defaults to all rights reserved) does not qualify.
- “This only affects Colorado, who cares.” According to The Register’s coverage (April 2026), similar bills are active in California, New York, Illinois, Louisiana, Texas, and Utah – and in Brazil. The Colorado language is already being treated as a template.
- “The penalty is small.” Per the enrolled bill text (May 2026): civil penalties run up to $2,500 for each minor affected by each negligent violation and up to $7,500 for each minor affected by each intentional violation, recovered by the attorney general. Multiply that by every Colorado minor who installed your app.
- “I need to integrate the age signal API right now.” Existing devices have until January 1, 2029 to comply – so the OS-side API doesn’t even need to exist in shippable form for years. Don’t panic-integrate against an API that’s not finalized.
Comparison: SB051 vs the alternatives you’ll soon face
SB26-051 is patterned off California’s AB1043 (per The Register’s April 2026 coverage), but the open-source exemption is what sets this version apart from the pre-amendment text and from many sibling state bills. Whether other states adopt equivalent exemptions as they copy the template is genuinely unknown – The Register’s reporting identifies the states with similar legislation but doesn’t confirm whether those bills carry matching OSS carve-outs. That’s worth watching.
Practical upshot: if you’re a small dev right now, the Colorado version is arguably the friendliest variant in the country – assuming the Governor signs it. Treat qualifying for this exemption as a useful step, not a permanent shield. The bill page is the authoritative source; news summaries lag the enrolled text.
Here’s the harder question nobody’s answered yet: what happens when a state with no OSS exemption copies Colorado’s template and drops the carve-out? Developers in those states would face the full weight of the age verification requirement, no matter how permissive their license. That scenario isn’t hypothetical – it’s the default outcome if the exemption language doesn’t travel with the bill. Worth monitoring as other state sessions open.
What to do this week
Three concrete actions. Open your repo, confirm the LICENSE file actually exists and is OSI-approved. If you’re on BSL or SSPL and serve any consumer userbase, talk to a lawyer before August about whether the bill’s signal API will reach you. And bookmark the official bill page – the enrolled text is the version that matters, not the news summaries.
FAQ
Does the exemption apply if I use AGPL?
Yes, by the plain reading. AGPL lets recipients copy, redistribute, and modify – the network-use disclosure obligation is a condition on distribution of modifications, not a restriction on modification itself.
I run a SaaS with an open-core repo and a closed paid tier. What now?
This is the murky zone the bill doesn’t explicitly address. Your open-source component, distributed via your public repo, should qualify on its own terms. But the closed paid tier you serve to consumers is a separate “application” in the bill’s framing – it’s distributed under proprietary terms, processes personal data, and isn’t coming from a free public code repository. Realistically, you need to evaluate each tier separately, and the paid tier probably isn’t exempt. If you have Colorado users, that side may need to integrate the age signal API once the OS-level infrastructure exists.
Has the Governor signed it yet?
As of this writing the bill was sent to the Governor on May 12, 2026 – signature status may have changed since. Check the official bill page before making any compliance decision based on this article.