Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] Open Source Software Stewards and CRA Whitepaper: review in progress until November 20th

On 10 Nov 2025, at 10:36, Elizabeth Mattijsen via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

On 10 Nov 2025, at 10:20, Olle E. Johansson <oej@xxxxxxxxxx> wrote:
On 10 Nov 2025, at 10:15, Elizabeth Mattijsen via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
There’s no requirement for Open Source projects to have a steward, and no requirement to have any legal body.
True.  But then either the Open Source project will not be used in a commercial setting, or the manufacturer will eventually usurp and/or drop the project.
I am sorry, but I don’t follow you. The manufacturer will be fully responsible for all components in the product
regardless if there’s a steward upstream or not.

Right.  So the manufacturer may either support the Open Source project in some way, or fork it and take complete responsibility.

Correct - or in practice - if the manufacturer does nothing in terms of interacting with the open source project - it (or its (cyber & product liability) Insurance company) effectively needs to assume that the manufacturer has taken a snapshot, or a `fork' on a certain day - and then needs to pro-actively maintain (and be able to provide evidence to that effect when asked) that `fork'.

So the default is the other way round - you are assumed to be fully responsible on any and all code you place on the market.

And then by doing the right thing - e.g. collecting attestations from your upstream, contracts, etc - you can reduce your burden.

And even though the CRA states (as I'm led to understand) that the manufacturer would be required to produce any fixes upstream (regardless of whether the license actually requires this), I don't see this (easily) actually enforced in reality.

I am not holding my breath for the regulators; but I am very much expecting the insurances and underwriters to become very uppity & in effect become a regulating force. 

As (with strict liability coming in through the PLD as a double whammy) - company directors are loath to personally step into firing lines that cost them privately.

IMHO - I would argue that the EC has learned after the GDPR fiasco & put some more stick into things this time.

The change with the steward is outlined in our
paper, but maybe not from a manufacturer’s point of view. With a steward upstream, chances are better that
there’s a working security process.

And a steward would be a legal body, or not?

Also here - the CRA turns this 180 aground - a stewards -must- be a legal person ([1 - 3.(14)] and by extension cannot be a natural person (3.14 is the only place that the CRA applies only to a legal person - everywhere lease it applies to  natural or legal persons.

We’re working on the attestations to figure them out, but they
*MAY* be a way to simplify the manufacturer’s due diligence.  A steward may also have a process
to be more clear about lifecycle events for an open source project.

Well, they should.  Otherwise they wouldn't be much of a steward?

Not sure I agree - the obligations of a steward are lesss [1 - 3.14)] - and article 25 is clear that it is optional and voluntary [2 - 25]

The risk of projects dying or being end-of-life is very similar to projects without a steward. In those cases
the manufacturer will just have to make a decision to take the risk and continue using the software or switch to another solution.

That's what I meant with "usurp and/or drop".  Because any sane company "taking the risk" would want to have control.

Agreed - and I think we need to stress perhaps more that this is the `default' for our downstream. 

Dw.



3.(14)

‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;


2: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

Article 25

Security attestation of free and open-source software

In order to facilitate the due diligence obligation set out in Article 13(5), in particular as regards manufacturers that integrate free and open-source software components in their products with digital elements, the Commission is empowered to adopt delegated acts in accordance with Article 61 to supplement this Regulation by establishing voluntary security attestation programmes allowing the developers or users of products with digital elements qualifying as free and open-source software as well as other third parties to assess the conformity of such products with all or certain essential cybersecurity requirements or other obligations laid down in this Regulation.


Back to the top