Table of Contents
Public Comments for Specification Version 1.1
The final release candidate of the OpenChain 1.1 specification can be found here:
OpenChain Compliance Specification version 1.1
The development of the OpenChain specification functions like an open source project by obtaining input from dozens of companies and organizations that have experiences preparing for and/or exchanging software in the software supply chain. There were no specific requirements for participating. Once we had a stable release candidate we solicited for public comments which are listed below. During this last phase of the specification release we will try to accommodate feedback that does not result in a material or semantic change (for example avoid changing a definition, adding or materially changing a requirement, and so forth). Any feedback not accommodated in version 1.1 will be carried over and be given priority consideration in the next release of the spec.
1) Suggest: Verification Artifacts are not intended to be public
Submitted By: Luis Villa
The language in the FAQ noting that Verification Artifacts are not intended to be public, and could be provided under NDA or through a third-party, should be pulled into the introduction to the main document - it is critical context when assessing how burdensome this process will be.
Response:
Add the following text to the introduction to clarify: Verification Artifacts are not intended to be public, but could be provided under NDA or upon private request from the OpenChain organization to validate conformance.
2) Suggest: Definition of "Identified Licenses" is somewhat circular
Submitted By: Luis Villa
The definition of “Identified Licenses” is somewhat circular. Is the outcome there a list of acceptable licenses, or a list of licenses actually used in the Supplied Software?
Response:
There was a fair amount of discussion and proposals on how to update the definition to be more clear. It was decided, due to limited time, to move this discussion to the next version where we can give it the time it deserves.
3) Suggest: Not clear what it means to "address" the typical use cases
Submitted By: Luis Villa
In 3.2, I'm not clear what it means to “address” the typical use cases. Do you mean that the program must be able to answer outside vendor questions about these use cases? That it must evaluate/analyze what might happen if the Supplied Software is used in those use cases?
Response:
An organization must have a process that determine which use cases exist for their situation and how to handle it. How one actually responses is left to the legal interpretation of the respective organization. This requirement is more about the existence of a process. That is, an outside vendor should expect to find that a process exists to handle the common use cases but there is not expectation on how precisely one should conduct a given use case. Modifications were made to better clarify this.
4) Suggest: A mere email address should be insufficient
Submitted By: Luis Villa
In 2.1.1, a mere email address should be insufficient - it has to be published somewhere. So I might adjust to say “e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory” (I might add a link to the OCD as well.)
Response:
The recommended update was made.
5) Suggest: Could be internal or external
Submitted By: Luis Villa
2.2: “could be internal or external” may make more sense in 2.2.2? “Identify source… available to …. roles. Could be internal or external.”
Response:
The recommended update was made.
6) Suggest: 3.1.1. - is comprised wording review
Submitted By: Luis Villa
3.1.1: If “from which” is being removed, then “is comprised” should also be removed, I think?
Response:
The “from which” and “is comprised” phrases were retained.
7) Suggest: Prepare the artifacts that are required by each Identified License
Submitted By: Luis Villa
4.1: Might be simpler to say “Prepare the artifacts that are required by each Identified License contained in the Supplied Software”? But depends on if/how “Identified License” is clarified.
Response:
We updated the “Identified Licenses” definition to make it more clear.
8) Suggest: Rewording of 2.1.2 for clarity
Submitted By: Sami Atabani and Jilayne Lovejoy
2.1.2 A documented procedure exists that assigns responsibility for receiving FOSS compliance inquiries - where is this supposed to be documented? Internally? 2.1 and 2.1.1 are talking about the public-facing FOSS liaison but I don’t think this procedure needs to be public, correct? My interpretation of this is to avoid the age-old issue of having an email for compliance enquiries and then no one checks it or responds appropriately – I think this verification artifact is trying to avoid that, but I’m not sure it’s as clearly stated (for someone looking at this new/fresh) as it could be??
Response:
The text for 2.1.2 was updated to clarify that the procedure could be internal (i.e., it does not need to be made public).
9) Suggest: "escalation path" is a bit too hairy sounding
Submitted By: Sami Atabani and Jilayne Lovejoy
Likewise, 2.2.4 could maybe use some clarification: 2.2.4 A documented procedure exists that identifies an escalation path for issue resolution. - as 2.2 is about identifying internal roles, I would assume that this is referring to internal issues, but it’s a bit unclear and I think part of the issue is that issue “escalation path” is a bit too hairy sounding. Practically speaking, what are we talking about here (and how is this really different than 2.1.2?)
Response:
TBD - The text for 2.2.4 was updated to clarify that the step is focused on non-compliance remediation (as opposed to the vague statement around escalation.
10) Suggest: Clarifying responsibility for receiving FOSS compliance inquiries
Submitted By: Jilayne Lovejoy
2.1.2 A documented procedure exists that assigns responsibility for receiving FOSS compliance inquiries.
Might be revised to: 2.1.2 An internal documented procedure exists for receiving and addressing FOSS compliance inquiries.
Response:
TBD -
11) Suggest: Clarification on assigning responsibilities for FOSS compliance
Submitted By: Jilayne Lovejoy
For reference, 2.2.3 and 2.2.4 currently state: 2.2.3 A documented procedure exists that assigns responsibilities for FOSS compliance. 2.2.4 A documented procedure exists that identifies an escalation path for issue resolution.
Could consider something along the lines of: 2.2.3 A documented procedure exists that assigns responsibilities for FOSS compliance, including issue resolution
If its deemed that we need to keep these as two different items, then maybe: 2.2.3 A documented procedure exists that assigns responsibilities for FOSS compliance. 2.2.4 A documented procedure exists that identifies an escalation path for FOSS compliance issue resolution.
Response:
TBD - Updated 2.2.4 to read: 2.2.4 A documented procedure exists for handling review and remediation of non-compliant cases.
12) Suggest: Adding 3.1.2 Verification Artifact
Submitted By: The general group discussion
3.1.2 Records exist that demonstrate the document procedure was followed for each Supplied Software release.
Response:
TBD.
13) Suggest: texted edit
Submitted By: Jilayne Lovejoy
3.1.2 One small edit: 3.1.2 should be “documented” not “document” :)
Response:
Fixed.
14) Suggest: Discuss how we a reference to SPDX in the spec
Submitted By: General group discussion.
Section 4.1 was rewritten several months back to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively.
4.1 Prepare the set of artifacts that each Identified License requires accompany the Supplied Software. They include but are not limited to the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers and so forth (Compliance Artifacts).
SPDX was not included in the definition because it is not a requirement of any open source license. If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specifications. Suggestions?
Response:
The section + definition were re-written to include a reference to SPDX.
15) Suggest: Minor feedback in section 2.1
Submitted By: Jilayne Lovejoy
in 2.1 and the specificity of “electronic communication” and “via a published contact email address” is really just a question I had as to whether we mean to be that narrow/specific - if I recall, the LF list has both email and phone number and I’d think a phone number would be fine too? In any case, not a key issue, more of a question/clarification.
Response:
TBD -
16) Suggest: Minor edit to section 3.2 rationale
Submitted By: Jilayne Lovejoy
The only other minor edit I had was some wording that I thought seemed a bit extra in the 3.2 Rationale - I was thinking the when it says “an organizations’ typical common FOSS use cases…” that seemed like enough and that “as a result of that organization’s business practices” seems to be saying the same thing in a different way.
3.2 Rationale
To ensure the FOSS management program is sufficiently robust to handle an organization’s
common FOSS use cases as a result of that organization’s business practices. That a procedure
exists to support this activity and that the procedure is followed.
Response:
TBD -
