Free and open-source software

Free and open-source software has its own definition in the Cyber Resilience Act (CRA). Article 3(48) turns on two features: the source code is openly shared, and the licence grants all rights needed to make the software freely accessible, usable, modifiable and redistributable. Whether any particular body has approved that licence is irrelevant. The CRA points to no list of licences.

That definition does not, however, decide whether the Regulation applies. It only opens the door to a handful of special rules. Scope turns on a different question altogether.

Commercial activity decides, not the licence

Under Article 2(1) the CRA applies to products with digital elements that are made available on the market and whose intended purpose or reasonably foreseeable use includes a data connection to a device or network. Article 3(22) defines making available on the market as supply “for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”. Giving the software away therefore buys you nothing, because the test is commercial activity.

Recital 18 turns that into a workable yardstick: what counts is whether the manufacturer monetises the product. Free and open-source software that is not monetised is not supplied in the course of a commercial activity. For open-source components intended for integration by other manufacturers, supply amounts to making available on the market only where the original manufacturer monetises the component.

What expressly does not create commercial activity

Recitals 18 and 20 list several circumstances that are not enough on their own:

• financial support for an open-source project by manufacturers, or their contributions to its development
• the mere presence of regular releases
• development by a not-for-profit organisation, provided all earnings after costs go to not-for-profit objectives
• hosting on open repositories, through package managers or on collaboration platforms (those providers become a distributor only if they supply the software in the course of a commercial activity)

Nor does the Regulation apply to natural or legal persons who contribute source code to an open-source product that is not under their responsibility. Opening a pull request against someone else’s project does not make you answerable for its conformity.

These clarifications sit in the recitals, not in the enacting terms. They guide interpretation but have no binding legal force of their own, and so settle no borderline case conclusively. The legislator saw as much: Article 26(2)(a) obliges the Commission to address scope in its guidance with a particular focus on remote data processing solutions and free and open-source software.

Integrating open-source components keeps you on the hook

Exempting the project shifts the burden onto whoever uses the code. Article 13(5) requires the manufacturer to exercise due diligence when integrating components sourced from third parties. That duty expressly covers open-source software that was not made available on the market in the course of a commercial activity. Recital 34 names, among the possible measures, checking whether a component receives regular security updates, checking it against the European vulnerability database, and carrying out additional security tests.

Article 13(6) goes further. On identifying a vulnerability in an integrated component, including an open-source one, the manufacturer reports it to the person or entity manufacturing or maintaining that component and remediates it. Where it has developed a software or hardware modification to address the vulnerability, it shares the relevant code or documentation with that party, in a machine-readable format where appropriate. The CRA therefore expects a flow back into the project, not a silent fix in your own build.

Reliefs for open-source products

For manufacturers who market open-source products themselves, the CRA provides two:

• Article 32(5) turns on the product class: Annex III lists the important products, Annex IV the critical ones. Where an open-source product falls into one of the Annex III categories, its manufacturer may use any of the procedures in Article 32(1), including internal control under module A. The condition is that the technical documentation is made available to the public at the time of placing on the market. That saves the third-party involvement which is otherwise mandatory for class II without exception, and for class I whenever harmonised standards, common specifications or a European cybersecurity certification scheme are not applied in full. The relief does not extend to the critical products in Annex IV.
• Under Article 25, the Commission may introduce voluntary security attestation programmes for open-source software by delegated act. None has been adopted; anyone planning around one currently has nothing to hold.

A role of its own: the open-source software steward

Article 24 creates a light-touch regime for the open-source software steward. Article 3(14) covers legal persons that provide systematic and sustained support for the development of open-source products intended for commercial activities and that ensure the viability of those products, without being manufacturers themselves. Their duties are narrow: a cybersecurity policy documented in a verifiable manner, cooperation with market surveillance authorities on request, and, to the extent they are involved in development, the reporting obligations in Article 14(1). Article 14(3) and (8) apply as well where severe incidents affect the network and information systems the steward provides for developing those products. Administrative fines are off the table for them: Article 64(10)(b) exempts open-source software stewards from the fines in paragraphs 3 to 9 for any infringement of the Regulation.

The Regulation applies from 11 December 2027; the reporting obligations in Article 14 bite earlier, from 11 September 2026.