Am 06.01.25 um 07:55 schrieb Marta Rybczynska:
> Dear Ilu,
> It looks like I have touched a sensitive subject, sorry for that.
I'm sorry too. I'm getting a bit touchy because I see no progress.
Everybody is asking questions but this group is supposed to prepare the
answers - "to guide and support compliance". At least that's what I read
on the website. We will not get any answers about compliance by asking
the same questions over and over again.
Dirk-Willem gave answers by proposing a FAQ text and I gave answers by
proposing a different text (which, understandably, nobody liked).
Everybody else is just asking variants of the same question. But all of
us need to work on answers!
Agreed. Hopefully our move to GitHub will help facilitate this.
> I was thinking *only* about the situation of a project without a formal
> organization behind it,
> that does not have stable funding, developers doing their work mostly on
> volunteer basics.
> Every single one of us knows such projects.
>
> My impression was that this was the main subject that has been discussed
> over the last few days.
>
> For me personally, it seems to put all the manufacturer obligations on
> those who use their
> code in commercial products.
Yes, that is the intention. But there is a big grey area around the
"commercial" criterium and we don't know the outcome yet. And PLD is on
the horizon. There is a lot of good security related best-practice stuff
in CRA which even small projects can start on, if they prioritize it -
no matter whether they are in or out of CRA. Sticking with best
practices is always good.
The intended high-level purpose of the CRA is to steer the overall industry towards healthier security practices. This is something we ought to be aligned with as a community. The message shared by the European Commission on a regular basis is that we can have substantial impact shaping how this plays out through various means. So it's really up to us to drive the implementation of the CRA towards outcomes that are both meaningful in terms of improving our overall security posture and reasonable given available resources and the nature of how open source is developed.
An important aspect of the implementation of the CRA is the guidance described in Article 26 which must have a "particular focus" on "free and open-source software." The questions we collect in our FAQ and the answers we tentatively provide (as much as those where we don't have good answers and that we should clearly identify as such) is extremely valuable input for this guidance.
These security related requirements are also those that are relevant for
software stewards. That's what we need to help with. F.e. with a list:
What stuff should I start with for compliance?
> And I wasn't talking about the 'beta' versions. I was talking about the
> 'intended purpose' as in
> Annex II.
Yes, that information has to be provided if you are in scope of CRA. But
it does not determine whether you are in scope or not.
> I think that the 'intended purpose' has a big role to play, because this is
> the way I envisaged
> use for educational software that contains security issues to be found and
> fixed by students.
I'm not exactly sure what type of "educational software" you mean but
I'm sure that schools and students are generally a group that CRA is not
intended for. But a teacher could also have a side business or the
university could have a startup incubator (I know several that have) and
suddenly you are back in grey area. It always needs careful assessment
of the individual situation.
Increasing legal certainty for economic actors is part of the goals of this legislation (see for example Recital 4). The kind of uncertainty described above goes against this goal. This needs to be clarified through guidance. Our best opportunity to have impact here is to (1) clearly spell-out the areas of uncertainty, (2) spell-out what the ideal outcome would be that is aligned with the intended overall purpose of the CRA, (3) provide this as input to the Commission for the Guidance, and (4) hopefully obtain clarification before the guidance is out so that we can increasingly proceed on firmer ground.
> And I have read the CRA multiple times.
I'm sorry that I implied differently. I understand that it is an
extremely difficult read and in parts impossible to make sense of.
That's exactly why I'm warning to come to any conclusions of the "I'm
out of scope" type. Only time will tell who the EU authorities consider
to be in scope. And don't forget about PLD.
Regardless of whether you're formally in scope or out of scope of the CRA, the CRA (and other upcoming legislation worldwide) will impact your project if said project is used in products or services that end up in the hands of consumers and businesses. Indeed, manufacturers have a due diligence obligation here, defined in Article 13(5), and so facilitating this requirement will quickly become a standard practice (much like adding a license to your repo is) or a differentiator between projects. Worth noting that the CRA also offers an opportunity for manufacturers to foot part of the cost of shifting security left through the attestation program defined in Article 25.
Our best bet here is to make sure that the impact of the CRA is minimal in terms or resources, sound in terms of improving project's security posture, and potentially a vector of improved resourcing for the projects that do.
In summary, we need to:
- Improve our collective understanding of the CRA and spread that understanding across the community. This is best done through our FAQ effort.
- Identify areas that lack legal certainty and flag them with the Commission. Tracking a way to do so here: https://github.com/orcwg/cra-hub/issues/5
- Identify the elements that manufacturers will rely on to exercise their due diligence requirements defined in Article 13(5) and collect relevant best practices. As a start, I suggest leveraging the dedicated section I just added to our inventory.
- Explore the opportunities provided by the attestation program described in Article 25 and identify related efforts (like FreeBSD's SSDF attestation program). Here again, I believe collecting relevant resources in the inventory is a good first step.
Hopefully these suggestions will help address our shared desire to make progress and stand on firmer ground.
Happy to discuss all or any of the above further.