User Tools

Site Tools


openchain:spec-1.1-draft-public-comments

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
openchain:spec-1.1-draft-public-comments [2017/03/12 02:09]
mgisi [5) Suggest: Could be internal or external]
openchain:spec-1.1-draft-public-comments [2017/08/21 23:54] (current)
mgisi [14) Suggest: Discuss how we a reference to SPDX in the spec]
Line 25: Line 25:
  
 === Response: === === Response: ===
-Redefined "​Identified Licenses"​ to:  +There was 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
-**Identified Licenses** - //set of licenses governing ​the FOSS used to construct ​the Supplied Software.//+
  
 ---- ----
Line 66: Line 65:
  
 === Response: === === Response: ===
-TBD - [Mark: ​ Good point. There was a discussion on whether to keep or remove “is comprised” (and therefore “from which” should be removed as well). I would like to hold one more round to discuss whether “is comprised” should stay or go.]+The "from which" and "is comprised" phrases were retained
  
 ---- ----
Line 76: Line 75:
  
 === Response: === === Response: ===
-TBD - [Mark: ​We will likely clarify ​Identified Licenses to mean – the list of licenses of the FOSS components used to construct the software. Given that definition I believe Identified Licenses ​ in 4.1 makes more sense.]+We updated the "Identified Licenses" definition ​to make it more clear
  
 ---- ----
  
  
-==== 8) Suggest: ​zzzzzz ​====+==== 8) Suggest: ​Rewording of 2.1.2 for clarity ​====
 Submitted By: Sami Atabani and Jilayne Lovejoy Submitted By: Sami Atabani and Jilayne Lovejoy
  
Line 89: Line 88:
  
 === Response: === === Response: ===
-TBD - [Mark: As you point out the objective is to ensure the external role is assigned and a documented (internal) procedure exists to ensure this responsibility does not fall through the cracksI think it makes sense to clarify that the documented process is internal (as a minimum)That is – an internal process exists ​to ensure the external role & responsibility has been effectively resourced and thought through+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).
  
 ---- ----
Line 103: Line 102:
  
 === Response: === === Response: ===
-TBD - [Mark: I can see how the “escalation path” maybe a bit to specificThe intent here is to make sure an issue review and remediation process is in place. Whether escalation is a part of that is up to the implementerPerhaps we can talk about it in “review and remediation” ​ terms. I added this to the “to be discussed” list] +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
  
-==== 1) Suggest: zzzzzz ==== +2.1.2 A documented procedure exists that assigns responsibility for receiving FOSS 
-Submitted Byzzzzzzz+compliance inquiries. 
 + 
 +Might be revised to: 
 +2.1.2 An internal documented procedure exists for receiving and addressing FOSS 
 +compliance inquiries.
  
  
Line 117: Line 122:
  
 ---- ----
 +
 +==== 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 <​del>​as a result of that organization’s business practices</​del>​. That a procedure
 +exists to support this activity and that the procedure is followed.
 +
 +
 +
 +
 +=== Response: ===
 +TBD - 
 +
 +----
 +
openchain/spec-1.1-draft-public-comments.1489284545.txt.gz · Last modified: 2017/03/12 02:09 by mgisi