Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Public Comments for Specification Version 1.0 ======

The final release candidate of the OpenChain 1.0 specification can be found here: 

{{:openchain:openchainspec-1.0.pdf| OpenChain Compliance Specification version 1.0}}

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. 




==== 1) OpenChain regarding vendor neutrality ==== 
Submitted By: Jeremiah Foster

"I would like to hear something from OpenChain regarding vendor neutrality in the proposals section. I think it is implied somewhat, but I don't think it would hurt to make this explicit. By vendor neutrality I mean that no particular company, or particular company process, or even a particular community process, is considered the orthodoxy. This allows for greater balance of the "permissive" and "copyleft" dichotomy which I think is also mirrored in the "open source" and "free software" community. That dichotomy is confusing to many companies and ought to be ameliorated as much as it can be and I think neutrality and focus on pragmatic aspects of compliance will best serve those companies involved in open source and hopefully improve the number that are in compliance with all FOSS licenses."

=== Response: ===
It was generally believe that the spec addresses the concern as follows:  One of the core principles that guided the drafting of the first version of the spec was that the requirements should focus solely on  *what* and *why* aspects of a FOSS compliance program and not the *how* and *when*. To quote the spec draft (which is attached):
“The requirements represent a base level (minimum) set of requirements a program must satisfy to be considered OpenChain compliant. The specification focuses on the “what” and “why” qualities of a compliance program as opposed to the “how” and “when” considerations. This ensures a practical level of flexibility that enables different organizations to tailor their policies and processes to best fit their objectives.”

It is important to note that the spec is NOT a best practice guide. It represents a core set of requirements that a quality  FOSS compliance program should satisfy. The “What and Why” principle supports the ability to allow multiple different “how and when” FOSS program implementations to successfully coexist. This approach accommodates the neutrality consideration you raised. Also worth noting - the group that drafted the first version of the spec functioned like an open source project by openly obtaining input from  dozens of companies and organizations. There was no specific criteria to participate. It is for these reasons I believe the first draft of the spec was able to successful preserve organization neutrality. 

----

==== 2) Important to consider leveraging community resources  ==== 
Submitted By: Jeremiah Foster

"I think there have been some important changes in compliance since OpenChain was founded that would be nice for OpenChain to address proactively, namely the community compliance process. This process, largely made public last year, is exemplified by sites like this one: http://copyleft.org/guide/comprehensive-gpl-guidepa2.html but not limited to this. Both the SFC and FSF have resources on community compliance that perhaps might be reused in some way perhaps."

=== Response: ===

It was generally believe that the spec addresses the concern as follows: The development of the spec is open to all.  A lot of feedback from many perspectives was considered. There was no shortage of recommendations and considerations including points similar to the ones covered in the above GPL compliance guide. Note that the spec and the guide, although related and complimentary, serve different objectives. Another spec guiding principle was for the requirements was not to provide legal interpretation. Such interpretations are delegated to the respective organizations (part of the how and when). The GPL guide represents a good example of a “How and When” set of procedures with a special focus on compliance of a specific set of FOSS licenses, which is complimentary  with the OpenChain spec. Since the spec’s evolution will continue to function similar to an open source project, which resources are considered will dependent upon i) who decides to participate  (scratch an itch) and ii) what resources they bring to the discussion. The approach taken supports the situation where if the spec is found to be lacking in some way, and that existing relevant public resources exist, that they would be offered up to guide its remediation. 

----
==== *3) Suggested removing historical view from Introduction ====
Submitted By: Martin Yagi

"Introduction: Interesting though it is, I don’t think I’d include all the historical view if it isn’t particularly relevant…especially where it may be upsetting for people to know that they weren’t being trusted by their customers. ;)"


=== Response:  ===

Although the feedback was recognized as important, it was not categorized as a top priority fix for the current late stage version of the 2016 H1 draft. It was added to the consideration queue for the next version of the spec. 

----
==== 4) Suggested goal for IP training at 85% may be unrealistic ====
Submitted By: Martin Yagi

"1.2 1.2.3: A goal of >85% is a great target, but I wonder if it’s realistic, particularly for any (large) organisation. It may also be helpful to have a ramp-up. E.g. at least 60% in yr1, etc."

=== Response: ===

There was debate over what was the right percentage level. The concern raised here was that too high might be too difficult to meet in the beginning (especially by larger organizations). Too little and the spec is weaken because it does not ensure a sufficient number of staff have been properly trained to ensure the FOSS compliance program was properly executed. It was recognized that the requirement does not need to apply to an entire organization, but instead to just those required to participate on the development for a given software release. A large organization might have several different units using different FOSS programs. Not all FOSS programs will necessarily achieve OpenChain conformance within a given organization. Clarification will be include in the spec FAQs docs.

----
==== 5) Suggest changing “FOSS program” to “FOSS management program” ====
Submitted By: Martin Yagi

"G3, 3.2: Suggest to change “FOSS program” to “FOSS management program” as it is called in G6."

=== Response: ===

It was agreed that the spec needs use the identified phrase consistent through the spec. The spec will be modified to standardize on "FOSS program" to keep it sufficiently general.

----
==== 6) Suggest adding something about including “build instructions”” ====
Submitted By: Martin Yagi

"G4, 4.1: I’d add something about including “build instructions”, as potentially unbuildable or only buildable using proprietary toolchain source isn’t appreciated."   

=== Response: ===

We will add "required build instructions and scripts" to the 4.1 list.

----
==== *7) Request to Add text stating value of compliance in generally has value ====
Submitted By: Karen Sandler 

"Complying with the terms of the free and open source licenses used in industry is not only important for minimizing risk to individual companies, but is also a necessary step towards the preservation, collaboration and improvement of the software infrastructure we all rely on."

=== Response: ===

Although the feedback was recognized as important, it was not categorized as a top priority fix for the current late stage version of the 2016 H1 draft. It was added to the consideration queue for the next version of the spec.

----
==== 8) Suggest pointing out: Text: does not guarantee full compliance ====
Submitted By: Karen Sandler 

"Text should also be added to clarify that completely following the spec does not guarantee full compliance and that the (obvious) intention is that companies need to tailor the guidelines to their own procedures. I think this would fit well in the second to last paragraph on page 3 and perhaps should also be added to G6.1."

=== Response: ===

It was agreed that the the spec should note that OpenChain conformance does not guarantee full license compliance.

----

==== 9) "OpenChain Compliant" could potentially be is confusing ====
Submitted By: Karen Sandler
 
"In the definitions,  I think the term "OpenChain Compliant" is confusing, and can be fixed by using a term other than "compliant". We don't want people to think that following these recommendations is any attestation as to actual compliance (though of course I agree that they will help if followed fully). Calling it "OpenChain Conforming" or "OpenChain Accordant" would work, for example."

=== Response: ===

It was agreed that the use of "OpenChain Compliance" could easily be confused with "license compliance". The decision was made to change the spec terminology from "OpenChain Compliance" to "OpenChain Conformance".

----
==== 10) Suggest using "complete and corresponding source code" ====
Submitted By: Karen Sandler

"G4.1 should refer to "complete and corresponding source code" instead of just "source code"."

=== Response: ===

The complete and corresponding source code has a specific definition in the GPL-3.0 license text (section 1 paragraph 3) but not in any other license. One spec guiding principle is to be license neutral. An important more general idea being expressed here is to ensure all the source code as required by the different respective licenses is included. We will update  phrase "source code" in the 4.1 list to “required source code”. This should tighten the reference to the source code as required by the different licenses. 

----


==== *11) Suggest including: "scripts used to control compilation and installation"  ====
Submitted By: Karen Sandler

"Also in G4.1, a bullet point should be added saying "scripts used to control compilation and installation", as per GPLv2 Section 3 and GPLv3 Section 1 (we may also want to include some reference to this in G3.2, along with a reference to complete and corresponding source code as well). Even though scripts are included in CCS under GPL I think it makes sense to give this its own bullet point to highlight the requirement which is sometimes overlooked. GPLv2 and GPLv3 ensure not only that users receive software freedom in the abstract, but have the technically necessary information to make practical use of those freedoms. Ability to rebuild the binaries from source code, and knowing that everything necessary to produce the binary are present is what matters most in copyleft compliance (this is why, for example, copyleft and security go hand in hand)."

=== Response: ===
The issue raise here was addressed by the modification made for public comments (8) above. The wording added in (8) states: "required build instructions and scripts" which should be general enough to  accommodate all licenses including the GPL. 

This topic resulted in a discuss such that it was decided that we will revisit it to discuss it further for the next version of the spec.

----

==== 12) Suggest: Code of Conduct for a company's participation in any community ====
Submitted By: Karen Sandler

"In G5.2, it may be appropriate to recommend considering a Code of Conduct for a company's participation in any community (right now the language is weak anyway and says "might include"). This is becoming increasingly common in companies, as I understand it, as a way to limit liability for inappropriate communications by employees in the public and is something they should actively consider."

=== Response: ===
It was generally agreed upon that section 5.2 should also include a reference to a Code of Conduct policy some major open source projects publish. We will update the “community engagement and interaction” phrase in the 5.2 section list to be: “community engagement and interaction, including a projects's Code of Conduct or equivalent"

----


==== 13) Suggest: Adding phrase "from third parties"  ====
Submitted By: Jilayne Lovejoy

2.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: ===
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. 

----

==== 14) Suggest: required to have an email address sounds a bit over-complicated  ====
Submitted By: Jilayne Lovejoy

- FOSS liaison “must have an email-capable communications system” - um, so does this simply mean, I have an email address you can contact me at?  This wording is a bit odd and sounds a bit over-complicated

=== Response: ===
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").

----

==== 15) Suggest:  FOSS Liaison rewording ====
Submitted By: Jilayne Lovejoy

2.1.1 FOSS Liaison function is publicly identified (including an email address). 
- remove the word “function” 
- is listing this person on the organization’s website enough?  Above we reference the LF Open Compliance Directory, which is great, but seems like a narrow example, no? Maybe add a couple other example as to how this might be achieved in the bullets in 2.1?


=== Response: ===
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. 

----

==== 16) Suggest: FOSS Compliance Role rewording ====
Submitted By: Jilayne Lovejoy

2.2 FOSS Compliance Role - I think the intent here is this part is dealing more with the internal role - we might want to explicitly state that to better contrast to 2.1 
2.2.4 “documented procedure exists that identifies an escalation path for issue resolution” - this starts to sound like the above section and FOSS Liaison role. I’m not entirely sure what escalation this is talking about - internally?  I think we need some clarifying language here.


=== Response: ===
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. 

----

==== 17) Suggest: 3.1 and 3.2 sub-section consolidation =====
Submitted By: Jilayne Lovejoy

3.1 and 3.2 - it kind of seems like these could be collapsed, such that 3.2.1 becomes 3.1.2 and the description of 3.1 simply includes use case. I’m not sure what is achieved by making these separate, as they are part and parcel of the same function in my eyes. 


=== Response: ===
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) G5 - Should cover code that the organization provides as open source ====
Submitted By: Jilayne Lovejoy

G5 - I think this should cover code that the organization provides as open source (i.e., it’s own FOSS projects). Given the vast number of FOSS projects that have crappy license information - in terms of easily and clearly identifying both the inbound and outbound license - this would be a great help to everyone downstream as well. We could consider if this might eventually simply reference compliance with the requirements that the CII initiative is coming up with. 


=== Response: ===
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

1.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

Page Tools
