The European Commission publishes CRA implementation guidelines. Key takeaways for open source
By Juan Rico
It provides practical clarification of key CRA concepts that directly impact the open source ecosystem, including the criteria for placing software on the market, the distinction between maintainers and contributors, the obligations of Open Source Software Stewards, upstream vulnerability reporting, and downstream integration requirements.
Below is a detailed open-source analysis summarising the guidance’s key takeaways while emphasising the critical advocacy role of the Open Regulatory Compliance. Through ongoing engagement with policymakers, the release of technical assets like the stewards white paper and engagement in key public consultations, ORC ensures that the open source community interests are represented and that regulatory frameworks translate effectively into practical, real-world implementation.
Key takeaways from an open source perspective
A. Placement on the Market & Monetisation Boundaries
- Commercial vs. Non-Commercial distinctions: FOSS is only subject to standard manufacturer obligations if it is placed on the Union market in the course of a commercial activity. Merely publishing, hosting, or openly sharing source code under an open source licence does not constitute placing software on the market.
- Monetisation triggers: FOSS is considered placed on the market (making the developer/entity a “manufacturer”) if one of these is true:
- A price is directly charged for the software or compiled binaries.
- It is bundled with paid technical support services exceeding reasonable cost recuperation (including reasonable living expenses for natural persons).
- It monetises other products/services, conditions access on personal data processing (unrelated to security/interoperability), or accepts donations exceeding cost recovery with an intention to make a profit.
- Dual-Licensing & “Community” Versions: Providing a free “community” version alongside a monetised enterprise version does not bring the community version under manufacturer obligations, provided the free version itself is not monetised.
B. Responsibility: Maintainers vs. Contributors
- Contributor protection: The guidance explicitly clarifies that natural or legal persons who contribute code (e.g., submitting pull or merge requests) but do not control releases, roadmaps, or governance decisions are contributors, not maintainers, and fall outside the scope of the CRA.
- Maintainer responsibility: Software is only under the responsibility of natural or legal persons (maintainers) who publish it and exercise primary control over development, releases, and distribution.
C. Open Source Software Stewards (Art 3(14) & Art 24)
- Definition: Stewards are legal persons (such as non-profit foundations) that provide sustained support for FOSS intended for commercial activities but do not place the software on the market themselves.
- Tiered obligations based on involvement (Art 24(3)):
- Non-Technical Stewards (governance, branding, events): Must adopt a cybersecurity policy, but are not required to report actively exploited vulnerabilities or severe infrastructure incidents.
- Infrastructure Stewards (hosting code repositories, CI/CD pipelines): Must notify ENISA and CSIRTs of severe incidents affecting their IT infrastructure.
- Engineering Stewards (employing developers, directly coordinating releases): Must report actively exploited vulnerabilities they become aware of.
D. Upstream & downstream integration mechanics
- Integrator accountability (Art 13(5)): Commercial integrators who build FOSS components into their monetised products bear full manufacturer liability for the finished product. Integrating FOSS does not transfer CRA liability upstream to open source maintainers or stewards.
- Upstream reporting & fix sharing (Art 13(6)):
- Integrators discovering vulnerabilities in FOSS components must report them upstream to maintainers, using the guidelines set by the open source project
- Integrators developing a patch must share the security fix upstream in a machine-readable format compatible with the project’s licence.
- Crucially, maintainers are not legally obligated to accept or merge proposed upstream security fixes.
E. Practical compliance relief for FOSS
- Conformity assessment flexibility (Art 32(5)): Important Class I and Class II FOSS products placed on the market are permitted to use the internal control procedure (Module A self-assessment), avoiding mandatory third-party audits.
- Single-Version patching (Art 13(10)): Software developers/manufacturers may restrict active vulnerability patching to the latest release version, provided downstream users can upgrade free of charge and without incurring additional infrastructure costs.
Summary
The Commission’s Guidance Package validates much of what the open source community advocated for: protecting individual contributors, recognising non-profit steward models, and ensuring maintainers are not held liable for downstream commercial usage.
The ORC community was fundamental in this process. By serving as a bridge between the realities of open source development and the complexities of EU regulatory frameworks, ORC ensured that policymakers understood and addressed the community’s unique needs. Through targeted technical advocacy, expert participation in the CRA Expert Group, and coordinated feedback, the ORC community did more than just provide input, they acted as a strategic partner in translating open source collaboration into the final regulatory outcomes. This achievement cements the ORC community as an essential, authoritative voice in shaping digital policy, proving that open source expertise is critical to creating sustainable, innovation-friendly legislation.