Differences

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

--- openchain:spec-1.1-draft-public-comments [2017/03/12 17:01]
mgisi [9) Suggest: escalation path is a bit too hairy sounding]
+++ 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: ===
-Redefined "Identified Licenses" to:
+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.
-**Identified Licenses** - //a set of licenses governing the FOSS used to construct the Supplied Software.//
 ----
@@ Line 81: / Line 80: @@
-==== 8) Suggest: zzzzzz ====
+==== 8) Suggest: Rewording of 2.1.2 for clarity ====
 Submitted By: Sami Atabani and Jilayne Lovejoy
@@ Line 107: / Line 106: @@
 ----
+==== 10) Suggest: Clarifying responsibility for receiving FOSS compliance inquiries ====
+Submitted By: Jilayne Lovejoy
-==== 1) Suggest: zzzzzz ====
+.1.2 A documented procedure exists that assigns responsibility for receiving FOSS
-Submitted By: zzzzzzz
+compliance inquiries.
+Might be revised to:
+.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.3 A documented procedure exists that assigns responsibilities for FOSS compliance.
+.2.4 A documented procedure exists that identifies an escalation path for issue resolution.
+Could consider something along the lines of:
+.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.3 A documented procedure exists that assigns responsibilities for FOSS compliance.
+.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.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
+.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
+.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.
+.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 -
+----

Wiki

User Tools

Site Tools

Differences

Page Tools