The EU’s Cyber Resilience Act: How Open Source Averted a Crisis and What It Means for You
The European Union’s Cyber Resilience Act (CRA) is a landmark piece of legislation designed to bolster cybersecurity across the continent. Its goal is simple and commendable: to ensure that any “product with digital elements” sold in the EU is secure by design and receives timely security updates. However, the initial draft of the CRA sent a shockwave through the open-source community, threatening the very foundation of collaborative software development.
Thanks to the tireless advocacy of key figures like Linux kernel maintainer Greg Kroah-Hartman and organizations such as the Linux Foundation, the final version of the act looks dramatically different. It has evolved from a potential catastrophe for open source into a regulation that places responsibility exactly where it belongs: on the commercial entities that profit from it.
Here’s a breakdown of what happened, what the final rules mean, and the actionable steps you need to take.
The Initial Draft: A Looming Threat to Open Source
The core problem with the original CRA was its failure to distinguish between a volunteer developer and a multi-billion dollar corporation. The act intended to make the “manufacturer” of a digital product liable for security vulnerabilities. In the world of open source, this could mean that an individual developer, working for free in their spare time, could be held legally and financially responsible for a security flaw in code they gave away.
This created a chilling scenario:
- Crippling Liability: A single developer could face massive fines for a bug in a project used by millions.
- A Chilling Effect: Fearing legal repercussions, developers might have stopped creating open-source software or withdrawn existing projects.
- Undermining Collaboration: The open and collaborative nature of software development would have been replaced by a culture of fear and legal risk.
This fundamental misunderstanding of how the open-source ecosystem operates was, without exaggeration, an existential threat. It treated free, community-driven projects as commercial products, a comparison that simply doesn’t hold up.
A Turning Point: Critical Changes That Saved Open Source
Recognizing the imminent danger, the open-source community mobilized. Leaders and foundations engaged in extensive dialogue with EU legislators to explain the realities of software development. This advocacy was successful, leading to crucial amendments in the final version of the Cyber Resilience Act.
The most important change is the explicit exemption for open-source software developed or supplied outside the course of a commercial activity. This single clause is the victory that ensures individual, non-commercial open-source projects can continue without the fear of crippling liability.
The final act clarifies responsibility in three key ways:
Clear Exemption for Non-Commercial Work: If you are a developer contributing to an open-source project on a truly non-commercial basis, you are not the “manufacturer” under the CRA. The act now rightfully recognizes that providing code for free is not a commercial transaction.
Introduction of “Open Source Stewards”: The CRA now includes the concept of a steward—typically a non-profit foundation like the Linux Foundation or the Eclipse Foundation. These organizations can formally take on the responsibility and liability for the projects they host, providing a legal shield for the individual contributors working under their banner.
Responsibility Shifts to Commercial Implementers: This is the most significant outcome. The CRA now firmly places the legal liability on the company that integrates open-source software into its own commercial product. If a business sells a smart TV that uses the Linux kernel, that business—not the individual kernel developers—is responsible for ensuring the final product is secure and compliant with the CRA.
Lingering Questions: The Gray Area of “Commercial Activity”
While the final text is a massive improvement, some ambiguity remains. The key question revolves around the definition of “commercial activity.” It’s clear that a company selling software is a commercial entity. It’s also clear that a hobbyist developer working for free is not.
However, a gray area exists for projects that receive financial support. For instance:
- What if a developer receives donations through platforms like GitHub Sponsors or Patreon?
- What if a company pays its employees to contribute to an open-source project?
- What if the primary maintainer of a project runs a consulting business related to that software?
The line between a non-commercial project and a commercial one remains a subject for interpretation, and developers will need to be mindful of how their projects are funded and presented to avoid unintentionally falling under the CRA’s commercial definition.
Actionable Guidance: What This Means for Businesses and Developers
The Cyber Resilience Act is no longer a threat but a catalyst for change. It forces a new level of maturity and responsibility on the entire software industry.
For Businesses Using Open Source:
- Take Ownership: The responsibility is now yours. You can no longer simply consume open-source software without being accountable for its security within your products.
- Know Your Dependencies: You must maintain a comprehensive Software Bill of Materials (SBOM) for your products. You need to know exactly what open-source components you are using and be able to track them for vulnerabilities.
- Invest in Security: Your processes must include rigorous security vetting for all dependencies. This means funding security audits, contributing patches back to upstream projects, and having a clear plan for deploying security updates.
For Open Source Developers and Maintainers:
- Understand Your Status: Be clear about whether your project is a non-commercial, community effort or has commercial backing. This will determine where responsibility lies.
- Work with Foundations: If possible, house your project within an established foundation. These “Open Source Stewards” can provide the legal and organizational infrastructure to help with compliance.
- Maintain Good Security Hygiene: Continue to follow best practices for security, such as having a clear vulnerability disclosure policy (
SECURITY.md), triaging reports quickly, and being transparent with your users.
Ultimately, the Cyber Resilience Act has prompted a necessary evolution. It forces the commercial entities that derive immense value from open source to finally share in the responsibility of securing it. While it began as a potential crisis, the CRA has become a powerful driver for a more secure and sustainable digital ecosystem for everyone.
Source: https://go.theregister.com/feed/www.theregister.com/2025/09/30/cyber_reiliance_act_opinion_column/
