Re: OpenChain 2.0 Self-Certification Questionnaire Update - Review before Thursday CoB Pacific


 

On Aug 5, 2020, at 7:56, Shane Coughlan <scoughlan@linuxfoundation.org> wrote:

This is a big email. It is about taking the lessons learned on the Conformance Questionnaire Webinar held on the 3rd of August 2020 to improve our self-certification questionnaire. Lessons applicable to the questionnaire have been applied as discussed below.

The practical side of this update has happened on GitHub. It refers to this branch:
https://github.com/OpenChain-Project/conformance-questionnaire/tree/improving-questions-for-clarity
And this Pull Request for the Main branch:
https://github.com/OpenChain-Project/conformance-questionnaire/pull/47

However, you do not need to visit GitHub to review what I have been doing. Below you will find:
(1) The Updated Questions (and you can comment)
(2) The Updated Questions Alongside Strikethrough of the Old Questions
(3) A List of the Specific Commits on GitHub used

The update focuses on the following:
(a) Changing to active voice instead of passive voice
(b) Removing words or constructs not necessary for understanding
(c) Adjusting language to align more closely with the Specification
(d) Correcting terminology not used in the Spec but used in the Questionnaire
(e) Correcting typographical issues

Here is the Specification 2.0 for reference:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.0.pdf

Below is the adjusted Self-Certification Questionnaire for review.
Unless we have a blocking issue I would like to go live by Thursday CoB Pacific to ensure we can release the Self-Certification Walk-Through Video as soon as possible. Therefore, while all comments are welcome, requests for changes should be isolated to errors, if any.

Goal 1:

Do you have a documented policy governing the Open Source license compliance of the Supplied Software?

Do you have a documented procedure to communicate the existence of the Open Source policy to all Software Staff

Have you identified the roles and responsibilities that affect the performance and effectiveness of the Program?

Have you identified and documented the competencies required for each role?

Have you documented the assessed competence for each Program participant?

Have you documented the awareness of your Program participants on the following topics?
The Open Source policy and where to find it;
Relevant Open Source objectives;
Contributions expected to ensure the effectiveness of the Program;
The implications of failing to follow the Program requirements.

Do you have a process for determining the scope of your Program?

Do you have a written statement clearly defining the scope and limits of the Program?

Do you have a documented procedure to review and document Open Source license obligations, restrictions and rights?

Goal 2: Relevant Tasks Defined and Supported

Have you assigned individual(s) responsibility for receiving external Open Source compliance inquiries?

Is the external Open Source compliance contact publicly identified (e.g. via an email address or the Linux Foundation Open Compliance Directory)?

Do you have a documented procedure for receiving and responding to Open Source compliance inquiries?

Have you documented the persons, group or function supporting the Program role(s) identified?

Have the identified Program roles been properly staffed and adequately funded?

Has legal expertise to address internal and external Open Source compliance been identified?

Do you have a documented procedure assigning internal responsibilities for Open Source compliance.

Do you have a documented procedure for handling review and remediation of non-compliant cases?

Goal 3: Open Source Content Review and Approval

Do you have a documented procedure for identifying, tracking and archiving information about the Open Source components in a Supplied Software release?

Do you have Open Source component records for Supplied Software which demonstrates the documented procedure was properly followed?

Do you have a documented procedure that covers these common Open Source license use cases for Open Source components in the Supplied Software?
Distribution in binary form;
Distribution in source form;
Containing modified Open Source;
Containing Open Source with attribution requirements;
Integration with other Open Source that may trigger copyleft obligations;
Containing Open Source or other software under incompatible licenses for interaction with other components in the Supplied Software.

Goal 4: Compliance Artifact Creation and Delivery

Do you have a documented procedure describing the process ensuring the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses?

Do you have a documented procedure for archiving copies of Compliance Artifacts for the Supplied Software?

Are the Compliance Artifacts archived at least as long as the Supplied Software is offered and as required by the Identified Licenses?

Goal 5: Understand Open Source Community Engagement

Do you have a policy for contribution to Open Source projects on behalf of the organization?

Do you have a documented procedure governing Open Source contributions?

Do you have a documented procedure for making all Software Staff aware of the Open Source contribution policy?

Goal 6: Adherence to the Specification Requirements

Do you have documentation confirming that your Program meets all the requirements of this specification?

Do you have documentation confirming that your Program conformance was reviewed within the last 18 months?

Here are the changes line by line

Goal 1:

Do you have a documented policy governing the Open Source license compliance of the Supplied Software?
Do you have a documented policy that governs open source license compliance of the Supplied Software distribution (e.g., via training, internal wiki, or other practical communication method)?

Do you have a documented procedure to communicate the existence of the Open Source policy to all Software Staff
Do you have a documented procedure that communicates the existence of the open source policy to all Software Staff?

Have you identified the roles and responsibilities that affect the performance and effectiveness of the Program?
Have you identified the roles and the corresponding responsibilities that affect the performance and effectiveness of the Program?

Have you identified and documented the competencies required for each role?
Have you identified and documented the competencies required for each role?

Have you documented the assessed competence for each Program participant?
Have you documented evidence of assessed competence for each Program participant?

Have you documented the awareness of your Program participants on the following topics?
The Open Source policy and where to find it;
Relevant Open Source objectives;
Contributions expected to ensure the effectiveness of the Program;
The implications of failing to follow the Program requirements.
Do you have evidence documenting the awareness of your personnel of the following topics?
The open source policy and where to find it,
The relevant open source objectives,
The contributions expected to ensure the effectiveness of the Program,
The implications of failing to follow the Program requirements,

Do you have a process for determining the scope of your Program?
Do you have a process for determining the scope of your Program?

Do you have a written statement clearly defining the scope and limits of the Program?
Do you have a written statement that clearly defines the scope and limits of the Program?

Do you have a documented procedure to review and document Open Source license obligations, restrictions and rights?
Do you have a process for reviewing open source license obligations, restrictions and rights?
Do you have a documented procedure to review and document the obligations, restrictions and rights?

Goal 2: Relevant Tasks Defined and Supported

Have you assigned individual(s) responsibility for receiving external Open Source compliance inquiries?
Have you assigned individual(s) responsible for receiving external open source compliance inquiries (\"Open Source Liaison\")?

Is the external Open Source compliance contact publicly identified (e.g. via an email address or the Linux Foundation Open Compliance Directory)?
Is the Open Source Liaison function publicly identified (e.g. via an email address and/or the Linux Foundation\u0027s Open Compliance Directory)?

Do you have a documented procedure for receiving and responding to Open Source compliance inquiries?
Do you have a documented procedure that assigns responsibility for receiving and responding to open source compliance inquiries?

Have you documented the persons, group or function supporting the Program role(s) identified?
Have you documented the persons, group or function supporting the Program role(s) identified?

Have the identified Program roles been properly staffed and adequately funded?
Have the identified Program roles been properly staffed and has adequate funding provided?

Has legal expertise to address internal and external Open Source compliance been identified?
Is legal expertise pertaining to internal and external open source compliance identified?

Do you have a documented procedure assigning internal responsibilities for Open Source compliance.
Do you have a documented procedure assigning internal responsibilities for Open Source compliance.

Do you have a documented procedure for handling review and remediation of non-compliant cases?
Do you have a documented procedure for handling review and remediation of non-compliant cases?

Goal 3: Open Source Content Review and Approval

Do you have a documented procedure for identifying, tracking and archiving information about the Open Source components in a Supplied Software release?
Do you have a documented procedure for identifying, tracking and archiving information about the collection of open source components from which a Supplied Software release is comprised?

Do you have Open Source component records for Supplied Software which demonstrates the documented procedure was properly followed?
Do you have open source component records for each Supplied Software release which demonstrates the documented procedure was properly followed?

Do you have a documented procedure that covers these common Open Source license use cases for Open Source components in the Supplied Software?
Distribution in binary form;
Distribution in source form;
Containing modified Open Source;
Containing Open Source with attribution requirements;
Integration with other Open Source that may trigger copyleft obligations;
Containing Open Source or other software under incompatible licenses for interaction with other components in the Supplied Software.
Have you implemented a procedure that handles at least the following common open source license use cases for the open source components of each supplied Supplied Software release?
distributed in binary form;
distributed in source form;
integrated with other open source such that it may trigger copyleft obligations;
contains modified open source;
contains open source or other software under an incompatible license interacting with other components within the Supplied Software;
contains open source with attribution requirements.

Goal 4: Compliance Artifact Creation and Delivery

Do you have a documented procedure describing the process ensuring the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses?
Do you have a documented procedure that describes a process that ensures the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses?

Do you have a documented procedure for archiving copies of Compliance Artifacts for the Supplied Software?
Do you archive copies of the Compliance Artifacts of the Supplied Software?

Are the Compliance Artifacts archived at least as long as the Supplied Software is offered and as required by the Identified Licenses?
Are the copies of the Compliance Artifacts archived for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer)?

Goal 5: Understand Open Source Community Engagement

Do you have a policy for contribution to Open Source projects on behalf of the organization?
Do you have a policy that governs contributions to open source projects on behalf of the organization?

Do you have a documented procedure governing Open Source contributions?
Do you have a documented procedure that governs Open Source contributions?

Do you have a documented procedure for making all Software Staff aware of the Open Source contribution policy?
Do you have a documented procedure that makes all Software Staff aware of the existence of the Open Source contribution policy?

Goal 6: Adherence to the Specification Requirements

Do you have documentation confirming that your Program meets all the requirements of this specification?
Do you have documentation confirming that your Program meets all the requirements of this specification?

Do you have documentation confirming that your Program conformance was reviewed within the last 18 months?
Do you have documentation confirming that your Program conformance was reviewed within the last 18 months?

Here are the changes as per GitHub

Updated Question 1(a) for clarity …
d114034

Updated Question 1(b) for clarity
17c5bca

Updated Question 1(c) for clarity
ec468ff

Updated Question 1(d) for clarity
4fa152d

Corrected 1(d), reverted because of double-check with spec
7a3f70e

Improved 1(e) for clarity
3f6b2ae

Improved 1(f) for clarity
8b51cf0

Updated 1(f)ii for clarity
0878235

Updated 1(f)iii for clarity
71b01ec

Updated 1(h) for clarity
dff6cb9

Updated 1(i) to clarify conflation between "process" and "procedure" … …
76033ba

Improved 2(a) for clarity
0200570

Fixed "open source" to Open Source throughout as this is a defined te… …
e501444

Improved Question 2(b) for clarity
6b12c98

Improved 2(c) for clarity and to bring it closer to the precise words… …
91e6ad6

Improved 2(e) for clarity
061c387

Improved 2(f) for clarity and to bring the wording closer to the spec
71cf4f6

Further improvement to 2(f) for clarity
b1eaa18

Improved 3(a) for clarity
800b25c

Improved 3(b) for clarity
e3aa6c9

Improved 3(c) for clarity
abde070

Updated 3.c.i to active voice for clarity
b795769

Updated 3.c.ii to active voice for clarity
64b1bdd

Updated Updated 3.c.iii to active voice for clarity, also reduced unn… …
ca882cb

Fixed 3(c) because it used the term "at least" these use cases but th… …
1ae5a99

Updated 3.c.iv to active voice
f253c0b

Updated 3.c.v to active voice and for clarity
fa4b8ac

Updated 3.c.vi to active voice
62ceb8f

Re-ordered questions under 3(c).X to make a better read path …
d2256e7

Changed 4.a to active voice
6fc0fb6

Improved 4.b to bring it closer to the actual wording of the Spec
0683ad0

Improved 4.d for clarity (using AND instead of OR as the effect of AN… …
5f3fcbe

Tweaked for clarity
5fead24

Improved 5.a to bring it closer to the wording of the spec
0d60b84

Updated 5.b to active voice
3587ad4

Updated legacy error with numbering (4.d to 4.c as no 4.c existed prior)
3936cf9

Updated 5.c to active voice and for clarity
750cde1

Updated bullet list formatting to match the rest of the document
0715c0a

Corrected typo (. instead of ?) in 2.g
0f875a7

Join uk-wg@lists.openchainproject.org to automatically receive all group messages.