CEMarque

Does the CRA apply to open-source software I maintain?

Last verified 3 September 2026 · Facts v2026.09.2

If you maintain open-source software and do not monetise it, you are outside the Regulation. Free and open-source software that is not monetised is not considered placed on the market [1]. That is a real exemption written into the text, not an interpretation.

There are two important qualifications, and one consequence for the companies that use your code.

Qualification one: monetisation is broader than a price

Charging for support, selling a hosted version, taking sponsorship tied to the software's commercial use, or shipping it inside something you sell all count as commercial activity [2]. A dual-licensed project with a paid commercial licence is monetised. Re-check your position the moment any of that becomes true [3].

Donations and general sponsorship of a maintainer are a different thing from selling the software, but the boundary is not always obvious, and it is worth writing down where you think you sit and why [3].

Qualification two: stewards have their own regime

Open-source software stewards — legal persons, such as foundations, that systematically provide sustained support for the development of open-source products intended for commercial use — are not fully exempt [1]. They have a lighter set of obligations than manufacturers: a cybersecurity policy, cooperation with market surveillance authorities, and reporting of actively exploited vulnerabilities in the products they steward [1].

This is a deliberate middle category. It recognises that a foundation stewarding widely deployed infrastructure is not in the same position as a hobbyist, without treating it as a manufacturer either [1].

The consequence for your downstream users

A developer who integrates your component into their own product is the manufacturer of that product, and is responsible for its conformity including the integrated component [4]. Manufacturers must exercise due diligence when integrating third-party components, including open-source ones, and report vulnerabilities they find in them to the person maintaining the component [5].

In practice that means the companies using your library will start asking you for things: a bill of materials, a disclosure policy, an idea of your release cadence. They are not doing this to make your life harder. They are trying to discharge an obligation that is genuinely theirs, and you are under no duty to help — but a project that publishes a security policy and a contact address will be adopted more readily than one that does not [6].

Applies to you if

  • You are a foundation or company that systematically supports an open-source project intended for commercial use [1].
  • You have added any paid tier, hosted offering, or commercial licence to your project [2].
  • You are packaging other people's open source into something you sell [4].

What to do next

If you are unmonetised, you have no obligations here, and it is worth saying so plainly on your repository so that downstream users stop asking [1].

If you are a steward or you have monetised, the cheapest first step is the one every route requires anyway: publish a coordinated vulnerability disclosure policy and a contact address that a researcher can find [6]. That single artefact is the foundation of the reporting duty that starts on 11 September 2026 [7].

What to do next

Run your own product through the checker — it takes under a minute and gives you a dated, citable result you can send to a customer.

Check my product

Sources

  1. Free and open-source software not monetised is not considered placed on the market. Open-source software stewards (legal persons that systematically support free and open-source software intended for commercial activities) have a light regime: a documented cybersecurity policy, cooperation with authorities, and Article 14 reporting only where they are involved in development or where an incident affects their own development infrastructure; they do not affix CE marking and are not subject to fines. Art. 3(14), Art. 3(48), Art. 24, Recitals — EUR-Lex ↩
  2. The Regulation applies to products made available on the market in the course of a commercial activity; charging a price, charging for support, monetising via advertising or data, or otherwise intending to monetise are commercial activity. Art. 2(1), Art. 3(22), Recitals — EUR-Lex ↩
  3. Monetisation or commercial redistribution by you changes a non-commercial verdict; re-check when that happens. Recitals — EUR-Lex ↩
  4. A developer who integrates a component into their own product is the manufacturer of that product and responsible for its conformity, including the integrated component. Art. 13(5), Art. 3(13) — EUR-Lex ↩
  5. Where a product contains an integrated third-party component (including open source), the manufacturer exercises due diligence and reports vulnerabilities found in components to the person maintaining them. Art. 13(5)–(6) — EUR-Lex ↩
  6. Manufacturers have a coordinated vulnerability disclosure policy in place and a contact address for reporting. Annex I Part II(5)–(6) — EUR-Lex ↩
  7. Article 14 (reporting obligations of manufacturers) applies from 11 September 2026. Art. 71(3) — EUR-Lex ↩

Related

  • Does the CRA apply to WordPress plugins and themes?

    A paid or freemium plugin is a product with digital elements and is in scope. A genuinely non-monetised free plugin is not. Agencies that ship client sites under their own name are manufacturers of what they ship.

  • Does the CRA apply to free or ad-supported apps?

    Charging nothing does not put you outside the Regulation. What matters is whether the product is supplied in the course of a commercial activity, and advertising, data and freemium funnels all count.

  • What must I do by 11 September 2026?

    Be able to report. From that date manufacturers must notify actively exploited vulnerabilities and severe incidents through the ENISA platform, with an early warning within 24 hours of becoming aware.

  • What is a product with digital elements under the CRA?

    A software or hardware product and its remote data processing solutions, including components placed on the market separately. The phrase is broad on purpose and the remote-processing half is the part people miss.

CEMarque encodes Regulation (EU) 2024/2847 and the European Commission's published guidance as of 3 September 2026 (Facts v2026.09.2). It is not legal advice. Verify obligations for your product with qualified counsel where the stakes require it.