Differences

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

--- openchain:spec-2016-h1-public-comments [2016/07/15 22:34]
mgisi [11) Suggest including: scripts used to control compilation and installation]
+++ 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 139: / Line 139: @@
 ----
-==== 13) Suggest: Reconsider the definition of Supplied Software ====
-Submitted By: Jilayne Lovejoy
-The definition of Supplied Software - is so broad that it would include software provided as open source software by the organization. I don’t think we really intended it to be that way, and references to “Supplied Software” in several of the goals and verification artifacts are really referring to the use of third party FOSS in the distribution of products, not FOSS projects created by the organization.  I’d think that FOSS that is created by the organization would be covered under G5, not so much as G2-4 - ??
-Should we narrow the definition of Supplied Software as such? (also consider impact on definition of Software Staff)
-=== Response: ===
-TBD
-----
-==== 14) Suggest: Mentioning a test to satisfy training ====
+==== 13) Suggest: Adding phrase "from third parties"  ====
 Submitted By: Jilayne Lovejoy
-.2 and 1.2.3 -  85% must of all Software Staff must have done training within last 24 mos; can have test to satisfy training - thinking about this realistically, should the OpenChain curriculum team create a template of what the test might be along with standard training materials?  The 85% within 24 mos could be a big challenge and really annoying for software staff who know this stuff, so the test could be key, but then we also may want to consider some way to not let the test option get too watered down??
+.1 - first bullet, “assign individual responsible for receiving FOSS compliance inquiries…" I think we should add "from third parties” - it says this in the rationale, but adding this would make it clear from the get-go that this section is dealing with a more public-facing role, versus internal role, which is dealt with later.
 === 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.
-==== 15) Suggest: Adding phrase "from third parties"  ====
+And to change the wording of bullet #1:
-Submitted By: Jilayne Lovejoy
-.1 - first bullet, “assign individual responsible for receiving FOSS compliance inquiries…" I think we should add "from third parties” - it says this in the rationale, but adding this would make it clear from the get-go that this section is dealing with a more public-facing role, versus internal role, which is dealt with later.
+from: Assign individual(s) responsible for receiving FOSS compliance inquiries;
-=== Response: ===
+to: Assign individual(s) responsible for receiving external FOSS inquiries;
-TBD
+The word: "compliance" was removed to make it more general.
 ----
-==== 16) Suggest: required to have an email address sounds a bit over-complicated  ====
+==== 14) Suggest: required to have an email address sounds a bit over-complicated  ====
 Submitted By: Jilayne Lovejoy
@@ Line 176: / 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").
 ----
-==== 17) Suggest:  FOSS Liaison rewording ====
+==== 15) Suggest:  FOSS Liaison rewording ====
 Submitted By: Jilayne Lovejoy
@@ Line 189: / 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.
 ----
-==== 18) Suggest: FOSS Compliance Role rewording ====
+==== 16) Suggest: FOSS Compliance Role rewording ====
 Submitted By: Jilayne Lovejoy
@@ Line 201: / 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.
 ----
-==== 19) Suggest: 3.1 and 3.2 sub-section consolidation =====
+==== 17) Suggest: 3.1 and 3.2 sub-section consolidation =====
 Submitted By: Jilayne Lovejoy
@@ Line 212: / 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.
 ----
-==== 20) 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 223: / 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.
 ----
+==== 19) Suggest: Reconsider the definition of Supplied Software ====
+Submitted By: Jilayne Lovejoy
+The definition of Supplied Software - is so broad that it would include software provided as open source software by the organization. I don’t think we really intended it to be that way, and references to “Supplied Software” in several of the goals and verification artifacts are really referring to the use of third party FOSS in the distribution of products, not FOSS projects created by the organization.  I’d think that FOSS that is created by the organization would be covered under G5, not so much as G2-4 - ??
+Should we narrow the definition of Supplied Software as such? (also consider impact on definition of Software Staff)
+=== Response: ===
+The Supplied Software definition was discussed. It was decided to keep the definition as is (more general).
+----
+==== 20) Suggest: Mentioning a test to satisfy training ====
+Submitted By: Jilayne Lovejoy
+.2 and 1.2.3 -  85% must of all Software Staff must have done training within last 24 mos; can have test to satisfy training - thinking about this realistically, should the OpenChain curriculum team create a template of what the test might be along with standard training materials?  The 85% within 24 mos could be a big challenge and really annoying for software staff who know this stuff, so the test could be key, but then we also may want to consider some way to not let the test option get too watered down??
+=== Response: ===
+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