CRA and open source: distinguishing contributors, manufacturers and stewards

What it is

Status as of 25 October 2026. The CRA treats open-source software according to the product's supply and the entity's role. Re-check the regulation, its corrigenda and the Commission's open-source guidance when funding, distribution or responsibility changes. The guidance used here was updated on 15 October 2026.

The Commission explains that open-source software supplied commercially on the market can fall within the CRA. It also distinguishes contributors to software outside their responsibility and a separate category of open-source software stewards. An open-source licence alone does not resolve that classification. Commission open-source guidance.

Why it matters

Recital 18 separates development funding from commercial supply. Manufacturer contributions, financial support and regular releases do not, by themselves, make an open-source activity commercial. Software not monetised by its manufacturer should not be treated as commercially supplied on that basis. Conversely, a zero download price is not conclusive: Recital 15 discusses monetisation through other services and support charges exceeding actual cost recovery. The analysis concerns the actual arrangement, not just the repository's licence. Regulation, recitals 15 and 18.

The dates differ too. Manufacturer reporting under Article 14 has applied since 11 September 2026. Steward obligations under Article 24, including reporting, apply from 11 December 2027. The Commission's reporting page states this distinction explicitly.

How to apply

• Identify responsibility for each product. Recital 18 excludes people and legal entities merely contributing source code to open-source products outside their responsibility. That wording should not be expanded into a blanket exemption for anyone called a maintainer.
• Examine the manufacturer role. Article 3(13) concerns the entity developing or having a product developed and marketing it under its own name or trademark. Where an in-scope open-source product is placed on the market commercially, the Commission says manufacturer obligations apply. Most wider CRA requirements apply from 11 December 2027 under Article 71; the reporting duty has the earlier date.
• Check the steward definition separately. Article 3(14) identifies a legal person other than a manufacturer that systematically supports development over time, for specified open-source products intended for commercial activities, and ensures their viability. A project label or a donation alone does not establish all those elements.
• Read the tailored obligations. Article 24 requires a documented cybersecurity policy supporting secure development and vulnerability handling, and cooperation with market surveillance authorities. Its reporting scope is qualified: vulnerability reporting follows the steward's involvement in product development; severe-incident reporting and the referenced user-information duties concern incidents affecting the network and information systems the steward provides for that development. It is not an unrestricted duty to report every downstream user's incident. These distinctions come from Articles 3 and 24.
• Keep the basis for classification reviewable. As an organisational proposal, record the responsible entity, product ownership, distribution arrangements, monetisation and infrastructure provided. Attach the provisions relied upon and identify unresolved facts for qualified review.

Pitfalls

An exemption from administrative fines is not an exemption from the steward's obligations. The Commission states that stewards are outside CRA administrative fines. Read Article 64(10) with the 2 July 2025 corrigendum, which corrects the paragraph range in that exemption. Do not generalise it to a manufacturer merely because its product uses an open-source licence.

Finally, an upstream project's status does not settle the obligations of a manufacturer integrating its components into another product. Assess the actors and products separately instead of assigning one status to the entire dependency chain.