Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] Stewards, open source projects etc


On Tue, Aug 6, 2024 at 9:43 AM Tobie Langel via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
I'm wondering at what point (if any) the model of payment (donation) for attestation turns an open source stewart into a manufacturer.

I'd be interested in the EU's perspective on this. I could see an argument that providing an Attestation no more makes an OSS Project a Manufacturer as an audit from a Third Party Assessor makes the Assessor a Manufacturer.
 

--tobie

On Tue, Aug 6, 2024 at 3:14 PM Greg Wallace via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
I wonder if this may be a relatively straightforward situation of demand and supply.
  • DEMAND: Attestations help Manufacturers comply 
  • SUPPLY: OSS projects are well positioned to provide Attestations for their code and how it is developed (though this is not required of them by the CRA nor by any OSS license)
A "Donation for Attestation" framework would have OSS Projects make Attestations available to donating Manufacturers under fair and reasonable terms  (e.g. graduated donations based on Manufacturer size).

Ensuring OSS Projects meet Manufacturers' security requirements as threats evolve will require ongoing investment. If we leave the source of funds for these investments up to the traditional mechanism of at-will donations by Manufacturers to OSS Projects, Projects risk receiving insufficient funds and we are left with the free rider problem. I would argue that this is suboptimal for Manufacturers (especially the "good ones" who invest in OSS), for Projects, and for the security of our shared digital society, for which OSS is a key foundation.

A "Donation for Attestation" model addresses these shortcomings by enforcing a degree of equitability, which brings the important side benefit of creating funding diversity for the Project to protect against any one large donor's change of direction or fortunes. "Donation for Attestation" provides the funds for the Project to build and maintain security processes and tooling and to produce the Attestations. And "Donation for Attestation" is a durable funding mechanism since Attestations are attached to major releases.

[ducking and covering] 🙂

On Tue, Aug 6, 2024, 2:47 AM Olle E. Johansson via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:


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
 
Best regards
Georg
 
 
 
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.
 
 
On Mon, Aug 5, 2024 at 7:52 AM Greg Wallace via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
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


On 5 Aug 2024, at 13:17, Greg Wallace <greg@xxxxxxxxxxxxxxxxxxxxx> wrote:
 
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:
 
 
Cheers,
Greg
 
On Mon, Aug 5, 2024 at 7:10 AM Olle E. Johansson via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

 
-- 
Greg Wallace
Director of Partnerships & Research
M +1 919-247-3165
 

 
-- 
Greg Wallace
Director of Partnerships & Research
M +1 919-247-3165
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

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


--
Greg Wallace
Director of Partnerships & Research
M +1 919-247-3165

Back to the top