← Commission worked examplesOpen source

When is open source software supplied in the course of a commercial activity?

22 worked examples from Commission guidance C(2026) 5252 final, reproduced word for word.

Also asked

  • Do donations make my open source project commercial under the CRA?
  • Am I a steward or a manufacturer of my open source component?
  • Does selling support for open source software trigger CRA obligations?
  • Does funding a feature make a manufacturer responsible for the project?
  • Do contributors to an open source project have CRA obligations?

The Cyber Resilience Act reaches free and open-source software only where it is supplied in the course of a commercial activity. The Commission's twenty-two examples locate that line. Charging for a paid version, gating releases or security fixes behind donations, monetising what is sold through the software, and requiring unrelated personal data processing all cross it. Voluntary donations, separately sold consultancy, funded features released openly, and contributing to someone else's project do not.

Falling outside placing on the market does not always mean falling outside the CRA. A publisher who supports a component others integrate may be a steward under Article 24.

At a glance

Test
Commercial activity, applied to how the software is supplied
Voluntary donations
Not commercial where access is unconditional (Example 20)
Donations gating releases
Commercial, de facto a price (Examples 21 and 22)
Contributors
No obligations. No primary control over releases (Example 13)
Stewards
Article 24 obligations, no CE marking, no fines under Article 64(10)

Last reviewed 27 July 2026

Verified against The Annex to Commission Communication C(2026) 5252 final of 27 July 2026, and Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

What makes the supply commercial

Recital 18 applies the commercial activity test to the supply of the software rather than to how the project was developed or financed.[2] Examples 14 to 22 work through the ways a supply becomes commercial without anyone charging for the software itself.

Monetising what flows through the application counts. A free marketplace app earning advertising, commission or subscription revenue is commercial, and so is a free VPN selling access to extra servers. Requiring users to accept personal data processing for advertising or unrelated analytics counts as well.

Support services split the two ways. Selling a paid edition of the operating system that bundles technical assistance is commercial. Selling optional consultancy alongside a freely available command line tool is not.

CRA referenceRecital 18, Article 3, point (48)

Donations turn on whether they gate access

Three examples settle the donations question that dominated the consultation. Example 20 confirms that inviting voluntary donations changes nothing where access to the software, its source and its updates is unconditional.

Examples 21 and 22 draw the other side. Providing downloadable releases and security updates only to donors makes the donation a de facto condition of access, which amounts to charging a price. Publishing the source publicly while reserving pre-compiled binaries, regular updates and guaranteed security fixes for donors does the same, because donations then buy access to essential aspects of the product.[1]

CRA referenceRecital 18

Stewards, manufacturers and everyone else

Examples 24 to 34 sort the roles. A publisher who provides sustained support for a component intended for integration into other products, without monetising the supply, is a steward under Article 24.[3] That covers a not-for-profit foundation, a company publishing an unmonetised library it also uses itself, and a not-for-profit publishing an SDK funded by membership fees.

A publisher who sells a paid version with benefits is a manufacturer, whatever outside contributors do.

Everyone else is generally outside. Contributors submitting pull requests have no obligations, because they exercise no primary control over releases or distribution. A manufacturer funding a feature that is released openly does not become the manufacturer of the project. Package repositories have no obligations for what they host. In every one of these scenarios the integrator still owes due diligence under Article 13(5).

CRA referenceArticle 24, Article 13(5), Article 64(10)

The Commission’s examples, word for word

22 examples, reproduced exactly as published. Each carries the section, guidance point and page it comes from. The bold line above each quotation is our summary of the outcome and is not part of the source.

Example 13

Section 3.1 Determining if free and open-source software is under one's responsibility, point 49, page 19

A contributor sending a pull request is not subject to the CRA

An individual developer or an employee of a company submits a 'pull' or 'merge' request containing a security patch or a new feature to a FOSS project. The project's maintainers review, accept and merge the code into the main repository, subsequently including it in a new release. In this scenario, the person who submitted the pull request is a 'contributor' and is not subject to the CRA. Although that person contributed source code, they do not exercise primary control over the development, releases or distribution decisions.

New in the adopted text. It has no counterpart in the earlier consultation draft.

Example 14

Section 3.2.2 Monetisation of other services or requiring the processing of personal data, point 54, page 20

Commercial. A free marketplace app that monetises what is sold through it

A natural or legal person publishes a free and open-source marketplace application. The application is available free of charge and enables users to purchase goods or services through it. The app allows the person that published it to monetise other products with digital elements and services offered through it (e.g. through advertisements, commission fees or subscription fees). Therefore, the application is considered placed on the market in the course of a commercial activity.

Example 15

Section 3.2.2 Monetisation of other services or requiring the processing of personal data, point 54, page 20

Commercial. A free VPN with paid servers or dedicated addresses

A natural or legal person publishes a free and open-source VPN. The application is available free of charge, but it enables users to pay to access additional servers or dedicated IP addresses. That application allows that person to monetise other services offered through it, therefore it is considered placed on the market in the course of a commercial activity.

Example 16

Section 3.2.2 Monetisation of other services or requiring the processing of personal data, point 54, page 20

Commercial. Use conditional on personal data processing unrelated to security or interoperability

A natural or legal person publishes a free and open-source fitness tracking application. The application is available free of charge, but its use is conditional upon the processing of users' personal data for purposes such as targeted advertising or analytics unrelated to the security, compatibility or interoperability of the software. By requiring such data processing as a condition for use, the application is therefore considered placed on the market in the course of a commercial activity.

Example 17

Section 3.2.3 Support services, point 57, page 21

Commercial. A paid version of the operating system bundling support

A natural or legal person publishes a free and open-source operating system, offering a paid version of that operating system which includes support services, such as technical assistance or performance optimisation. The paid version of the operating system is considered placed on the market in the course of a commercial activity.

Example 18

Section 3.2.3 Support services, point 57, page 21

Not commercial. Optional consultancy sold separately from the software

A natural or legal person publishes a free and open-source command line tool. The tool is freely accessible and anyone can download and install it. That natural or legal person separately offers professional services, such as optional consultancy services to train users and support them in installing and using the tool. That FOSS is not considered placed on the market within the meaning of the CRA.

Example 19

Section 3.2.3 Support services, point 59, page 22

Not placing on the market. Installing someone else's FOSS for a customer without substantially modifying it

A service provider does not publish a FOSS, but helps a customer install it on the customer's on-premises server. It does so without performing a substantial modification of that FOSS. The service provider is therefore not considered to be placing the FOSS on the market.

Example 20

Section 3.2.4 Donations, point 61, page 22

Not commercial. Voluntary donations with unconditional access to the software

A natural or legal person publishes a FOSS tool in a public online repository, allowing anyone to download, use, modify and redistribute it under a free and open-source licence. The publisher invites users to make voluntary donations via a donation platform to support the project's continued development and maintenance. Access to the software, its source code and its updates is not conditional on making a donation. That FOSS is not considered to be supplied in the course of a commercial activity and is not considered to be placed on the market within the meaning of the CRA.

Example 21

Section 3.2.4 Donations, point 62, page 22

Commercial. Donations gate the releases and the security updates

A natural or legal person publishes a software product with digital elements under a free and open-source licence, but provides downloadable releases and security updates only to users who make a donation. Users who do not make a donation do not have access to the software's current version.

In this case, the donations are de facto a condition for access to the product with digital elements and therefore amount to charging a price. That FOSS is therefore considered to be placed on the market within the meaning of the CRA.

Example 22

Section 3.2.4 Donations, point 62, page 23

Commercial. Source is public but binaries, updates and fixes are donor-only

A natural or legal person makes the source code of a FOSS publicly available, but provides pre-compiled binaries, regular updates and guaranteed security fixes only to donors. In this case, the donations are linked to access to essential aspects of the product with digital elements and constitute remuneration for that product's supply. That FOSS is therefore considered to be placed on the market in the course of a commercial activity.

Example 23

Section 3.2.5 Financing of free and open-source software, point 65, page 23

Not placing on the market. A manufacturer funding a feature that is released openly to everyone

An individual developer publishes a FOSS project and actively maintains it. Manufacturer A requests that the individual developer add a specific feature for that FOSS, and funds that development. The developer adds the feature to the FOSS codebase, openly sharing it and making it freely available for all to access, use, modify and redistribute. The individual developer is not considered to have placed that FOSS on the market. If the manufacturer integrates the FOSS into its product with digital elements, it needs to exercise due diligence in accordance with Article 13(5).

Example 24

Section 3.2.6 Not-for-profit entities set up to achieve not-for-profit objectives, point 66, page 24

Steward, not manufacturer. Direct monetisation, but all earnings after costs go to not-for-profit objectives

A legal person publishes a free and open-source browser that is directly monetised via search engine partnerships, but all its earnings after costs are used for not-for-profit objectives. The browser is not considered to be placed on the market within the meaning of the CRA. The legal person publishing it is subject to the obligations applicable to stewards.

Example 25

Section 3.2.7 Integration by other manufacturers, point 68, page 24

Steward. A published library the publisher also integrates into its own product

A legal person publishes a FOSS library for building user interfaces. It does not monetise the supply of that library, but integrates it into one of its products with digital elements (which is in turn placed on the market). The library is not considered placed on the market within the meaning of the CRA, but it is intended for integration into products with digital elements. The legal person that publishes it is its steward.

Example 26

Section 3.2.7 Integration by other manufacturers, point 68, page 24

Steward. Reference implementations published alongside a commercial operating system

A legal person places an operating system on the market, and also publishes FOSS libraries to serve as reference implementations for users of that operating system. The legal person does not monetise the FOSS libraries, which are intended for integration into other products with digital elements. The legal person that publishes them is a steward to those FOSS libraries.

Example 27

Section 3.5 Illustrative scenarios, point 89, page 28

No obligations at all for the developer. Donations from integrators do not make the supply commercial

Individual developer A has developed a FOSS. Developer A publishes that FOSS under its own name or trademark, but does not charge a price for its use. The software is openly shared and freely available for all to access, use, modify and redistribute. Developer A also includes a link to a platform to collect voluntary donations.

Companies B, C and D integrate that FOSS into their own products with digital elements. To support ongoing maintenance, companies B, C and D make voluntary donations to developer A. These donations enable developer A to keep the project actively maintained.

That FOSS is not placed on the market within the meaning of the CRA. Developer A has no obligations under the CRA. Companies B, C, and D are to exercise due diligence in accordance with Article 13(5) when integrating that FOSS into their own products with digital elements.

Example 28

Section 3.5 Illustrative scenarios, point 89, page 28

Steward. A not-for-profit foundation providing sustained support to a component others integrate

Not-for-profit foundation F publishes a FOSS component for integration into other commercial products with digital elements. Foundation F commits to providing sustained support to that FOSS, to ensure its viability and uptake. Companies A, B and C integrate that FOSS into their own products with digital elements. Companies A and B voluntarily contribute some of their developers' time to development and maintenance of FOSS projects within foundation F, including for that FOSS.

As foundation F is a not-for-profit entity set up in such a way that its earnings after costs are used to achieve not-for-profit objectives, the FOSS is not considered to be placed on the market within the meaning of the CRA. Foundation F is the FOSS steward and is subject to the corresponding obligations laid down in Article 24. Companies A, B and C are to exercise due diligence in accordance with Article 13(5) when integrating that FOSS into their own products with digital elements.

Example 29

Section 3.5 Illustrative scenarios, point 89, page 28

Steward, not manufacturer. A company publishing an unmonetised component it also uses itself

Company A has developed a FOSS component for integration into its own products with digital elements. It also publishes that FOSS separately under its own name or trademark and actively maintains it. However, it does not charge for its use or monetise in other ways. Companies B, C and D integrate that FOSS into their own products with digital elements, and voluntarily contribute some of their developers' time to its maintenance.

That FOSS is not considered to be placed on the market within the meaning of the CRA. Company A is not its manufacturer, but is its steward. Companies B, C, and D are to exercise due diligence in accordance with Article 13(5) when integrating the FOSS into their own products with digital elements.

Example 30

Section 3.5 Illustrative scenarios, point 89, page 28

Manufacturer. A paid version with benefits, notwithstanding outside contributors

Company A publishes a FOSS under its own name or trademark and offers it as a paid version, which includes certain benefits such as technical assistance or performance optimisation. Developers from companies B, C and D contribute to the FOSS's maintenance, but it remains under the control of company A.

Company A is considered a manufacturer to that FOSS. Companies B, C and D are not subject to obligations under the CRA for that specific FOSS. If they integrate that FOSS into their own products with digital elements, they are required to exercise due diligence in accordance with Article 13(5).

Example 31

Section 3.5 Illustrative scenarios, point 89, page 29

Steward. Support services sold independently by a contributor create no obligations for that contributor

Company A publishes a FOSS under its own name or trademark and provides ongoing maintenance to ensure its long-term viability, to enable that software to be integrated into other companies' products with digital elements. Company A does not charge for its use, process personal data it collects through the product with digital elements, or sell support services associated with publishing the FOSS.

Company B contributes code and developers' time to the FOSS's maintenance, but does not distribute it commercially. Company B offers technical support services independently from the FOSS's distribution. Company A is deemed to be the steward for that FOSS, whereas company B has no obligations under the CRA for that FOSS.

Example 32

Section 3.5 Illustrative scenarios, point 89, page 29

Steward. Funding a feature does not make the funder the manufacturer of the component

A FOSS component is published by a not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. The entity provides sustained support to ensure the project's long-term viability. Maintenance is financed through public funding, such as research grants. Additional developments, including new features, are funded through donations and specific projects, carried out in partnership with manufacturers that integrate that FOSS into their products with digital elements. Such features are incorporated into the FOSS's codebase.

The not-for-profit entity that publishes the FOSS is deemed the steward for that FOSS component. A manufacturer that has contributed to the development of certain features does not become the manufacturer of that FOSS component. Where the manufacturer integrates that FOSS component into its own product with digital elements, it needs to exercise due diligence in accordance with Article 13(5).

Example 33

Section 3.5 Illustrative scenarios, point 89, page 29

Steward. Membership fees and seconded developers do not shift responsibility to the members

A not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives publishes a FOSS software development kit (SDK) and ensures its ongoing maintenance. The SDK is openly shared and is freely available for all to access, use, modify and redistribute. Funding is provided through membership fees paid to the not-for-profit entity, and developers employed by member organisations contribute code and other resources to the SDK's development. Manufacturers use the SDK as a component to build other products with digital elements.

The not-for-profit entity that publishes that SDK is the steward for it. The foundation's members are not responsible for the SDK's compliance with the CRA. Where manufacturers use the SDK to build their own product with digital elements, they need to exercise due diligence in accordance with Article 13(5).

Example 34

Section 3.5 Illustrative scenarios, point 89, page 30

No obligations for the developer or the package repository. Due diligence sits with the integrator

An individual developer publishes a FOSS library on a public package repository for a given programming language and actively maintains it. In the package documentation, the developer adds a link to collect donations. A manufacturer downloads that library from the repository for free and integrates it into its own product with digital elements.

The individual developer and the package repository do not have any obligations under the CRA. The manufacturer that integrates the library needs to exercise due diligence in accordance with Article 13(5).

Sources

Every claim above traces to one of these. Items marked Binding are law in force. Everything else is interpretive and is labelled as such.

  1. [1]

    European Commission · Section 3, points 49 to 89 · C(2026) 5252 final · Final, adopted 27 July 2026

    Article 26 guidance sets out the Commission's interpretation of the CRA. It does not bind economic operators, and only the Court of Justice of the European Union can give an authoritative interpretation of the Regulation.

    Accessed 2026-07-27

  2. [3]

    European Union · Article 24 · CELEX:32024R2847

    Accessed 2026-07-27

  3. [4]

    European Union · Article 13(5) · CELEX:32024R2847

    Accessed 2026-07-27

Turn the guidance into an audit-ready file

Free CRA classification for your product, a vulnerability disclosure portal on your own domain, and Article 14 deadline tracking. Receiving and tracking reports is free for every manufacturer placing products with digital elements on the EU market.