I share a similar understanding, Greg. And yes, the how is not yet fully determined, but it follows other EU product rules. It means: following harmonized standards is voluntary anyways, even if you are a manufacturer of critical products, it just will make it easier in many regards.
In my point of view the most important part to grasp is all in Annex I as it lays out the essential requirements pretty straight forward. How (and in fact: if) you fulfill these requirements is your decision, the regulation just asks you kindly to go through it and explain how you do your assessment and encourages you to do so with a standard or established best practice. The question that hits here is just if users (or manufacturers in that regard) are able to deal with it in their risk management model, it’s simply their problem. And they want OSS to have these attestations to tick a (or numerous) box(es). I think what really only matters is the CVD/CVR anyways, that the essential .
For everything that is not a critical product it’s all self-assessment in the OSS land, the EC is happy with whatever you come up with and makes things more secure (they literally said it numerous times in the past but also in the presentations here). And apart from that, if you don’t follow any of it, there’s not a lot that can be done, the CRA has extremely broad exceptions — as long as it is not a critical product. In this case you have to get the okay by a NANDO *before* you can legally put it on the market in the EU (although there’s an extra layer of depth).
And btw a very common misunderstanding: The CRA does not contain liabilities, only obligations. Liabilities are in the PLD (Product Liability Directive), and Recital 14 exempts OSS.
On 5 Aug 2024, at 14:09, Greg Wallace via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
I have a slightly different understanding.
The manufacturer is responsible for the security of their product, including any third party components they include, regardless of how those components are licensed.
HOW the manufacturer determines that their entire product is secure, up to the standard required for their category, is not completely prescribed by the CRA.
An Attestation as to the security of an OSS project is ONE WAY a manufacturer can demonstrate that they performed appropriate due diligence.
A third party audit could be another way.
Questions I have here are:
- would the output of a third party audit be an Attestation?
- would this Attestation conform to some standard?
- if an Open Source Steward offers an Attestation, what obligations does a third party auditor have to consult with the Steward and/or conform to the Steward's Attestation?
Of course I'm very interested in others' thoughts. Perhaps the answers are understood.
Thank you!
Greg
Hi!
Hopefully a final question based on Enzo’s excellent presentation (go watch it if you haven’t).
If I understood Enzo right, a manufacturer can’t include a open source component without a valid attestation.
The way I see it is if a manufacturer includes Open Source software and that project either dies, remains or becomes non-compliant it will still be the responsibility of the manufacturer to make sure the full product placed on the EU market is compliant.
Is this an invalid assumption?
Cheers,
/O
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
-- Greg WallaceDirector of Partnerships & Research
M +1 919-247-3165
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
