search

OpenChain-Project / Reference-Material

This repository contains the reference material related to the OpenChain Project
Other
77 stars 57 forks source link

Distribution chain #56

Open kappapiana opened 1 year ago

kappapiana commented 1 year ago

I think the language here is too broad:

https://github.com/OpenChain-Project/Reference-Material/blob/175a79e30e86e53651a0e7b1b7d421e6a5486cd1/Adoption-Preparation/Model-Provisions/openchain-standards-model-provisions.0.5.md?plain=1#L121

The Supplier can warrant to accompany the material with a SBOM only when and for the extent they are in the distribution chain. Sometimes the supplier will publish updates directly, but most of the time they only provide their bit to the Customer, and the Customer takes over. So I think there is a need for adding some clarification language like (see the emphasis):

The Supplier warrants that any Open Source components contained within the Software are fully and accurately listed on each Software Bill of Materials made available to the Customer from time to time;
1.8.2.　Are accompanied by all Compliance Artifacts necessary to fully comply with the terms of the Open Source licenses applicable to all components contained within the Software when the Software is
1.8.2.1.　Delivered to the Customer; and*, in case the following acts of delivery are incumbent upon the Supplier*
1.8.2.2.　Delivered to any downstream distributor of the Customer; and
1.8.2.3.　Delivered to any End User [either as an installer package, a binary, a packaged delivered and installed through an app store, or delivered pre-installed into any device] as anticipated by the Use Case

the whole idea of a chain is that you only interact with your downstream, provide all the artifacts and the downstream takes care of it form there on (eg assembling the SBoM with other information gathered from other sources). Exceptionally, the Supplier has contact with further down acts of distribution, but that's more the exception than the rule, in my humble experience. No control, no obligation.

andrewjskatz commented 1 year ago

Hi Carlo This is an excellent point. I agree with the principle, but I'd like to suggest it's modified slightly. The specific concern that I have (which has come up in a few client engagements) is that the Supplier is compliant when supplying to the Customer (because they have provided all of the source to the customer), but when the Customer then passes on the developed app downstream, it's no longer compliant because, for example, the app is embedded in a device and there are no GPLv3 installation instructions, or there is no separate file of Compliance Artifacts because compliance from Supplier to Customer is carried out be providing all the licensing information embedded in the source. I'd hoped this would be addressed in the concept of the "Use Case" but I can see that this is doing some heavy lifting now.

Accordingly, can I suggest:

The Supplier warrants that any Open Source components contained within the Software are fully and accurately listed on each Software Bill of Materials made available to the Customer from time to time;
1.8.2.　Are accompanied by all Compliance Artifacts necessary to fully comply with the terms of the Open Source licenses applicable to all components contained within the Software when the Software is
1.8.2.1.　Delivered to the Customer; and*, in case the following acts of delivery are incumbent upon the Supplier _or are delivered with the intention that they shall be re-delivered unmodified by the Customer or a downstream distributor of the Customer_*
1.8.2.2.　Delivered to any downstream distributor of the Customer; and
1.8.2.3.　Delivered to any End User [either as an installer package, a binary, a packaged delivered and installed through an app store, or delivered pre-installed into any device] as anticipated by the Use Case

The wording is a little inelegant, but I think you understand the sentiment. I completely understand your comment about "control" which is why I have changed the wording so that the obligation should be conditional on these files being unmodified.

Many thanks

Andrew

kappapiana commented 1 year ago

The wording is a little inelegant, but I think you understand the sentiment. I completely understand your comment about "control" which is why I have changed the wording so that the obligation should be conditional on these files being unmodified.

Thank you Andrew, I am not attached to any particular language, I am fine as long as the concept passes through. Maybe someone could come up with a more streamlined language, but I'm good.