On 27 July 2026 the European Commission published Communication C(2026) 5252 and its annex, a guidance document on applying Regulation (EU) 2024/2847 on cyber resilience. It runs to 83 pages and 67 numbered examples, and devotes chapter 3 — paragraphs 40 to 89 — to free and open-source software. The general picture for manufacturers, covering scope, substantial modification, support periods and reporting windows, we cover on noze in a piece published the day after. Here I look only at that chapter, because it concerns those who maintain free software without selling it and holds the part that departs most from how the community is used to reasoning.

Two cumulative conditions

Article 3(48) of the regulation 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 of the guidance reads that sentence as two cumulative conditions: the licence must grant the full set of rights listed, and the source code must be openly shared.

The second condition is the one that moves something. Paragraph 46 clarifies that “openly shared” means publicly available, upstream or downstream, and not provided on a restricted or conditional basis; and draws the explicit consequence: software distributed under a free and open-source licence but whose source code is shared only with paying customers or a limited group of users is not FOSS within the meaning of Article 3(48).

It is not the first definition of free software written into a European regulation. Regulation (EU) 2024/903 on Interoperable Europe already defines an “open source licence” at Article 2(12) as one permitting reuse, redistribution and modification for all uses on the basis of a unilateral declaration by the right holder, “and where the source code of the software is made available to users indiscriminately”. The difference is that this defines the licence, whereas Article 3(48) defines the software, and makes that qualification the gateway to a compliance regime with market surveillance. The Open Source Definition reasons about the rights a licence grants; this one adds a requirement about the publisher’s conduct. A project can carry an OSI-approved licence and still fall outside the regulation’s notion of FOSS, if the source is not public.

Publishing and contributing

Paragraph 49 addresses the question the community has been asking for years whenever responsibility comes up: in a project with many contributors, who answers. The guidance’s answer is that free software is “under the responsibility” of the natural or legal persons who publish it and exercise primary control over development, releases and distribution decisions — the maintainers. Anyone contributing code without controlling releases, roadmaps or governance is a contributor, and the software is not under their responsibility even though they wrote part of it. It is the distinction that fifteen years ago carried no legal weight and served only to work out whom to thank.

The guidance then specifies that “the mere existence of technical permissions, such as commit access, is not sufficient to establish that the FOSS is under that person’s responsibility”. Write access to the repository does not transfer responsibility. Example 13 applies this to the commonest case, a pull request with a security patch accepted by the maintainers: the person who submitted it is a contributor and is not subject to the regulation.

Donations

The regulation does not look at how a project was financed but at whether it is monetised. Paragraphs 63 and 64 say so for development funding: the fact that a third party paid for, sponsored or otherwise financed the development does not in itself determine whether the software is placed on the market, because — recalling recital 18 — the circumstances of development and how it was financed are not to be taken into account when determining the commercial nature of the activity.

On donations the guidance is more explicit than one would expect. Paragraph 61 states that merely including a link to a donation platform is not to be read as an intention to make a profit even where the amount collected exceeds the costs of design, development and provision, and that this includes reasonable compensation for contributors hired by a legal person and a natural person’s reasonable living expenses. The verbatim conclusion is that a project supported only through donations “is therefore unlikely to be considered to be placed on the market”.

The same holds for technical support offered to cover costs: paragraph 58 includes among recoverable actual costs “the person’s reasonable living expenses”, so a natural person publishing FOSS and offering technical assistance to cover their costs and obtain fair remuneration does not, on that basis alone, place the software on the market.

The line falls where a donation becomes a price in fact. Paragraph 62 and its two examples place it precisely: if downloadable releases and security updates go only to those who donate (Example 21), or if pre-compiled binaries and guaranteed fixes are reserved for donors while the source stays public (Example 22), then the donation is remuneration and the software is placed on the market.

Not-for-profit entities, foundations, stewards

Paragraph 66 deals with not-for-profit legal persons set up so that all earnings after costs go to not-for-profit objectives: the software they publish is not considered placed on the market. Example 24 illustrates it with a free browser monetised through search engine partnerships whose earnings serve not-for-profit objectives, and concludes that such a body does not place on the market but is subject to stewards’ obligations.

The steward is the category Article 3(14) introduces for cases where free software is published but not made available on the market: a legal person, other than a manufacturer, whose purpose is systematically to provide support on a sustained basis for the development of free software intended for commercial activities, and which ensures its viability. Paragraph 78 brings within it those foundations that offer collaboration platforms with governance arrangements letting manufacturers contribute regularly, or that are regularly financed by manufacturers.

Two clarifications head off the wrong reading, which would attach the status to the body rather than the project. The status is assessed project by project: paragraph 72 establishes that being steward of one piece of free software does not imply being steward of others published by the same body, and paragraph 73 that the same legal person can be steward of one project and manufacturer of another. The typical case is publishing a community version and a paid version of the same software: steward of the first, manufacturer of the second.

Three levels of support, three sets of obligations

The operative part is paragraph 79, which distinguishes the type of sustained support and derives different obligations from it by way of Article 24(3). All stewards must in any case comply with Article 24(1) and (2), that is, put in place a verifiably documented cybersecurity policy and cooperate with market surveillance authorities. The documentation required is of the same kind the regulation asks of manufacturers, where the obligation that counts is that someone actually verifies it.

  • Non-technical support only — brand management, governance rules, events, collecting donations. Paragraph 80: not being involved in development, this steward is not required to report actively exploited vulnerabilities, and providing no network and information systems, is not required to report severe incidents. Where it becomes aware of an actively exploited vulnerability it should share this with the maintainers.
  • IT infrastructure — repositories, version control systems, generation of signing keys. Paragraph 81: it is required to notify ENISA and the CSIRTs, under Article 14(3), of severe incidents affecting that infrastructure with an impact on product security, and to inform users where appropriate.
  • Engineering resources — employed developers, coordinating development, reviewing and merging code, managing releases, handling vulnerability reports and security patches. Paragraph 82: it is required to notify under Article 14(1) the actively exploited vulnerabilities it becomes aware of, to inform all users where appropriate, and to inform impacted users directly where it has a direct relationship with them, under Article 14(8).

This is the scale that lets a foundation work out which band it falls into, and it turns not on size but on what it concretely does for that project.

The date the text does not give

On this point the two texts do not give a single answer.

Article 71(2) of the regulation provides that the text applies from 11 December 2027, with two exceptions brought forward: “However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026”. Article 24, which holds the stewards’ obligations, is not among the provisions brought forward.

Article 14, however, is titled “Reporting obligations of manufacturers” and its first paragraph provides that “a manufacturer shall notify”. By its own terms it binds manufacturers. A steward is reached only through Article 24(3), which extends to stewards the obligations in Article 14(1), (3) and (8) within the limits set out above.

From this follows a question the regulation does not close: if the reporting obligation reaches a steward through a provision applying from December 2027, does the September 2026 anticipation touch it? The reading closest to the text is that it does not, because Article 14 alone does not address stewards. The opposite reading is available, treating Article 24(3) as a rule about the scope of obligations that travel with the provision brought forward. The Commission’s guidance discusses stewards inside the section devoted to Article 14 without addressing the point.

For a maintainer the difference is fifteen months, and as things stand it cannot be derived from the published documents.

Limits

The above is a reading of two texts, the regulation and a guidance document. The guidance itself states at paragraph 89 that the chapter’s scenarios are entirely hypothetical, and a Commission communication does not bind the courts: the definitive interpretation of the Article 3 definitions rests with the Court of Justice, and national surveillance authorities may depart from it.

There is no census of how many foundations or projects fall within the definition of steward, so any figure on that would be invented. I have not verified which harmonised standards supporting the regulation have been cited in the Official Journal, and I do not assert it. And the classification of any single project turns on circumstances outside the documents — who controls releases, how the body is constituted, what exactly a donor receives — so the three categories described here are for reading your own case, not for settling it.

Cover image: base-measuring apparatus, Gebrüder Brunner, Paris 1876-1878, exhibited by the GeoForschungsZentrum Potsdam — photograph by Bautsch, CC0 — https://commons.wikimedia.org/wiki/File:Basisapparat.Gebrueder.Brunner.Paris.1878.jpg