On 5 Aug 2024, at 18:02, Georg Kunz via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Hi Joe, I’d say that this is not a perverse incentive for open source projects, but very much a valid option for all maintainers of open source projects. It comes down to the fact that many projects and their maintainers are NOT suppliers to commercial users. Thus, why should these maintainers take the extra effort and risk of producing an attestation? The correct approach would be that commercial users of a project should actively offer support to maintainers of said projects in for instance implementing security best practices and if accepted an attestation may be an option. I believe this sort of incentive is meant to be fostered by the due diligence requirements of the CRA. We should not simply demand form every open source maintainer to produce attestations.
Unless there is funding, it will not happen by itself. If Github/Gitlab and similar platforms offers attestations as part of their platform a lot of projects will move towards that.
I am worried about what will happen if manufacturers start putting pressure on projects and don’t offer funding or resources to assist.
/O To the extent that there are (lots of) OSS projects without stewards, I'm unclear what the methods are for them to get or produce attestations that the software they are publishing is developed in a secure fashion. Are there (perverse) incentives for these projects to not create an attestation as they would accrue liability if an incident occur that led to damages? For example, my understanding is that in the case of leakage of PII, a common method to mitigate the damage is to provide packages costing about USD$180 each to users to help them prevent identity theft. Joe Murray, PhD (he/him) President, JMA Consulting 416.466.1281 We respectfully acknowledge the autonomy of Indigenous peoples, and that JMA Consulting is located on the traditional territory of many nations including the Mississaugas of the Credit, the Anishnabeg, the Chippewa, the Haudenosaunee and the Wendat peoples which is now home to many diverse First Nations, Inuit and Métis peoples. We also acknowledge that Toronto is covered by Treaty 13 with the Mississaugas of the Credit. I see, thanks for the detail. My sense ( and this is just my sense and IANAL) is that in this case, your relationship to this OSS that matters to the CRA is that of a manufacturer that places the SW on the market. On Mon, Aug 5, 2024 at 7:44 AM Olle E. Johansson < oej@xxxxxxxxxx> wrote: Hi! While this is a good slide there are still questions it doesn’t answer. I contribute to an open source project and sell services related to the use of that software. I’m in no way managing the project as a whole. There are many people from many - mostly small - companies all over Europe contributing to the project. There’s no company behind the project. We do distribute Debian packages of the product. Are we all Open Source Stewards for the project? Are we all manufacturers since we monetise from the project by selling services? /O
Hi Olle, I find this slide from the recent webinar on Jul 22, 2024 | "The CRA obligations: Identifying the relevant obligations for the OSS community" helpful to suss out how CRA applies (if at all) to different types of open source: Hi! In Enzo’s presentation there are two examples, but both involves commercial companies and/or foundations. What about stand-alone multi-organisation open source projects? How will they be affected? In addition, there are discussions about whether projects that *ONLY* distribute source code and no binaries, no containers, are affected. Is source code (possibly on an open repository) seen as a product that is placed on the EU market? Cheers, /O _______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org
-- Greg Wallace Director of Partnerships & Research
-- Greg Wallace Director of Partnerships & Research
_______________________________________________open-regulatory-compliance mailing listopen-regulatory-compliance@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org
|