Date   

OpenChain Specification Work Team Call - Fourth Monday August 2020 - Full Recording

 

The recording of the OpenChain Specification Team Fourth Monday August call is now available:
https://youtu.be/DPYMisFWW_s
This call covered discussion on how to set expectations around evolution of the standard and to ensure maximum support as we graduate from the ISO/IEC process in September.


OpenChain Specification Work Team - Fourth Monday Call - Today at 5pm Pacific

 

A reminder that if you want to chat about the OpenChain Specification, our regular call is coming up…

OpenChain Specification Work Team - Fourth Monday Call - Today at 5pm Pacific
Join Zoom Meeting ( https://us02web.zoom.us/j/9990120120?pwd=NzVCaFE2L1RRRFZaSkk0dm8xdlplUT09 )

Meeting ID: 999 012 0120
Password: 123456


OpenChain Specification Work Team - Second Monday August 2020 - Full Recording

 

The recording of our regular bi-weekly Specification Work Team is now available. This is where people can provide input on the current version of the standard, suggest new reference material, and also provide suggestions for our future.
https://youtu.be/9LuZSmWY7Xo
You can join the Specification Mailing List to follow all the activity
https://lists.openchainproject.org/g/specification


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

 

On Aug 5, 2020, at 7:56, Shane Coughlan <@shanecoughlan> 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


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

 

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:
And this Pull Request for the Main branch:

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: 

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


Reminder: OpenChain Specification Work Team - Second Monday Meeting - 9am Pacific

 

Mark will host our regular bi-weekly Specification Work Team meeting at 9am Pacific today. This is where you can provide feedback and suggestions for clarification material and future iterations of the specification. You can check out recorded issues on GitHub here:
https://github.com/OpenChain-Project/Specification/issues

Join Zoom Meeting ( https://us02web.zoom.us/j/9990120120?pwd=NzVCaFE2L1RRRFZaSkk0dm8xdlplUT09 )

Meeting ID: 999 012 0120
Password: 123456


OpenChain Specification Bi-Weekly Call #2 – Fourth Monday June 2020 – Full Recording

 

The full recording of the 2nd OpenChain Specification bi-weekly call is now available. This call went over the general parameters of the editing process for the next generation of the OpenChain specification. Our goal is to ensure all comments and suggestions can be captured.
https://www.openchainproject.org/news/2020/06/29/openchain-specification-bi-weekly-call-2-fourth-monday-june-2020-full-recording


REMINDER: Specification 3.0 Draft/Review Meeting - June 22nd @ 5pm PST

 

Dear all

Mark Gisi (Spec Chair) will lead a meeting today (5pm PST) to discuss the next version of the OpenChain specification (3.0).

Join Zoom Meeting ( https://us02web.zoom.us/j/9990120120?pwd=NzVCaFE2L1RRRFZaSkk0dm8xdlplUT09 )

Not working for you?

Join Our Zoom Meeting
https://zoom.us/j/9990120120
Password
• 123456 *
One Tap Telephone (no screensharing)
• +358 9 4245 1488,,9990120120# Finland
• +33 7 5678 4048,,9990120120# France
• +49 69 7104 9922,,9990120120# Germany
• +852 5808 6088,,9990120120# Hong Kong
• +39 069 480 6488,,9990120120# Italy
• +353 6 163 9031,,9990120120# Ireland
• +81 524 564 439,,9990120120# Japan
• +82 2 6105 4111,,9990120120# Korea
• +34 917 873 431,,9990120120# Spain
• +46 850 539 728,,9990120120# Sweden
• +41 43 210 71 08,,9990120120# Switzerland
• +44 330 088 5830,,9990120120# UK
• +16699006833,,9990120120# US (San Jose)
• +12532158782,,9990120120# US
Find your local number: https://zoom.us/u/abeUqy3kYQ
Not all countries have available numbers.
After dialing the local number enter 9990120120#

Regards

Shane

--
Shane Coughlan
General Manager, OpenChain
e: @shanecoughlan
p: +81 (0) 80 4035 8083
w: www.linuxfoundation.org

Schedule a call:
https://calendly.com/shanecoughlan


Re: Specification 3.0 Draft/Review Meeting - June 8th @ 9am PST

 

Dear all

Apologies for the crossed wire. We may have lost a few attendees because Groups.io and my mail to the list referenced the OpenChain Zoom room, while Mark used the Windriver room. We will make sure to be super clear about the fourth Monday call.

Regards

Shane

On Jun 9, 2020, at 0:14, Mark Gisi <Mark.Gisi@...> wrote:

As Shane announced last week - we will be meeting today (9am PST) to discuss the next version of the OpenChain specification (3.0)

Note – there is a password (123456)

Join Zoom Meeting
https://windriver.zoom.us/j/91649628975?pwd=NEdGWDRUbTVoV0pMc3h0UkgzYThnQT09

Meeting ID: 916 4962 8975
Password: 123456
One tap mobile
+16468769923,,91649628975# US (New York)
+16699006833,,91649628975# US (San Jose)

Dial by your location
+1 646 876 9923 US (New York)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 346 248 7799 US (Houston)
+1 408 638 0968 US (San Jose)
Meeting ID: 916 4962 8975
Find your local number: https://windriver.zoom.us/u/abMlUXEjfP

Join by SIP
91649628975@...

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (EMEA)
103.122.166.55 (Australia)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
207.226.132.110 (Japan)
Meeting ID: 916 4962 8975
Password: 123456


Mark Gisi | Wind River | Director, IP & Open Source
Tel (510) 749-2016


Specification 3.0 Draft/Review Meeting - June 8th @ 9am PST

Mark Gisi
 

As Shane announced last week - we will be meeting today (9am PST) to discuss the next version of the OpenChain specification (3.0)

 

Note – there is a password (123456)

 

Join Zoom Meeting

https://windriver.zoom.us/j/91649628975?pwd=NEdGWDRUbTVoV0pMc3h0UkgzYThnQT09

 

Meeting ID: 916 4962 8975

Password: 123456

One tap mobile

+16468769923,,91649628975# US (New York)

+16699006833,,91649628975# US (San Jose)

 

Dial by your location

        +1 646 876 9923 US (New York)

        +1 669 900 6833 US (San Jose)

        +1 253 215 8782 US (Tacoma)

        +1 301 715 8592 US (Germantown)

        +1 312 626 6799 US (Chicago)

        +1 346 248 7799 US (Houston)

        +1 408 638 0968 US (San Jose)

Meeting ID: 916 4962 8975

Find your local number: https://windriver.zoom.us/u/abMlUXEjfP

 

Join by SIP

91649628975@...

 

Join by H.323

162.255.37.11 (US West)

162.255.36.11 (US East)

221.122.88.195 (China)

115.114.131.7 (India Mumbai)

115.114.115.7 (India Hyderabad)

213.19.144.110 (EMEA)

103.122.166.55 (Australia)

64.211.144.160 (Brazil)

69.174.57.160 (Canada)

207.226.132.110 (Japan)

Meeting ID: 916 4962 8975

Password: 123456

 

 

Mark Gisi | Wind River | Director, IP & Open Source

Tel (510) 749-2016

 


OpenChain Spec - Next Gen After ISO - initial discussion 10am Pacific, May 4th

 

Dear all

Immediately after our 3rd webinar covering contribution policies, M&A and due diligence between 9am and 10am Pacific May 4th, Mark Gisi will lead a 20 minute first drafting discussion of the next gen OpenChain, OpenChain 3. 

Why?

OpenChain 2 has been deployed for one year. It will be released in ISO form in the coming months. We expect the 2nd gen standard to run for several years as a clear lighthouse to guide all compliance work.

Meanwhile, starting the draft process for OpenChain 3 this month will allow us to get feedback and experience from existing, new and near future adopters. We will use this to carefully consider what adjustments, clarifications and extensions will work for all our stakeholders. It’s a great conversation to join if you want to help frame the future.


Regards

Shane 


OpenChain in Q2 - Continuing Leadership, Continuing Support

 

The global lockdown due to the spread of COVID-19 is a unique historical moment. We are seeing both great success and great challenges in addressing this disease, and at all times there is an awareness that it can impact our close friends and families. To a large extent the OpenChain community is fortunate. Many of our companies allow us to work from home. Many of us are near excellent health services. We are well-positioned to weather this storm.

That said, COVID-19 has disrupted all of our supply chains and it has created a situation where face-to-face meetings have been completely supplemented by remote services. Different companies are at different stages in using such systems and we inevitably face a combination of adjusted priorities and delays in this situation. Open source license compliance is just one component among thousands as we collectively try to maintain services and to bring products to market in a changed world.

During Q1 our community has continued to function effectively. We launched our German Work Group. Our Asian work groups (China, Japan, Korea, Taiwan and India) either proceeded entirely remotely or deferred certain activities while continuing core work remotely. Our global automotive and reference tooling work groups continue to bring people together and - in the case of tooling - edge ever closer to describing fully-formed methods for companies to deploy open source tooling for open source compliance automation. Most importantly, our work in bringing OpenChain through the ISO process has continued, and we remain on track for deployment as an official ISO standard in 1H 2020.

Looking forward I would highlight three activities that can help drive us forward and address immediate market requirements.

(1) We keep pushing our ISO work. This will be a critical development for assisting sales and procurement departments in their understanding, adoption and deployment of our industry standard.

(2) We work to bridge the physical divide that our community faces due to the pandemic. To make this happen I am going to pivot our bi-weekly calls. With less emphasis on editing our standard (the forthcoming ISO version is fully baked) and our reference material largely produced via local work teams, there is an opportunity to launch an on-going series of webinars to provide access to people and knowledge that we would otherwise obtain at events. The timing schedule remains the same (first Monday, third Monday). Full announcement later today.

(3) We seek to address the growing market demand for clarity on automation via our Reference Tooling Work Group. Today I am putting out a request to our tooling work group to accelerate activity around one or more turn-key reference implementations of open source tooling for open source compliance. I believe this will provide both the opportunity to guide more companies onto automation in compliance and - just as importantly - it will provide a clear understanding of gaps in existing tools. The latter point will allow us to provide “shopping lists” to activities like ACT, which is a funding umbrella for a growing number of open source tooling projects.

You fit into every part of this.

Join our webinars as part of the audience or as presenters. Ask questions and provide answers. Bridge the knowledge gaps that we all benefit from closing.

Participate in our local work groups (virtually for now), helping to create reference material in multiple languages that takes companies forward in their desire to deploy the key requirements of quality open source compliance programs.

Take part in our global work groups (reference tooling, automotive, education) and help to tie together whole-sector understanding and responses.

You can get started right away.
https://www.openchainproject.org/about/contact

Over the last 34 months we have redefined how open source compliance is approached. We have built an industry standard that is seeing accelerating adoption. We have produced over 400 documents of reference material to support this standard. Our educational material has become a new baseline for how companies approach the training of their staff. Above all, as a virtual-first community, we are positioned to provide a pillar that visibly, effectively guides the global expanse of companies adopting, developing and deploying open source in products and services.

OpenChain is an ambitious project that has experienced exceptional success in defining what constitutes a quality open source compliance program. We are equally successful in fostering exceptional local and global communities that redefine how organizations collaborate on shared solutions. In our space, and in the wider open source community, there has never been a better time to help reduce friction and help people work together.

Let’s take this forward.


OpenChain Wiki Migration - Update on Work Group pages

 

Dear All (below action required from Mark, Miriam and SZ)

We have begun to migrate away from our old wiki and fully onto the Github infrastructure. Our Japan Work Group has created a tutorial on how global and local work groups can easily and quickly create really simple, really cool pages:
https://github.com/OpenChain-Project/Onboarding-JWG/blob/master/Tutorial/GitHubPages/how-to-migrate.md

You can see the first full production page from our Korea Work Group:
https://openchain-project.github.io/OpenChain-KWG/

(Yay for international collaboration!)

You can also see the Japan Work Group trial page and source code:
https://openchain-project.github.io/Onboarding-JWG/
(https://openchain-project.github.io/[repository-name]/)
Source Code:
https://github.com/OpenChain-Project/Onboarding-JWG/tree/master/docs

Let’s start moving the rest of the material over from here:
https://wiki.linuxfoundation.org/openchain/start

Can I have conformation that the following Work Groups are ok to migrate?

Specification:
https://wiki.linuxfoundation.org/openchain/openchain-specification-wiki-page

Conformance:
https://wiki.linuxfoundation.org/openchain/openchain-conformance-wiki-page

Taiwan:
https://wiki.linuxfoundation.org/openchain/openchain-taiwan-working-group

Regards

Shane


New Spec editing issue submitted during First Monday call

 

Hi all

Hans from Bosch brought up a topic on one rationale in the spec and - subsequent to the call - opened an issue on GitHub:
https://github.com/OpenChain-Project/Specification/issues/50

Pasted below for easy reference:

= Text under review =

§3.4.1 Compliance Artifacts -- Rationale:
“To ensure reasonable commercial efforts have been instituted in the preparation of the compliance artifacts that accompany the supplied software, as required by the identified licenses”

= Proposition =

There should be no reference to a “reasonable efforts” standard in respect of fulfillment of an OSS license, because the law applies “strict liability”.

= Reasoning =

Generally and probably world wide, copyright law forbids copying, modifying and distributing of copyrighted works, if and insofar there is no grant of such a right by the author/copyright holder. And in respect of Open Source Software, this right is granted under conditions – the OSS License. If the OSS License is not fulfilled, there is no such permission, thus an infringement of copyright. Whether or not an OSS license is fulfilled depends on a strict standard of care (because it is a grant “in rem”, not a mere contract between parties). So the answer can only be “yes, OSS license fulfilled” or “no, OSS license not fulfilled”. There is no grey zone like “yes, if reasonable efforts were made to fulfill the OSS license”. We should avoid any language, even in a rationale, which could give the impression of accepting a standard of care which is not in line with the law.

= Suggestion for a new rationale =

“To ensure the compliance artifacts that accompany the supplied software have been provided and prepared, as required by the identified licenses”


The Great Wiki Migration

 

Are you using part of the main OpenChain wiki here?
http://wiki.linuxfoundation.org/openchain/

Time to prepare for an infrastructure change. We are taking all our toys to Github to make collaboration easier and more effective, not to mention reducing the amount of time spent in various config and permissions.

Tutorial:
https://github.com/OpenChain-Project/Onboarding-JWG/blob/master/Tutorial/GitHubPages/how-to-migrate.md

Our trial page:
https://openchain-project.github.io/Onboarding-JWG/
(https://openchain-project.github.io/[repository-name]/)
Source Code:
https://github.com/OpenChain-Project/Onboarding-JWG/tree/master/docs

Korea WG page:
https://openchain-project.github.io/OpenChain-KWG/

Our timescale is not locked down yet. Please let us know what you think is reasonable in this thread.

Kudos to Kobota San for working this out and Fukuchi San for helping to communicate it widely.


OpenChain Germany Work Group Meeting # 1 @ Siemens Nuremberg on February 6th

 


Dear all, it is time to close registration for our first OpenChain Germany Work Group. Here is an overview of what you can expect on February 6th in Nuremberg:

Our Agenda

• Welcome & Introduction
• OpenChain as an ISO standard
• Developments in our regional groups
• Developments in our global automotive work group
• Discussion of focus topics of the German work group
• Wrap up & Next steps

Attendees

We expect 34 attendees from the following companies:
• Alekto Metis 
• Atsumi Sakai Janssen
• Bitsea GmbH
• BMW
• Bosch
• Canon Production Printing Germany GmbH
• CMS
• Daimler TSS
• DB Systel
• EACG GmbH
• Elektrobit Automotive
• Fiducia & GAD IT AG
• Hella AG
• HERE
• Linux Foundation
• Mbition / Daimler
• Novartis Pharma AG
• Osborne Clarke
• PwC Germany
• Rafal Malujda Law Office 
• SALT Solutions AG
• SAP
• Siemens
• Siemens Healthineers
• SUSE Software Solutions Germany GmbH
• Two Birds

Where

• Siemens, Humboldtstr. 59, Nuremberg, 90459, Germany

When

• Between 1pm and 4pm

Get Help

• Mail scoughlan@... or call +818040358083


The OpenChain Policy Template - Final Release Candidate for 2.0

 

As we head into the weekend it is the perfect time to take a moment and review one of the most important documents in our reference library. There are two primary requests in the OpenChain Project regarding reference material. One is for reference training, something we have addressed through our comprehensive curriculum slides since the project formation. The second is for templates to create open source policies for organizations of different sizes and in different markets. Thanks to the tremendous work of Andrew Katz, his team at Moorcrofts, and the team at Orcro, the OpenChain Project has been able to offer a flexible template to address this need for over a year. Our first release focused on version 1.2 of the OpenChain standard. Our second release, formally coming to market very soon (but already in draft form for many months), is designed to explicitly support version 2.0 of the OpenChain standard. This is a critical release, as OpenChain 2.0 is going into the ISO process, and we expect it to spread globally in this form for many years. Please take a moment, take a look at our final release candidate for this document, and let us know what you think.

Excel File:
https://github.com/OpenChain-Project/curriculum/raw/master/policy-template/2.0/The%20OpenChain%20Open%20Source%20Policy%20Template%20-%202.0%20-%20Final%20Release%20Candidate.xlsx

Open Document File:
https://github.com/OpenChain-Project/curriculum/raw/master/policy-template/2.0/The%20OpenChain%20Open%20Source%20Policy%20Template%20-%202.0%20-%20Final%20Release%20Candidate.ods

Submit an issue:
https://github.com/OpenChain-Project/curriculum/tree/master/policy-template/2.0


Reminder: OpenChain Specification - ISO Draft Review Process Ends 10th December

 

This is your chance to help finalize our ISO submission.

For those new to the specification – The OpenChain project has developed a specification that defines a core set of requirements that a trusted open source compliance program is expected to satisfy. To obtain a better understanding of the goals and the context in which the specification was developed before providing feedback, you can review the following FAQ list.

The big change over the current 2.0 version was reformatting the document layout into one acceptable for ISO submission and adoption. Other than very minor clarification edits, the content has largely remained unchanged. If a company is conformant with version 2.0 – they would remain conformant with 2.1.

The current draft is available at:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.1.draft.pdf

Past readers of the spec might find the marked up version useful:
https://wiki.linuxfoundation.org/_media/openchain/OpenChainSpec-2.1.draft.MarkUp.pdf

Your Feedback is Welcome Via
• the Mailing list: Openchain-specification@...;
• the issues wiki: https://github.com/OpenChain-Project/Specification/issues;
• attending the bi-monthly OpenChain calls: https://www.openchainproject.org/get-started/participate;
• replying to Mark Gisi directly if you wish to remain anonymous (mark.gisi@...)


Re: public comments: release candidate version 3 (rc3)

Alexios Zavras <alexios.zavras@...>
 

Additionally (since I was the one who raised the issue), "copyleft" was only mentioned once in an example list of what to look for, something like "code that might have copyleft obligations".
Since there was nothing special about copyleft (you always have to take care of the obligations of any license), changing it with a generic "license obligations" did not change the meaning of the example.

-- zvr

-----Original Message-----
From: specification@... <specification@...> On Behalf Of Mark Gisi
Sent: Monday, 18 November, 2019 06:35
To: specification@...
Subject: Re: [specification] public comments: release candidate version 3 (rc3)

Hi Till,

I understand your concern. Although you and I may understand the importance of the copyleft principle, our understanding may not necessarily be universal. Let me explain.

The spec serves many different audiences (e.g., small vs huge companies; automotive vs medical device vs SaaS; North American vs Europe vs Asia, ...). We have committed to a number of guiding principles to ensure the spec remains simple, agnostic to specific practices and relevant to a diverse group. The guiding principles can be found here:
https://wiki.linuxfoundation.org/openchain/specification-questions-and-answers#what_is_the_objective_of_the_openchain_specification

Two principles that are particularly relevant here are: i) the spec avoids legal advice and ii) less is more. For instance we avoid license interpretation:
https://wiki.linuxfoundation.org/doku.php?id=openchain/specification-questions-and-answers#does_the_specification_describe_how_to_comply_with_the_most_popular_open_source_licenses

Some could argue that "copyleft" is a legal term that requires legal interpretation. And often it is an unknown term to those new to open source compliance. The spec intentionally avoids mentioning of any specific license or license concept (e.g., permissive license, derivative works, public domain, ...) and focuses on the more basic obligation concepts (attributions, source code, build and install scripts, copy of licenses, ...).

Furthermore, the inclusion of the copyleft term, which is used just once in the spec, would require a definition. Its absence does not detract from the spec's objective - hence less is more.

"additional licensing obligations" was chosen because it is broader and hence more encompassing. It would include copyleft terms and additional permissive license terms (e.g., GPL-3 section 7).

- Mark


-----Original Message-----
From: specification@... [mailto:specification@...] On Behalf Of Till Jaeger via Lists.Openchainproject.Org
Sent: Sunday, November 17, 2019 10:16 AM
To: specification@...
Subject: Re: [specification] public comments: release candidate version 3 (rc3)

Dear Mark,

Why not defining "Copyleft"? Copyleft is a crucial issue it would be a pitty to hide this behind "additional licensing obligations" (which is quite unspecific).

Best,

Till

Am 17.11.19 um 08:06 schrieb Mark Gisi:
We have receive feedback from the larger public as part of the public
comments stage. Some of which has been incorporated in to the 2.1
draft rc3 while the remainder was queued for the next major version
revision that commences January 2020. Recent updates added in draft rc3 included:

 

·        SPDX project updated the definition of SPDX

·        Improve the word flow of the compliant artifact definition
(section
2.1)

·        An update to the compliant artifact examples definition to include:
“build and install scripts”

·        "copyleft obligations" was replaced with "additional
licensing obligations" – because copyleft was not defined, used only
once and was too specific.

·        Lowercased ‘S’ in “Software” in definition section 2.2

 

The current draft is available at:

  
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.1.dr
aft.pdf

 

Past readers of the spec might find the marked up version useful:

   
https://wiki.linuxfoundation.org/_media/openchain/OpenChainSpec-2.1.dr
aft.MarkUp.pdf
   

 

You can send public comments feedback via:

·        the Mailing list: the list
<https://lists.openchainproject.org/g/specification>;

·        the issues wiki: issues list
<https://github.com/OpenChain-Project/Specification/issues>; or

·        replying to me directly if you wish to remain anonymous
(mark.gisi@... <mailto:mark.gisi@...>)

 

best,

Mark

 

*Mark Gisi | Wind River | Director, IP & Open Source *

*Tel (510) 749-2016 | Fax (510) 749-4552*

 






Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: public comments: release candidate version 3 (rc3)

 

Hi Till

My take is that if we define one type of license we need to define them all. It would be an unnecessary burden on the complexity and clarity of the Specification. While we are defining the key requirements of a quality open source compliance program, the specification itself is not the appropriate place for educational activity on specific aspects of open source, while our reference material (such as the curriculum) is the appropriate venue. The curriculum already contains descriptions of permissive, copyleft and so on.

Regards

Shane

On Nov 18, 2019, at 3:16, Till Jaeger via Lists.Openchainproject.Org <jaeger=jbb.de@...> wrote:

Dear Mark,

Why not defining "Copyleft"? Copyleft is a crucial issue it would be a pitty
to hide this behind "additional licensing obligations" (which is quite
unspecific).

Best,

Till

Am 17.11.19 um 08:06 schrieb Mark Gisi:
We have receive feedback from the larger public as part of the public
comments stage. Some of which has been incorporated in to the 2.1 draft rc3
while the remainder was queued for the next major version revision that
commences January 2020. Recent updates added in draft rc3 included:



· SPDX project updated the definition of SPDX

· Improve the word flow of the compliant artifact definition (section
2.1)

· An update to the compliant artifact examples definition to include:
“build and install scripts”

· "copyleft obligations" was replaced with "additional licensing
obligations" – because copyleft was not defined, used only once and was too
specific.

· Lowercased ‘S’ in “Software” in definition section 2.2



The current draft is available at:

https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.1.draft.pdf



Past readers of the spec might find the marked up version useful:

https://wiki.linuxfoundation.org/_media/openchain/OpenChainSpec-2.1.draft.MarkUp.pdf




You can send public comments feedback via:

· the Mailing list: the list
<https://lists.openchainproject.org/g/specification>;

· the issues wiki: issues list
<https://github.com/OpenChain-Project/Specification/issues>; or

· replying to me directly if you wish to remain anonymous
(mark.gisi@... <mailto:mark.gisi@...>)



best,

Mark



*Mark Gisi | Wind River | Director, IP & Open Source *

*Tel (510) 749-2016 | Fax (510) 749-4552*