Debian Statement on the Cyber Resilience Act
EU plans for a Cyber Resilience Act, which would impose security and liability requirements on software “manufacturers,” are raising concerns among open-source developers and small businesses. Commenters broadly support holding large commercial vendors to higher standards but fear that vague definitions of “commercial activity” and coverage of free or donation-funded projects could expose hobbyists and non-profits to heavy compliance burdens and fines. Some argue this risks chilling open-source development in Europe or driving projects to block EU users, while others counter that meaningful regulation is overdue and must be carefully written rather than abandoned.
Scope and Intent of the CRA
- Many commenters agree that parts of the Cyber Resilience Act (CRA) address real problems: weak security practices, zero legal liability, and “enterprise” software shipped with minimal rigor.
- Others ask for specific evidence it is “bad”; supporters say liability and minimum standards are overdue in software, similar to other regulated industries.
Liability, Safety Analogies, and Standards
- Repeated analogies to food safety, aerospace, medicine, bolts in cars, etc.
- One camp: regulation and standardization came first in other fields and made them safer; software should follow, especially where lives depend on it.
- Other camp: software complexity, rapid change, and dependence on malicious exploitation (vs intrinsic harm like poison) make direct analogies weak and regulation much riskier.
Impact on FOSS, Hobbyists, and Small Businesses
- Central concern: CRA’s broad “commercial activity” definition, including “free of charge” and monetization via support, platforms, or data.
- Fear that:
- Hobby projects, donation-funded tools, and small consultancies could incur heavy compliance and liability burdens.
- Open‑source maintainers (log4j, OpenSSL–type projects) would need “industrial‑grade” processes without matching funding.
- This could push many individuals and small firms out of the EU market or stop publishing code.
Attempts to Carve Out Exemptions
- Later amendments reportedly try to exempt individual FOSS developers, but:
- Employed contributors and projects with corporate backing or recurring donations may still be treated as “commercial.”
- Non‑profits and foundations remain a gray area, with risk of “liability laundering” via FOSS fronts.
Regulation vs Innovation and Professionalization
- Some argue software engineering should move toward professional licensure and codified best practices; regulation is part of maturing the field.
- Others warn of regulatory capture, cost explosions (1–2 orders of magnitude), and “aerospace‑style” stagnation where change becomes prohibitively expensive.
- There is disagreement whether self‑regulation should have come first, or whether “the time for the whip” has already arrived.
Licensing, Blocking, and Workarounds
- Proposals floated: licenses banning government/EU use, blocking EU IPs, or new FOSS licenses that void themselves if regulatory duties arise.
- Several replies note:
- Laws override licenses; such clauses likely don’t shield from CRA duties.
- Use‑based discrimination would violate common FOSS definitions and Debian’s social contract, even if technically enforceable via infrastructure blocking.