Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distribution chain #56

Open
kappapiana opened this issue Sep 6, 2023 · 2 comments
Open

Distribution chain #56

kappapiana opened this issue Sep 6, 2023 · 2 comments

Comments

@kappapiana
Copy link
Collaborator

I think the language here is too broad:

#### 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 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
Copy link
Member

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
Copy link
Collaborator Author

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.

shanecoughlan added a commit that referenced this issue Sep 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants