[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [open-regulatory-compliance] Maintainer considering removing project due to CRA obligations and uncertainty
|
Howdy,
On 12/19/2024 9:32 AM, Seth Michael Larson via
open-regulatory-compliance wrote:
Thanks all for the replies, here are some thoughts from me:
> I'd be particularly interested in a description of the minimum steps
required to transfer CRA responsibilities to a FLOSS steward, say
hypothetically the PSF or a cooperative of Python consultants.
I'm not sure the PSF or any other foundation like it is in a position
to absorb all projects under, in our example, PyPI. However, we still
have our eyes on lowering the bar, for example I have plans this
upcoming year to make complying with the "vulnerability reporting" and
"market surveillance compliance" easier for maintainers.
Although I support every desire and effort to make things easier for
maintainers, I can tell you:
1) The Eclipse project I maintain (ECF) is independent committer led (me)
2) Is a -1 dependency for the Eclipse IDE...we provide the file transfer
(e.g. https/ssl) api for Eclipse implemented by multiple third-party
provided impls (e.g. httpclient).
3) As part of the Eclipse Platform, ECF filetransfer (at least) will
likely be subject to vulnerabilities and regulations applying to the
Eclipse IDE install/update mechanism (called equinox p2) and our
third-party dependencies (equinox, provider impls, Eclipse Platform).
Things like an official location for a security policy, report a
vulnerability, and a process for contacting all relevant market
surveillance groups (CISA, ENISA, etc) in the case of actively
exploited vulnerabilities. I think these sorts of developments are
much more within our resourcing. That doesn't provide the resourcing
and time it takes to operate those facilities (so is still a burden on
solo-and-low-maintainer projects), but at least there's more clarity
about what is actually needed from folks and for external groups to
not "spook" maintainers with official and legalese-sounding emails
that you are now legally obligated not to ignore.
Although I have only read some of the DCA and am not a lawyer, and
appreciate the efforts that went into having a category of open source
'steward' recognized in the DCA, currently there is every reason to
expect that if faced with the burdens under discussion, I would be/am
'spooked' in a way similar to Seth's colleague.
I know that I do not have the personal resources even to continue as the
project steward, cannot absorb the additional maintenance burden (e.g.
responding to and addressing vulnerabilities or procedure), and
certainly cannot/will not absorb new legal risk.
FWIW, I do think that there should be additional thought in this group
to the 'open source steward spooking' problem identified by Seth.
Scott
https://eclipse.org/ecf