Differences

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

--- openchain:spec-2016-h1-public-comments [2016/07/18 15:54]
mgisi
+++ openchain:spec-2016-h1-public-comments [2016/10/05 00:03] (current)
mgisi
@@ Line 1: / Line 1: @@
-====== Public Comments for Specification Version 2106-H1 ======
+====== Public Comments for Specification Version 1.0 ======
-The final release candidate of the OpenChain 2016-H1 specification can be found here:
+The final release candidate of the OpenChain 1.0 specification can be found here:
-{{:openchain:openchainspec-2016-05-16-1.pdf| OpenChain Compliance 2016-H1 Specification}}
+{{:openchain:openchainspec-1.0.pdf| OpenChain Compliance Specification version 1.0}}
-The development of the 2016-H1 version of the spec functioned 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 the 2016-H1 version will be carried over and be given priority consideration in the next release of the spec.
+The development of the version 1.0 of the spec functioned 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.0 will be carried over and be given priority consideration in the next release of the spec.
@@ Line 33: / Line 33: @@
 ----
-==== 3) Suggested removing historical view from Introduction ====
+==== *3) Suggested removing historical view from Introduction ====
 Submitted By: Martin Yagi
@@ Line 74: / Line 74: @@
 ----
-==== 7) Request to Add text stating value of compliance in generally has value ====
+==== *7) Request to Add text stating value of compliance in generally has value ====
 Submitted By: Karen Sandler
@@ Line 117: / Line 117: @@
-==== 11) Suggest including: "scripts used to control compilation and installation"  ====
+==== *11) Suggest including: "scripts used to control compilation and installation"  ====
 Submitted By: Karen Sandler
@@ Line 146: / Line 146: @@
 === Response: ===
-TBD
+The discussion led to a more generation concern to update the definition of "FOSS Liaison" to be more general:
+FOSS Liaison: a designated person who is assigned to receive external FOSS inquires.
+And to change the wording of bullet #1:
+from: Assign individual(s) responsible for receiving FOSS compliance inquiries;
+to: Assign individual(s) responsible for receiving external FOSS inquiries;
+The word: "compliance" was removed to make it more general.
 ----
@@ Line 156: / Line 166: @@
 === Response: ===
-TBD
+It was agreed that the wording of the last (4th) bullet needed to be simplified. The decision was to: remove the last bullet; update the 3rd bullet:
+to: Publicly identify means of contacting the FOSS Liaison by way of electronic communication.
+and to move the "the Linux Foundation’s Open Compliance Directory" to the e.g, for the first Verification Artifact (along side "an email address").
 ----
@@ Line 169: / Line 183: @@
 === Response: ===
-TBD
+Its was decided to leave the word "Function" - the general consensus was to maintain the concept of a function as opposed to an individual (although an individual could single handily serve as the function). It was also decided to make sure all uses of the word role are lower case since it does not represent a definition.
 ----
@@ Line 181: / Line 195: @@
 === Response: ===
-TBD
+It was decided to add the word Internal to: Identify FOSS Compliance Role(s). And to update the first bullet to included the word "internal" as:
+Assign individual(s) responsible for managing internal FOSS compliance.
 ----
@@ Line 192: / Line 207: @@
 === Response: ===
-TBD
+It was discussed and decided to keep the two sections as two distinct sections and not merge them as one. It was generally believe that each section, although could be performed by one person or group, it is also common to have different roles/groups perform the two different requirements highlight in sections 3.1 and 3.2.
 ----
-==== 18) Suggest: 3.1 and 3.2 sub-section consolidation ====
+==== *18) G5 - Should cover code that the organization provides as open source ====
 Submitted By: Jilayne Lovejoy
@@ Line 203: / Line 218: @@
 === Response: ===
-TBD
+It was recognized that the section G5 was the section that will likely go through the most evolution in the next few up coming releases (versions) of the specification. Instead of trying to make significant changes to G5 in this final stage of the first release we decided to add this item to the issues consideration queue for the next version of the spec.
 ----
@@ Line 214: / Line 229: @@
 === Response: ===
-TBD
+The Supplied Software definition was discussed. It was decided to keep the definition as is (more general).
 ----
@@ Line 224: / Line 239: @@
 === Response: ===
-TBD
+The consideration noted here was discussed with the conclusion that it should be addressed by the OpenChain curriculum team and not in he spec. The spec focuses on the "what and why" where this issue was viewed as a "how and when" topic.
 ----
+==== *21) Suggest: Adding - identify the license conditions of the applicable licenses ====
+Submitted By: Till Jaeger
+[Feedback was receive after the first version of the spec was finalized]
+I'm very happy with the current draft but I have one major issue for consideration (in this or a later version): in my experience, it is a common problem that companies do not (properly) identify the license conditions of the applicable licenses.
+Thus, I recommend to add something in the specification like "(process for) identifying license conditions of applicable FOSS licenses".
+This could be a subsection of "Review and Approve FOSS Content" or an own main section ("Knowing License Conditions").
+----
+=== Response: ===
+Although the first version of the specification has been finalized (August 2016), your feedback is still timely in that we are embarking on the next revision round in September. I added your comments to the issues list for consideration.
+==== *22) Suggest:  Defining a Remediation Path ====
+Submitted By: Mark Gisi
+Currently no requirement to ensure an organization has a remediation and/or escalation path.
+----
+=== Response: ===
+Although the first version of the specification has been finalized (August 2016), your feedback is still timely in that we are embarking on the next revision round in September. I added your comments to the issues list for consideration.

Wiki

User Tools

Site Tools

Differences

Page Tools