IN SHORT
Open-source software is not exempt as such. The CRA applies to economic operators only for products made available on the market, which means supplied in the course of a commercial activity (Article 3, point (22)). Free and open-source software that is not supplied in the course of a commercial activity is outside the obligations for manufacturers, while monetised open-source products are covered like any other product. A separate, lighter regime applies to open-source software stewards (Article 24). And manufacturers that integrate open-source components remain responsible for them in their own products (Article 13(5)).
Key definitions
What the text requires
- Free and open-source software: software whose source code is openly shared and which is made available under a free and open-source licence providing all rights to make it freely accessible, usable, modifiable and redistributable (Article 3, point (48)).
- Making available on the market: the supply of a product for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge (Article 3, point (22)).
- Open-source software steward: a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products (Article 3, point (14)).
Because "free of charge" supply can still be a commercial activity, the question is not whether software is paid for but whether it is supplied in the course of a commercial activity.
What counts as a commercial activity — the recitals
The articles do not list criteria; the recitals give the legislature's explanation.
Recital 15 states that the Regulation applies to economic operators only in relation to products made available on the market, and that supply in the course of a commercial activity might be characterised by: charging a price for the product; charging a price for technical support services where this does not serve only to recover actual costs; an intention to monetise, for example through a software platform used to monetise other services; requiring, as a condition for use, the processing of personal data for reasons other than exclusively improving security, compatibility or interoperability; or accepting donations exceeding the costs of design, development and provision (Recital 15). It adds: Accepting donations without the intention of making a profit should not be considered to be a commercial activity. Recital 15
Recital 18 clarifies several situations:
the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity Recital 18
;- open-source components intended for integration by other manufacturers are considered made available on the market only if the component is monetised by its original manufacturer;
- receiving financial support from manufacturers, or manufacturers contributing to development, does not in itself make the activity commercial; nor does the mere presence of regular releases;
- development by not-for-profit organisations is not a commercial activity provided all earnings after costs are used to achieve not-for-profit objectives;
- the Regulation does not apply to persons who contribute source code to open-source products that are not under their responsibility (Recital 18).
Our interpretation
Recitals explain the provisions but are not themselves the operative provisions. In our reading, they are a strong indication of how "commercial activity" will be interpreted, but borderline cases (for example an open-source project run by a company that sells paid support) need a case-by-case analysis of the facts listed in recital 15. Keep a written record of that analysis.
Open-source software stewards
Recital 19 explains that stewards — which include certain foundations as well as entities developing and publishing open-source software in a business context, including not-for-profit entities — are subject to a light-touch and tailor-made regime, which covers only open-source products ultimately intended for commercial activities (Recital 19).
What the text requires
An open-source software steward must:
- put in place and document, in a verifiable manner, a cybersecurity policy to foster the development of a secure product and effective handling of vulnerabilities by its developers, which also fosters voluntary reporting of vulnerabilities and promotes information sharing within the open-source community (Article 24(1));
- cooperate with market surveillance authorities at their request, and provide the documentation of that policy upon a reasoned request (Article 24(2));
- comply with the reporting obligation of Article 14(1) on actively exploited vulnerabilities to the extent that it is involved in the development of the products, and with Article 14(3) and (8) where severe incidents affect network and information systems it provides for the development of such products (Article 24(3)).
Stewards are not subject to the same obligations as manufacturers, and recital 19 states that they should not be permitted to affix the CE marking to the products whose development they support (Recital 19). Administrative fines under Article 64 do not apply to infringements of the Regulation by open-source software stewards (Article 64(10), point (b)).
Manufacturers that integrate open-source components
What the text requires
Manufacturers must exercise due diligence when integrating components sourced from third parties, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity Article 13(5)
.
When they identify a vulnerability in a component, including an open-source component, they must report it to the person or entity manufacturing or maintaining the component, address and remediate it in accordance with Annex I, Part II, and, where they have developed a fix, share the relevant code or documentation with the maintainer, where appropriate in a machine-readable format (Article 13(6)).
To facilitate this due diligence, the Commission is empowered to establish, by delegated acts, voluntary security attestation programmes for products qualifying as free and open-source software (Article 25).
Uncertain / awaiting guidance
We have not verified whether delegated acts establishing such attestation programmes have been adopted. Until they exist and their content is known, manufacturers cannot rely on them to demonstrate due diligence.
Open-source products listed in Annex III
Manufacturers of products qualifying as free and open-source software that fall under the categories of Annex III (important products) may demonstrate conformity using any of the procedures of Article 32(1) — including internal control — provided that the technical documentation is made available to the public when the product is placed on the market (Article 32(5)).
Fictional example — Three projects
libquark (fictional) is a compression library maintained by volunteers, published under an open-source licence, not monetised, funded by donations that cover hosting costs. On the reading given in recitals 15 and 18, this supply is not a commercial activity: the project is not a manufacturer under the CRA.
Quark Foundation (fictional) is a not-for-profit foundation that hosts libquark's infrastructure and steers its development, knowing the library is widely integrated into commercial products. It may qualify as an open-source software steward and should prepare the cybersecurity policy required by Article 24.
CamCo (fictional) sells security cameras whose firmware integrates libquark. CamCo is the manufacturer of the camera: it must exercise due diligence on libquark, report any vulnerability it finds to the maintainers, and fix it in its own product.
Good practice (recommendation, not a legal requirement)
If you publish open-source software, document how your project is funded and supplied, and review it against recital 15. If you integrate open-source components, keep a software bill of materials, monitor upstream advisories, and agree internally how you will report vulnerabilities upstream. These are practical suggestions, not requirements in themselves.
What to do next
Read recitals 15 to 19 and Article 24 in full, then decide in writing whether your role is manufacturer, steward, contributor or none of these.