User Tools

Site Tools


openchain:spec-1.1-draft-public-comments

This is an old revision of the document!


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:

Redefined “Identified Licenses” to: Identified Licenses - a set of licenses governing the FOSS used to construct the Supplied Software.


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: zzzzzz

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.


openchain/spec-1.1-draft-public-comments.1489341187.txt.gz · Last modified: 2017/03/12 17:53 by mgisi