Re: [open-regulatory-compliance] Kicking off the CRA Attestations projec

[Luis Villa <luis@xxxxx>]

Without having been in the room, I would suggest that the framing around who can do an assessment is less about "who can do it" and more "do the presumptions of validity change based on who does it". 

We're always going to need to allow third parties to do assessments, because many key projects are either unmaintained or maintained by people who have no interest in this problem. But the standard of evidence for a non-maintainer/steward assessment should be high, both as a simple factual matter (they are by definition not the most relevant experts in the code) and as a policy matter (you want to provide an incentive to work with the maintainers or to move off unmaintained code).

On Fri, Oct 24, 2025 at 9:53 AM Scott Lewis via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

On 10/23/2025 9:03 AM, Greg Wallace via open-regulatory-compliance wrote:

<stuff deleted>

2.  Given that a manufacturer can always fulfill their Article 13(5) due diligence by conducting an internal assessment or by commissioning a private one from any third party, what is the justification for proposing to limit who gets to issue attestations under Article 25? This refers both to the proposals I heard in the room allowing an open source project to select who gets to issue article 25 attestations or limiting it to - for example - stewards.

I've thought about this a lot. In my view, Community is inseparable from Open Source. And so any effort to address the security compliance of open source must actively include Community in the solution. Community members are typically:

• the most apt people to audit (or oversee the auditing of) the security of a project and its development processes
• the most expert people to address any security issues, whether uncovered by an initial assessment or found in the natural course of operations
• or both

Hear, hear.   

I think this bears repeating:  And so any effort to address the security compliance of open source must actively include Community in the solution.

_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org