[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:en:is-your-open-source-project-commercial-under-the-cra-the-commissions-seven-tests":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"en","is-your-open-source-project-commercial-under-the-cra-the-commissions-seven-tests","Is your open-source project 'commercial' under the CRA? The Commission's seven tests, with its examples","The CRA reaches free and open-source software only where it is supplied in the course of a commercial activity, and the Regulation leaves 'commercial' to two recitals. The Commission's guidance of 27 July 2026, section 3, turns them into seven tests: a price, a paid edition or open core, monetising other services or personal data, support services, donations, sponsorship, and not-for-profit status, with 22 examples. Where a maintainer, an open-core company and a foundation each land, and what a pull request makes you.","2026-09-11","\nThe Cyber Resilience Act, Regulation (EU) 2024\u002F2847, applies to free and open-source software only when it is \"made available on the market\", which means supplied \"in the course of a commercial activity\". [The three cases](\u002Farticles\u002Fdoes-the-cra-apply-to-open-source-software), a non-monetised project, a product built on open-source components, and the open-source software steward, come from the Regulation itself. What the Regulation does not do is say when a project that takes money, offers support, runs a paid tier or is funded by a company crosses the line. Recitals 15 and 18 give the direction; the Commission's guidance of 27 July 2026, C(2026) 5252, section 3, paragraphs 42 to 89, gives the tests, and 22 worked examples numbered 13 to 34.\n\nThis article is that section. It is written for the three people who ask: the maintainer with a donation link, the company with a community edition and an enterprise one, and the foundation.\n\n## First, what counts as open source at all\n\nArticle 3(48) defines free and open-source software as \"software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable\". Paragraph 44 reads that as two cumulative conditions: a licence granting the full set of rights, and source code that is openly shared. Paragraph 46 draws the consequence for source-available and customer-only models: software \"whose source code is only shared (or allowed to be shared) with paying customers or a limited group of users is not to be considered FOSS\". The guidance names no licences. It names the two conditions.\n\n## Who is responsible: maintainers, not contributors\n\nBefore asking whether a project is commercial, paragraph 48 asks whether you are the one supplying it. Paragraph 49: open-source software is \"under the responsibility\" of the persons \"who publish it and exercise primary control over its development, releases, and distribution decisions (often referred to as 'maintainers')\". Contributors, who \"contribute source code but do not control releases, roadmaps, or governance decisions\", are not responsible, \"even though they contributed code to it\", and \"the mere existence of technical permissions, such as commit access, is not sufficient\". Example 13 is the pull request: the person who submits a patch that maintainers review and merge \"is a 'contributor' and is not subject to the CRA\".\n\nParagraphs 86 and 87 close the loop for companies: a manufacturer that integrates a component and contributes to its maintenance does not become responsible for that component, and integrating a component into a monetised product \"has no impact on the status of that FOSS component under the CRA\". Whether the Regulation applies to a component \"depends solely on whether the natural or legal person that publishes it places it on the market\".\n\n## The seven tests\n\n**1. Charging a price for the software.** Paragraph 51: charging for the software itself, \"e.g. by charging a price for the pre-compiled binaries\", is placing it on the market, and the person charging is a manufacturer.\n\n**2. A paid edition next to a free one, including open core.** Paragraph 52 treats them as two products. The paid version is placed on the market; \"the version provided for free (or community version) is not monetised and therefore is not considered to be placed on the market\". That holds \"where the paid version is an 'enhanced' commercial version, which extends the codebase of the version provided for free, or incorporates that version into a broader product (e.g. as in the case of the 'open-core' model)\". Paragraph 53 adds the catch for companies: a legal person supplying the community version is a steward for it; a natural person is outside the Regulation for it.\n\n**3. Monetising other services through the software, or requiring personal data.** Paragraph 54: a project is placed on the market where the publisher \"monetises other products with digital elements or services\" through it, or \"requires as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software\". Example 14 is a free marketplace app that earns commissions or advertising; example 15 a free VPN client that sells access to additional servers; example 16 a free fitness app whose use is conditional on data processing for targeted advertising. All three are on the market.\n\n**4. Support services.** Paragraphs 55 to 57 draw the line most open-source companies live on. Offering paid support \"does not, as such\" make the software commercial: \"the decisive factor is whether access to the FOSS itself, including its maintenance, is conditioned on remuneration, rather than the mere offering of professional services around a freely available product\". Example 18, a freely downloadable command-line tool with optional paid consultancy, is not on the market. Example 17, an operating system with a paid version \"which includes support services, such as technical assistance or performance optimisation\", is, and paragraph 57 says so \"irrespective of whether functionally equivalent software is also available free of charge\". For individuals, paragraph 58 adds Recital 15's cost-recovery rule: bundling assistance with access is still not commercial \"if the price charged serves only the recuperation of actual costs\", which \"include the person's reasonable living expenses\".\n\n**5. Donations.** Paragraph 61, from Recital 15: \"accepting donations without the intention of making a profit should not be considered to be a commercial activity\", and a donation link is not an intention to profit \"even where the amount collected via donations exceeds the mere costs\", reasonable contributor compensation and living expenses included. \"A FOSS supported only through donations is therefore unlikely to be considered to be placed on the market.\" Paragraph 62 gives the exception: donations that are \"de facto equivalent to charging a price\", where \"access to the FOSS, to essential functionalities or to updates is conditioned in practice on making a donation\". Example 21 provides releases and security updates only to donors: on the market. Example 22 publishes the source but gives \"pre-compiled binaries, regular updates and guaranteed security fixes only to donors\": on the market.\n\n**6. Sponsorship and funded development.** Paragraphs 63 to 65: grants, bug bounties, sponsorships and paid feature work \"should not be taken into account when determining the commercial nature of that activity\". Example 23 is a company paying an individual maintainer to add a feature that is then openly shared; the maintainer has not placed anything on the market, and the company owes due diligence under Article 13(5) when it integrates the result.\n\n**7. Not-for-profit publishers.** Paragraph 66: a legal person \"set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives\" does not place its software on the market, even where it is directly monetised. Example 24 is a browser \"directly monetised via search engine partnerships\" whose earnings after costs go to not-for-profit objectives: not on the market, and the publisher is a steward.\n\nParagraph 67 adds the case the whole steward regime exists for: software \"intended for integration by other manufacturers into their own products\" is not placed on the market unless the publisher also monetises it; the legal person publishing it is a steward if it provides sustained support. Examples 25 and 26 are a UI library and reference implementations a company publishes without charge.\n\n## Where each of the three lands\n\nThe illustrative scenarios of section 3.5 map the tests onto real shapes, and three of them cover most readers.\n\n**The individual maintainer with a donation link** (examples 27 and 34): not on the market, no obligations under the Regulation, however many companies depend on the project and however much they donate. The companies integrating it owe due diligence under Article 13(5), and, under Article 13(6), owe the maintainer reports of vulnerabilities they find and the fixes they write.\n\n**The company with a community edition and a paid one** (examples 29 and 30): a manufacturer for the paid edition, with the full Regulation attached to it, and a steward for the community edition it supplies free, with Article 24's lighter duties attached to that. Paragraphs 72 to 74 are explicit that one legal person can be both at once, project by project, and must decide \"for each specific FOSS that it publishes\" which it is.\n\n**The foundation** (examples 28, 32 and 33): a steward, whether funded by public grants, donations, partnership projects or membership fees, provided it is set up so that earnings after costs serve not-for-profit objectives and it sustains the software. Its members and funders are not responsible for the software's compliance; manufacturers who build on it owe due diligence.\n\n## What to write down\n\nFor each project you publish, one page: whether it meets the two conditions of Article 3(48); who exercises primary control over releases; which of the seven tests, if any, it meets, with the example number it resembles; and the resulting role, manufacturer, steward or neither. A company that publishes several projects writes that page several times, because paragraph 74 says the answer is per project. A manufacturer that integrates open-source components does not write it for them; it records the due diligence of Article 13(5) and the upstream reports of Article 13(6) instead, which is where [the twelve steps](\u002Farticles\u002Fthe-cyber-resilience-act-for-a-small-software-manufacturer-in-twelve-steps) put them.\n\n## Sources\n\n- Regulation (EU) 2024\u002F2847, Article 3(14) and (48), Article 13(5) and (6), Article 24, Recitals 15, 18 and 19.\n- European Commission, Commission guidance on the application of Regulation (EU) 2024\u002F2847, C(2026) 5252 final of 27 July 2026, Annex, section 3, paragraphs 42 to 89 and examples 13 to 34.\n\nThis is not legal advice. Section 3 is fourteen pages, and the 22 examples are the part to read; most projects will recognise themselves in one of them.\n",1789383985807]