Re: [open-regulatory-compliance] Maintainer considering removing project

[Dirk-Willem van Gulik <dirkx@xxxxxxxxxxxxxx>]

On 20 Dec 2024, at 14:35, Daniel Thompson-Yvetot via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
> 
> A little hack crossed my mind today:
> 
> What if everyone clearly labelled their OSS software as BETA and unfit for any (commercial) purpose. There is a specific carveout that says that even those that will be classified as Manufacturers can't put a CE marking on Beta products (that are not sold / aka used for QA purposes)...
> 
> That might calm the OSS waters for a bit.


I think you want to lift the helicopter a bit - what is the intention of the CRA ?

It is, basically, to make software safer - as to prevent harm. Or in more economic terms - so that society does not pay the cost of bad security and we all lose (i.e. prevent externalisation). The business case behind the CRA is solid; even if all software / release engineering get 30% or 50% more expensive - we probably make that back within the year.   Secondly - 95% of any given (commercial) software stack or service is essentially open source. If it is SaaS; probably more 99%.

So if above hack where to work - you'd be looking at a CRA-II in no time. As the intention of all this is making software safe. Just like - over the years - we've learned how to keep steam boilers from exploding, bridges from collapsing, not have another Thalidomide scandal, prevent mass food poisoning & bad water, prevent large outbreaks of diseases and so on. 

Secondly - if things quack like a duck, walk like a duck and look like a duck - do not be surprised if the legal system (in Europe) treats them like a duck. And in this it is not so much the regulators who are in control - but the insurances and underwrites that cover mandatory/legal product liability far downstream.

Because, in all fairness, popular open source a lot of `productisation' and `release engineering' that often demonstrates an expectation, intend and desire to make it easy to be used by others. Which is a far cry from code developed by a hobbyist or an academic  for another hobbyist or researcher. Or code that is intendend for inhouse use that happend to be shared on a `your milage may vary' basis.

So I would urge us to not go down that path.

But instead - just like open source has done in the security field - where responsible disclosure is now the _norm_ -- set the industry standards on responsible release processes (version number, no known CVEs, release notes with any residual CVEs, SBOMs, triage based bug & vulnerability processes and so on). That list is not long.

With kind regards,

Dw