Date   

OpenChain (Specification and Conformance)

Kelly Williams
 

Shane will send out a new meeting series with the updated Uberconference line.
__________________________________________________
Join the call: https://www.uberconference.com/kellyw
Optional dial in number: 855-889-3011
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
 


Re: [EXTERNAL] Re: New definition for section 4.1 Compliance Artifacts

Chang, Hung <Hung.Chang@...>
 

Friendly suggestion on the language below, and you are free to defer the change until next edit if you choose to accept the suggestion. The language in question is as follows:

 

. . . Compliance Artifacts which may include (but not limited to) the following: . . . .

 

The language above is confusing for the following reasons: (1) “may” already suggests that reader is at her option to include or not include certain elements, but (2) “but not limited to” suggests that the list following the sentence is a non-exhaustive list, which implies that the items on the list are somehow required.

 

I would suggest the following edits:

(a)    Remove “but not limited to”; or

(b)   Rewrite the paragraph so it reads easier: Prepare the set of artifacts (“Compliance Artifacts”) which represent the output of the FOSS review program for each Supplied Software release. By way of example, the Compliance Artifacts may include source code, attribution notices, copyright notices, license text, modification notices, written offers, SPDX documents, etc.

 

On (b), while we have worked hard to remove legalese or other complicated sentence structures, I would encourage us, as a general comment, to continue using simple English – active voice, less compounded sentences, etc.  I know we have been word-smithing for months now and we have a deadline. That said, I think it’d be helpful for our brand, our readers, and our translators, to have a copy editor review the specification for readability in future iterations.

 

Hung

 

 

Hung Chang | Director, IP & Open Source Counsel | HARMAN | +1 650.906.8926 | hung.chang@...

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Thursday, March 23, 2017 4:26 PM
To: Kate Stewart; Gisi, Mark
Cc: openchain@...
Subject: [EXTERNAL] Re: [OpenChain] New definition for section 4.1 Compliance Artifacts

 

Agree, looks good to me too.

 

From: <openchain-bounces@...> on behalf of Kate Stewart <kstewart@...>
Date: Thursday, March 23, 2017 at 7:41 AM
To: Mark Gisi <Mark.Gisi@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] New definition for section 4.1 Compliance Artifacts

 

 

 

On Thu, Mar 23, 2017 at 12:19 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Hi,

 

At the last OpenChain spec meeting it was decided to try and rewrite section 4.1 to include SPDX documents in the Compliance Artifacts definition. This is one of the most important definitions of the specification. The rewrite of section 4.1 is presented below. We are seeking your feedback.

 

best,

Mark

 

4.1         Prepare the set of artifacts which represent the output of the of the FOSS review program for each Supplied Software release. This set is referred to as the Compliance Artifacts which may include (but not limited to) the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers, SPDX documents and so forth.

 

Verification Artifact(s):

ð      4.1.1 A documented procedure exists describing a process that ensures the Compliance Artifacts are prepared and distributed with Supplied Software as required by the Identified Licenses.

 

ð      4.1.2 Copies of the Compliance Artifacts of the Supplied Software are archived and easily retrievable, and the archive is planned to exist for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer).

 

Rationale:

Ensure the complete collection of Compliance Artifactsaccompany the Supplied Software as required by the Identified Licenses that govern the Supplied Software along with other reports created as part of the FOSS review process.

       

 

Thanks Mark.   Looks good to me!

 

Kate

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: OpenChain Specification 1.1 draft updates & status

Mark Gisi
 

Great. Thanks Karen.

 

- Mark

 

 

From: Copenhaver, Karen [mailto:kcopenhaver@...]
Sent: Friday, March 24, 2017 2:24 PM
To: Gisi, Mark; openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I was OK with 3.1.1 as it was – although I see that describe should be describes.  I think archiving the way it was in 3.1.1 is consistent with how it is used in 4.1.  And I am also OK with the way it is in this draft.  Both work.  Thanks!

 

From: Gisi, Mark [mailto:Mark.Gisi@...]
Sent: Friday, March 24, 2017 5:12 PM
To: Copenhaver, Karen; openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Thank you Karen, as always – excellent advice. I made your recommended changes which are highlighted in yellow:

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

 

Can you review all of section 3.1 one more time to make sure it captures what you intended?

 

Thanks,

- Mark

 

 

From: Copenhaver, Karen [mailto:kcopenhaver@...]
Sent: Friday, March 24, 2017 1:09 PM
To: Gisi, Mark; openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

First – what an amazing and excellent document – kudos to everyone for the focused energy that went into it. It is just awesome!

 

On 3.1 –  I wonder whether a non-English speaker might read too much into our use of different terms.  In the main sentence we use “an inventory.”   In 3.1.1 we refer to “archiving”.  In the Rationale of 3.1 we refer to a bill of materials – which I think is the most accurate term for 3.1.  (We also use archive in 4.1.2 (where archive is definitely the proper term)).   

 

One way that the first statement in 3.1 might be misunderstood is if the company has already created or is familiar with the idea of creating an internal repository of open source components that can be drawn from without review.  This was a common practice for many companies, but one that I think is not ideal as it often results in the use of older versions of projects that do not include all available updates and avoids a review of the specific use case for the component.  I would not want anyone to read 3.1 as suggesting the creation of such an internal repository “from which a Supplied Software release” could be “comprised.”

 

I would say “A process exists for creating and managing a FOSS component bill of materials which includes each component (and its Identified License) in a Supplied Software release.” 

 

The remainder of 3.1 looks great to me.

 

Some suggestions on nits:

 

Page 4 – add a blank line between paragraphs 2 and 3.  In Vision, I suggested once that trustworthy seemed like the right word rather than trusted, but I am assuming that was rejected and that is fine.

 

Page 6 – 1.1 The end of the second sentence of the Rationale seems to trail off.  Should it be: “other sections may [impose or suggest] requirements on the policy.” 

 

Page 6 -  1.2 – I think “as a minimum” should be “at a minimum” but that may just be my ear.  In the second bullet we use IP and I think that is the only time we refer to IP.    For non-lawyers and non-English speakers that is sometimes confused with Internet Protocol so I would spell it out.

 

Page 8 - 2.2 – “and the FOSS Liaison may be the same individual – rather than can.

 

Page 9 – 3.2 – for other lists following colons we generally have semicolons. And inserting “and/or” after the next to last bullet might be helpful in this context.

 

Page 10 – 4.1 – in the parenthetical I think we need “are” inserted in the context of the sentence  – (including but are not limited to)

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gisi, Mark
Sent: Friday, March 24, 2017 1:11 PM
To: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

>> another set of eyes is always appreciated.

 

To clarify what feedback we are accepting on the 1.1 version of the spec at this stage are:

·       Feedback on Section 3.1 (all levels)

·       Across the whole document: typos, grammar issues, formatting issues and basic doc clean-up

 

You can find the latest draft here:

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

 

thanks,

Mark

 

 

From: Gisi, Mark
Sent: Thursday, March 23, 2017 11:12 PM
To: 'Steve Cropper'
Cc: 'openchain@...'
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Re: OpenChain Specification 1.1 draft updates & status

Karen C.
 

I was OK with 3.1.1 as it was – although I see that describe should be describes.  I think archiving the way it was in 3.1.1 is consistent with how it is used in 4.1.  And I am also OK with the way it is in this draft.  Both work.  Thanks!

 

From: Gisi, Mark [mailto:Mark.Gisi@...]
Sent: Friday, March 24, 2017 5:12 PM
To: Copenhaver, Karen; openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Thank you Karen, as always – excellent advice. I made your recommended changes which are highlighted in yellow:

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

 

Can you review all of section 3.1 one more time to make sure it captures what you intended?

 

Thanks,

- Mark

 

 

From: Copenhaver, Karen [mailto:kcopenhaver@...]
Sent: Friday, March 24, 2017 1:09 PM
To: Gisi, Mark; openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

First – what an amazing and excellent document – kudos to everyone for the focused energy that went into it. It is just awesome!

 

On 3.1 –  I wonder whether a non-English speaker might read too much into our use of different terms.  In the main sentence we use “an inventory.”   In 3.1.1 we refer to “archiving”.  In the Rationale of 3.1 we refer to a bill of materials – which I think is the most accurate term for 3.1.  (We also use archive in 4.1.2 (where archive is definitely the proper term)).   

 

One way that the first statement in 3.1 might be misunderstood is if the company has already created or is familiar with the idea of creating an internal repository of open source components that can be drawn from without review.  This was a common practice for many companies, but one that I think is not ideal as it often results in the use of older versions of projects that do not include all available updates and avoids a review of the specific use case for the component.  I would not want anyone to read 3.1 as suggesting the creation of such an internal repository “from which a Supplied Software release” could be “comprised.”

 

I would say “A process exists for creating and managing a FOSS component bill of materials which includes each component (and its Identified License) in a Supplied Software release.” 

 

The remainder of 3.1 looks great to me.

 

Some suggestions on nits:

 

Page 4 – add a blank line between paragraphs 2 and 3.  In Vision, I suggested once that trustworthy seemed like the right word rather than trusted, but I am assuming that was rejected and that is fine.

 

Page 6 – 1.1 The end of the second sentence of the Rationale seems to trail off.  Should it be: “other sections may [impose or suggest] requirements on the policy.” 

 

Page 6 -  1.2 – I think “as a minimum” should be “at a minimum” but that may just be my ear.  In the second bullet we use IP and I think that is the only time we refer to IP.    For non-lawyers and non-English speakers that is sometimes confused with Internet Protocol so I would spell it out.

 

Page 8 - 2.2 – “and the FOSS Liaison may be the same individual – rather than can.

 

Page 9 – 3.2 – for other lists following colons we generally have semicolons. And inserting “and/or” after the next to last bullet might be helpful in this context.

 

Page 10 – 4.1 – in the parenthetical I think we need “are” inserted in the context of the sentence  – (including but are not limited to)

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gisi, Mark
Sent: Friday, March 24, 2017 1:11 PM
To: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

>> another set of eyes is always appreciated.

 

To clarify what feedback we are accepting on the 1.1 version of the spec at this stage are:

·         Feedback on Section 3.1 (all levels)

·         Across the whole document: typos, grammar issues, formatting issues and basic doc clean-up

 

You can find the latest draft here:

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

 

thanks,

Mark

 

 

From: Gisi, Mark
Sent: Thursday, March 23, 2017 11:12 PM
To: 'Steve Cropper'
Cc: 'openchain@...'
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Re: OpenChain Specification 1.1 draft updates & status

Mark Gisi
 

Thank you Karen, as always – excellent advice. I made your recommended changes which are highlighted in yellow:

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

 

Can you review all of section 3.1 one more time to make sure it captures what you intended?

 

Thanks,

- Mark

 

 

From: Copenhaver, Karen [mailto:kcopenhaver@...]
Sent: Friday, March 24, 2017 1:09 PM
To: Gisi, Mark; openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

First – what an amazing and excellent document – kudos to everyone for the focused energy that went into it. It is just awesome!

 

On 3.1 –  I wonder whether a non-English speaker might read too much into our use of different terms.  In the main sentence we use “an inventory.”   In 3.1.1 we refer to “archiving”.  In the Rationale of 3.1 we refer to a bill of materials – which I think is the most accurate term for 3.1.  (We also use archive in 4.1.2 (where archive is definitely the proper term)).   

 

One way that the first statement in 3.1 might be misunderstood is if the company has already created or is familiar with the idea of creating an internal repository of open source components that can be drawn from without review.  This was a common practice for many companies, but one that I think is not ideal as it often results in the use of older versions of projects that do not include all available updates and avoids a review of the specific use case for the component.  I would not want anyone to read 3.1 as suggesting the creation of such an internal repository “from which a Supplied Software release” could be “comprised.”

 

I would say “A process exists for creating and managing a FOSS component bill of materials which includes each component (and its Identified License) in a Supplied Software release.” 

 

The remainder of 3.1 looks great to me.

 

Some suggestions on nits:

 

Page 4 – add a blank line between paragraphs 2 and 3.  In Vision, I suggested once that trustworthy seemed like the right word rather than trusted, but I am assuming that was rejected and that is fine.

 

Page 6 – 1.1 The end of the second sentence of the Rationale seems to trail off.  Should it be: “other sections may [impose or suggest] requirements on the policy.” 

 

Page 6 -  1.2 – I think “as a minimum” should be “at a minimum” but that may just be my ear.  In the second bullet we use IP and I think that is the only time we refer to IP.    For non-lawyers and non-English speakers that is sometimes confused with Internet Protocol so I would spell it out.

 

Page 8 - 2.2 – “and the FOSS Liaison may be the same individual – rather than can.

 

Page 9 – 3.2 – for other lists following colons we generally have semicolons. And inserting “and/or” after the next to last bullet might be helpful in this context.

 

Page 10 – 4.1 – in the parenthetical I think we need “are” inserted in the context of the sentence  – (including but are not limited to)

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gisi, Mark
Sent: Friday, March 24, 2017 1:11 PM
To: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

>> another set of eyes is always appreciated.

 

To clarify what feedback we are accepting on the 1.1 version of the spec at this stage are:

·       Feedback on Section 3.1 (all levels)

·       Across the whole document: typos, grammar issues, formatting issues and basic doc clean-up

 

You can find the latest draft here:

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

 

thanks,

Mark

 

 

From: Gisi, Mark
Sent: Thursday, March 23, 2017 11:12 PM
To: 'Steve Cropper'
Cc: 'openchain@...'
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Re: OpenChain Specification 1.1 draft updates & status

Karen C.
 

First – what an amazing and excellent document – kudos to everyone for the focused energy that went into it. It is just awesome!

 

On 3.1 –  I wonder whether a non-English speaker might read too much into our use of different terms.  In the main sentence we use “an inventory.”   In 3.1.1 we refer to “archiving”.  In the Rationale of 3.1 we refer to a bill of materials – which I think is the most accurate term for 3.1.  (We also use archive in 4.1.2 (where archive is definitely the proper term)).   

 

One way that the first statement in 3.1 might be misunderstood is if the company has already created or is familiar with the idea of creating an internal repository of open source components that can be drawn from without review.  This was a common practice for many companies, but one that I think is not ideal as it often results in the use of older versions of projects that do not include all available updates and avoids a review of the specific use case for the component.  I would not want anyone to read 3.1 as suggesting the creation of such an internal repository “from which a Supplied Software release” could be “comprised.”

 

I would say “A process exists for creating and managing a FOSS component bill of materials which includes each component (and its Identified License) in a Supplied Software release.” 

 

The remainder of 3.1 looks great to me.

 

Some suggestions on nits:

 

Page 4 – add a blank line between paragraphs 2 and 3.  In Vision, I suggested once that trustworthy seemed like the right word rather than trusted, but I am assuming that was rejected and that is fine.

 

Page 6 – 1.1 The end of the second sentence of the Rationale seems to trail off.  Should it be: “other sections may [impose or suggest] requirements on the policy.” 

 

Page 6 -  1.2 – I think “as a minimum” should be “at a minimum” but that may just be my ear.  In the second bullet we use IP and I think that is the only time we refer to IP.    For non-lawyers and non-English speakers that is sometimes confused with Internet Protocol so I would spell it out.

 

Page 8 - 2.2 – “and the FOSS Liaison may be the same individual – rather than can.

 

Page 9 – 3.2 – for other lists following colons we generally have semicolons. And inserting “and/or” after the next to last bullet might be helpful in this context.

 

Page 10 – 4.1 – in the parenthetical I think we need “are” inserted in the context of the sentence  – (including but are not limited to)

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gisi, Mark
Sent: Friday, March 24, 2017 1:11 PM
To: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

>> another set of eyes is always appreciated.

 

To clarify what feedback we are accepting on the 1.1 version of the spec at this stage are:

·         Feedback on Section 3.1 (all levels)

·         Across the whole document: typos, grammar issues, formatting issues and basic doc clean-up

 

You can find the latest draft here:

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

 

thanks,

Mark

 

 

From: Gisi, Mark
Sent: Thursday, March 23, 2017 11:12 PM
To: 'Steve Cropper'
Cc: 'openchain@...'
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Choate Hall & Stewart LLP Confidentiality Notice:

This message is transmitted to you by or on behalf of the law firm of Choate, Hall & Stewart LLP. It is intended exclusively for the individual or entity to which it is addressed. The substance of this message, along with any attachments, may contain information that is proprietary, confidential and/or legally privileged or otherwise legally exempt from disclosure. If you are not the designated recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy and/or delete all copies of it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Re: OpenChain Specification 1.1 draft updates & status

Mark Gisi
 

>> another set of eyes is always appreciated.

 

To clarify what feedback we are accepting on the 1.1 version of the spec at this stage are:

·       Feedback on Section 3.1 (all levels)

·       Across the whole document: typos, grammar issues, formatting issues and basic doc clean-up

 

You can find the latest draft here:

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

 

thanks,

Mark

 

 

From: Gisi, Mark
Sent: Thursday, March 23, 2017 11:12 PM
To: 'Steve Cropper'
Cc: 'openchain@...'
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Re: OpenChain Specification 1.1 draft updates & status

Steve Cropper
 

My mistake!

I'll read the latest.

Cheers
Steve


Steve Cropper
+1 925 978 3457


On Mar 24, 2017, at 06:12, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Re: OpenChain Specification 1.1 draft updates & status

Mark Gisi
 

Hi Steve,

 

I spend the last week proofing, cleaning up and reviewing  the doc formatting. Those changes were fixed in the latest version which also include the new 4.1 text. The latest version can be found here:

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

 

another set of eyes is always appreciated.

 

thanks,

- Mark

 

 

From: Steve Cropper [mailto:stcroppe@...]
Sent: Thursday, March 23, 2017 10:49 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Apologies for this being past the deadline.

 

Will there be a grammar check before locking 1.1 down?

 

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

 

E.g.

 

"...from which in the Supplied Software is comprised."

 

"...is sufficiently robust to addressing handle an..."

 

Regards

Steve

 

 

Steve Cropper

+1 925 978 3457

 


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Re: OpenChain Specification 1.1 draft updates & status

Steve Cropper
 

Apologies for this being past the deadline.

Will there be a grammar check before locking 1.1 down?

I see a number of sentences that don't make sense which look like an edit was made where a word should have been deleted or added or modified.

E.g.

"...from which in the Supplied Software is comprised."

"...is sufficiently robust to addressing handle an..."

Regards
Steve



Steve Cropper
+1 925 978 3457


On Mar 24, 2017, at 01:18, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Redrafting of Section 3.1 to provide clarity around the core concept: managing a FOSS bill of materials

Mark Gisi
 

Section 3.1 was conceived to ensure  a compliance program creates and manages a FOSS bill of materials for each software release. The objective of the rewrite below is to capture the essences of that idea using the simplest of terms. We are seeking your feedback on this new drafting of section 3.1. This is our last item to address before we finalize version 1.1 of the specification.

 

best,

Mark

3.1         A process exists for creating and managing an inventory of FOSS components (and their respective Identified Licenses) from which a Supplied Software release is comprised.

 

Verification Artifact(s):

ð      3.1.1 A documented procedure exists that describe the process of identifying, tracking, and archiving information about the collection of FOSS components from which a Supplied Software release is comprised.

ð      3.1.2 FOSS component records exist for each Supplied Software release which demonstrates the documented procedure was properly followed.

 

Rationale:

To ensure a procedure exists for creating and managing a FOSS component bill of materials used to construct the Supplied Software. A bill of materials is needed to support the systematic review of each component’s license terms to understand the obligations and restrictions as it applies to the distribution of the Supplied Software.

 

 


Re: Japanese translation of OpenChain spec and curriculum

Shane Coughlan <shane@...>
 

Thanks Nori! Looking forward to welcoming our first Japanese translation to the project.

Regards

Shane 

On 24 Mar 2017, at 08:32, Noriaki Fukuyasu <fukuyasu@...> wrote:

Hi Shane

Thanks for the response.

>I defer to Mark on the specifics of the process to become maintainer. Mark, as a ballpark suggestion, perhaps it is >enough for us to have a known party such as Kunai San step forward as maintainer and be listed on the wiki?

Mark and I (and Kunai-san) are working on the process off-line. And yes, it would be great to list the name on the wiki once it is finalized.

>I am very excited to have the Japanese translations about to start. Regarding the Curriculum slides (which are not >subject to the same strict policy as the Specification), we are just about ready with the Release 3 slides to support >the forthcoming Specification 1.1. Perhaps we could start translation around these slides? If you agree I will send >you the relevant link.

Actually, it's been started based on the copy you sent us the other day :)

Please stay tuned ;)

regards

Nori


On Thu, Mar 23, 2017 at 4:57 PM, Shane Martin Coughlan <shane@...> wrote:
Hi Nori!

I defer to Mark on the specifics of the process to become maintainer. Mark, as a ballpark suggestion, perhaps it is enough for us to have a known party such as Kunai San step forward as maintainer and be listed on the wiki?

I am very excited to have the Japanese translations about to start. Regarding the Curriculum slides (which are not subject to the same strict policy as the Specification), we are just about ready with the Release 3 slides to support the forthcoming Specification 1.1. Perhaps we could start translation around these slides? If you agree I will send you the relevant link.

Regards

Shane

> On Mar 23, 2017, at 14:55, Noriaki Fukuyasu <fukuyasu@...> wrote:
>
> Hi Mark
>
> As for the maintainer of Japanese translation, Kunai-san, ex-director of LF Japan, will be taking that role.
> He is on this mailing list. Does he need to go through some kind of formal appointment process to become a maintainer?
>
> regards
>
> Nori
>
> On Thu, Mar 23, 2017 at 12:58 PM, Gisi, Mark <Mark.Gisi@...> wrote:
> Hi Nori,
>
>
>
> Thank you for taking the initiative to set up the infrastructure for the Japanese translations. The latest draft of the spec translation policy, which will be finalized at the April 3rd meeting, can be found here:
>
>     https://wiki.linuxfoundation.org/openchain/spec-translations
>
> One minor update to the policy is that we need to assign someone to serve as the lead translator (maintainer) to coordinate with others to produce the translation. Would you be serving as the Japanese translation maintainer?
>
>
>
> kind regards,
>
> - Mark
>
>
>
>
>
>
>
> From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Noriaki Fukuyasu
> Sent: Wednesday, March 22, 2017 6:24 PM
> To: openchain@lists.linuxfoundation.org
> Subject: [OpenChain] Japanese translation of OpenChain spec and curriculum
>
>
>
> Hi Shane & everyone
>
>
>
> As I promised earlier, I have been working on building a translation community as well as Omega-T+Github based collaboration environment, and now, it is about to be ready.
>
>
>
> we've set up a Github account at LF Japan and the initial version of the spec & curriculum will be pushed sometime very soon.
>
> Taniguchi-san, NEC, is currently preparing the repository.
>
>
>
> I hope Japanese speakers on this list will join our effort to brush up the translated materials.
>
> (I know Shane is a fluent Japanese speaker so at least he should be able to help :P )
>
>
>
> Anyway, please stay tuned!!
>
>
>
> regards
>
>
>
> Nori
>
>
>
>
>
>
>
>
>
> --
>
> Noriaki Fukuyasu
>
>
>
> The Linux Foundation
>
> Mail: fukuyasu@...
>
> Tel: +81-80-4350-1133
>
> Twitter: nori_fukuyasu
>
> Facebook: linuxfoundationjp
>
>
>
> Please visit our web sites:
>
> http://www.linuxfoundation.jp
>
> http://events.linuxfoundation.jp
>
> http://jp.linux.com
>
>
>
>
>
>
> --
> Noriaki Fukuyasu
>
> The Linux Foundation
> Mail: fukuyasu@...
> Tel: +81-80-4350-1133
> Twitter: nori_fukuyasu
> Facebook: linuxfoundationjp
>
> Please visit our web sites:
> http://www.linuxfoundation.jp
> http://events.linuxfoundation.jp
> http://jp.linux.com
>
> _______________________________________________
> OpenChain mailing list
> OpenChain@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/openchain




--
Noriaki Fukuyasu

The Linux Foundation
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:


Re: New definition for section 4.1 Compliance Artifacts

Shane Coughlan <shane@...>
 

Hi Mark

I believe this captures precisely what was discussed and agreed. 

Regards

Shane 

On 23 Mar 2017, at 14:19, Gisi, Mark <Mark.Gisi@...> wrote:

Hi,

 

At the last OpenChain spec meeting it was decided to try and rewrite section 4.1 to include SPDX documents in the Compliance Artifacts definition. This is one of the most important definitions of the specification. The rewrite of section 4.1 is presented below. We are seeking your feedback.

 

best,

Mark

 

4.1         Prepare the set of artifacts which represent the output of the of the FOSS review program for each Supplied Software release. This set is referred to as the Compliance Artifacts which may include (but not limited to) the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers, SPDX documents and so forth.

 

Verification Artifact(s):

ð      4.1.1 A documented procedure exists describing a process that ensures the Compliance Artifacts are prepared and distributed with Supplied Software as required by the Identified Licenses.

 

ð      4.1.2 Copies of the Compliance Artifacts of the Supplied Software are archived and easily retrievable, and the archive is planned to exist for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer).

 

Rationale:

Ensure the complete collection of Compliance Artifacts accompany the Supplied Software as required by the Identified Licenses that govern the Supplied Software along with other reports created as part of the FOSS review process.

       

 

 

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

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

 

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Re: OpenChain Specification 1.1 draft updates & status

Mark Gisi
 

Hi Jilayne,

 

The public comments window technically closed on Sunday (3/19). All issues raised by Sunday, including SPDX inclusion, have been addressed.  There was one more topic I promised to address at Monday’s (3/20) spec working group meeting which I will follow up shortly by email. That topic involves providing additional clarification around the concepts of section 3.1. If we are not able to  come to an agreement reasonably quickly we can move it to the next version (1.2) discussions.  Your feedback below will be addressed in the 1.2 spec discussions.

 

- Mark

 

 

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Thursday, March 23, 2017 4:33 PM
To: Jilayne Lovejoy; Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

 

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

 

Jilayne

 

--------------------

 

1.1 Rationale

- probably don’t need “other” twice in second sentence —> “Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.”

 

2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).”

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?

 

"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."

 

—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 

For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

 

"Verification Artifact(s):

ð 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

ð 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.

 

3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "

 

------------

 

Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.

 

Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."

 

—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?

 

 

 

 

From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: Japanese translation of OpenChain spec and curriculum

Noriaki Fukuyasu
 

Hi Shane

Thanks for the response.

>I defer to Mark on the specifics of the process to become maintainer. Mark, as a ballpark suggestion, perhaps it is >enough for us to have a known party such as Kunai San step forward as maintainer and be listed on the wiki?

Mark and I (and Kunai-san) are working on the process off-line. And yes, it would be great to list the name on the wiki once it is finalized.

>I am very excited to have the Japanese translations about to start. Regarding the Curriculum slides (which are not >subject to the same strict policy as the Specification), we are just about ready with the Release 3 slides to support >the forthcoming Specification 1.1. Perhaps we could start translation around these slides? If you agree I will send >you the relevant link.

Actually, it's been started based on the copy you sent us the other day :)

Please stay tuned ;)

regards

Nori


On Thu, Mar 23, 2017 at 4:57 PM, Shane Martin Coughlan <shane@...> wrote:
Hi Nori!

I defer to Mark on the specifics of the process to become maintainer. Mark, as a ballpark suggestion, perhaps it is enough for us to have a known party such as Kunai San step forward as maintainer and be listed on the wiki?

I am very excited to have the Japanese translations about to start. Regarding the Curriculum slides (which are not subject to the same strict policy as the Specification), we are just about ready with the Release 3 slides to support the forthcoming Specification 1.1. Perhaps we could start translation around these slides? If you agree I will send you the relevant link.

Regards

Shane

> On Mar 23, 2017, at 14:55, Noriaki Fukuyasu <fukuyasu@...> wrote:
>
> Hi Mark
>
> As for the maintainer of Japanese translation, Kunai-san, ex-director of LF Japan, will be taking that role.
> He is on this mailing list. Does he need to go through some kind of formal appointment process to become a maintainer?
>
> regards
>
> Nori
>
> On Thu, Mar 23, 2017 at 12:58 PM, Gisi, Mark <Mark.Gisi@...> wrote:
> Hi Nori,
>
>
>
> Thank you for taking the initiative to set up the infrastructure for the Japanese translations. The latest draft of the spec translation policy, which will be finalized at the April 3rd meeting, can be found here:
>
>     https://wiki.linuxfoundation.org/openchain/spec-translations
>
> One minor update to the policy is that we need to assign someone to serve as the lead translator (maintainer) to coordinate with others to produce the translation. Would you be serving as the Japanese translation maintainer?
>
>
>
> kind regards,
>
> - Mark
>
>
>
>
>
>
>
> From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Noriaki Fukuyasu
> Sent: Wednesday, March 22, 2017 6:24 PM
> To: openchain@lists.linuxfoundation.org
> Subject: [OpenChain] Japanese translation of OpenChain spec and curriculum
>
>
>
> Hi Shane & everyone
>
>
>
> As I promised earlier, I have been working on building a translation community as well as Omega-T+Github based collaboration environment, and now, it is about to be ready.
>
>
>
> we've set up a Github account at LF Japan and the initial version of the spec & curriculum will be pushed sometime very soon.
>
> Taniguchi-san, NEC, is currently preparing the repository.
>
>
>
> I hope Japanese speakers on this list will join our effort to brush up the translated materials.
>
> (I know Shane is a fluent Japanese speaker so at least he should be able to help :P )
>
>
>
> Anyway, please stay tuned!!
>
>
>
> regards
>
>
>
> Nori
>
>
>
>
>
>
>
>
>
> --
>
> Noriaki Fukuyasu
>
>
>
> The Linux Foundation
>
> Mail: fukuyasu@...
>
> Tel: +81-80-4350-1133
>
> Twitter: nori_fukuyasu
>
> Facebook: linuxfoundationjp
>
>
>
> Please visit our web sites:
>
> http://www.linuxfoundation.jp
>
> http://events.linuxfoundation.jp
>
> http://jp.linux.com
>
>
>
>
>
>
> --
> Noriaki Fukuyasu
>
> The Linux Foundation
> Mail: fukuyasu@...
> Tel: +81-80-4350-1133
> Twitter: nori_fukuyasu
> Facebook: linuxfoundationjp
>
> Please visit our web sites:
> http://www.linuxfoundation.jp
> http://events.linuxfoundation.jp
> http://jp.linux.com
>
> _______________________________________________
> OpenChain mailing list
> OpenChain@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/openchain




--
Noriaki Fukuyasu

The Linux Foundation
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:


Re: OpenChain Specification 1.1 draft updates & status

Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

I’m re-sending this in an edited version as there we some suggestions here that never made to the discussion on the call, and some of them are pretty minor:

Suggested edits in red with the relevant section in quotations, as well as comments in blue.

Jilayne

--------------------

1.1 Rationale

- probably don’t need “other” twice in second sentence —>Although no requirements are provided here on what should be included in the policy, other requirements in other sections may.


2.1 - third bullet, sentence could shortened: 

"Publicly identify means of contacting the FOSS Liaison by way of electronic communication"

—> if you gave a phone number, that would be good enough too? Does it have to be email?  Same question for 2.1.1:

"2.1.1 FOSS Liaison function is publicly identified (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).

—> I read this as saying email address is by way of example, not the specific required format, in other words, could also be a phone number – or do we specifically and intentionally want an email address?


"3.1 A process exists for identifying, tracking and archiving a list of all FOSS components (and their

respective Identified Licenses) from which Supplied Software is comprised in a trackable data format (such as SPDX). The process is followed for each Supplied Software release under the FOSS management program."


—> I don’t think the operative outcome here is “a list” so much as it is really “data”- may need to play with wording.  I’ve seen plenty of lists that were not impressive… (I.e., did not inspire trust)

I had edited this to accommodate SPDX. I still think this is an appropriate place to mention it, and would like to keep that on the docket for later discussions. 
For the current release, I think there was some agreement that “a list” was a bit too limiting, so I still think that minor change is viable for the 1.1 release.

"Verification Artifact(s):

 3.1.1 A documented procedure exists used to identify, track, and archive a list of FOSS

components and their Identified Licenses from which in the Supplied Software is comprised.

 3.1.2 Records exist that demonstrate the documented procedure was followed for each

Supplied Software release.


3.2 Rationale

"To ensure the FOSS management program is sufficiently robust to addressing handle an

organization’s typical common FOSS use cases as a result of that organization’s business

practices. That a process exists to support this activity and that that process is followed. "


------------


Alternative wording and other thoughts for later discussion :

3.1 A process (system) exists to capture and retain relevant data for all FOSS components (and their respected Identified Licenses from which Supplied Software is comprised (e.g., SPDX documents or fields used for such data). This process is followed (this system is used) for each Supplied Software release.


Rationale:

To ensure a process exists for identifying and listing all FOSS components used to construct the

Supplied Software and that process is followed. This inventory must exist to support the

systematic review of each component’s license terms to understand their respective distribution

obligations and restrictions applicable to the Supplied Software. The recorded inventory also

serves as evidence that the process was followed."


—> re: rationale and 3.1.2 - would existence of SPDX document for each release suffice as a “record”?





From: Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 8:34 PM
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>, Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

Hi Jilayne,

 

I look forward to your suggestions and discussion later today.

 

I agree that one of the main objectives of the OpenChain “project” is to educated. The OpenChain specification is just one of potentially many outputs of the OpenChain project but the spec has a specific objective  which I would describe in one word – trust. Trust that the spec represents a minimum set of requirements  every quality compliance program must satisfy. Trust in the quality of the compliance artifacts one receives from another OpenChain conforming organization - even if they did not use the same tools or procedures. With each change we make to the spec we need to ask first and foremost – does it strength or weaken trust. Trust is the spec’s value proposition and therefore trust takes precedence. However, with respect to the OpenChain project, education is overarching. If we succeed to create the trust we seek then the education part becomes a lot easier.

 

I think this is a worthwhile discussion as a group to see where we are aligned (and where we are not).  Thoughts?

 

- Mark

 

 

From: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Sent: Monday, March 20, 2017 9:43 AM
To: Gisi, Mark; Sami Atabani; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

In reference to your marketing comment below – the main goal of OpenChain, if we could reduce it to one word, I think would be “education.”  By defining the requirements for effective open source management, we are educating people on what that looks like as a first step, even before anyone can certify that they are in conformance of such requirements.  To that end, mentioning SPDX – as the only organized standard for communicating licensing, copyright, provenance, etc. information for (open source) software is part and parcel of that educational goal.  

 

I see what you mean about the change in definition structure complicating the previous mention. I plan to have a look at this more closely this afternoon, before our call later today, and try to propose some specific language changes.

 

Thanks,

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 20, 2017 at 4:37 PM
To: Sami Atabani <Sami.Atabani@...>, J Lovejoy <opensource@...>, Kate Stewart <kstewart@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Sami,

 

Artifact 4.1.2 in version 1.0 made reference to several examples (including SPDX). In version 4.1.2 no longer makes references to any examples. The main update to section 4.1  was to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively. The definition never  mentioned SPDX because compliance artifacts by definition are very specifically those things required by open source licenses. SPDX is not a requirement of any license so it does not fit. As I have noted in my last email –

If we want to include SPDX we will need to rework the definition of Compliance Artifacts. Keep in mind this is one of the most important definitions in the entire specification. Suggestions?

 

- Mark

 

 

 

From: Sami Atabani [mailto:Sami.Atabani@...]
Sent: Monday, March 20, 2017 2:54 AM
To: Gisi, Mark; J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: RE: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Hi Mark,

 

I recall that we used SPDX as an example so the original wording said something along the lines “such as SPDX” rather than making it a hard requirement to deliver SPDX documents. We discussed at the time that this will be helpful as it will assist the supply chain to better understand what is required to conform.

 

Thanks

 

Sami

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: New definition for section 4.1 Compliance Artifacts

Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

Agree, looks good to me too.

From: <openchain-bounces@...> on behalf of Kate Stewart <kstewart@...>
Date: Thursday, March 23, 2017 at 7:41 AM
To: Mark Gisi <Mark.Gisi@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] New definition for section 4.1 Compliance Artifacts



On Thu, Mar 23, 2017 at 12:19 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Hi,

 

At the last OpenChain spec meeting it was decided to try and rewrite section 4.1 to include SPDX documents in the Compliance Artifacts definition. This is one of the most important definitions of the specification. The rewrite of section 4.1 is presented below. We are seeking your feedback.

 

best,

Mark

 

4.1         Prepare the set of artifacts which represent the output of the of the FOSS review program for each Supplied Software release. This set is referred to as the Compliance Artifacts which may include (but not limited to) the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers, SPDX documents and so forth.

 

Verification Artifact(s):

ð      4.1.1 A documented procedure exists describing a process that ensures the Compliance Artifacts are prepared and distributed with Supplied Software as required by the Identified Licenses.

 

ð      4.1.2 Copies of the Compliance Artifacts of the Supplied Software are archived and easily retrievable, and the archive is planned to exist for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer).

 

Rationale:

Ensure the complete collection of Compliance Artifactsaccompany the Supplied Software as required by the Identified Licenses that govern the Supplied Software along with other reports created as part of the FOSS review process.

       


Thanks Mark.   Looks good to me!

Kate
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: Compliance Texts that are Machine Readable [WAS: New definition for...]

Gary O'Neall
 

Greetings all,

 

Agree with Mark’s suggestion that this could also be leveraged by the certification system.

 

I would be interested in participating and contributing to any machine readable format.

 

 

Gary

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gisi, Mark
Sent: Thursday, March 23, 2017 6:40 AM
To: Joseph Potvin; openchain@...
Cc: Joseph Potvin
Subject: Re: [OpenChain] Compliance Texts that are Machine Readable [WAS: New definition for...]

 

>> Has there been any thought to putting all this in a machine readable format like .yml?

 

This is the first suggestion that I am aware of. If there is sufficient demand for a machine readable format then we might treat it similar to a language translation task where, for a given format (e.g., .yml), we designate a maintainer to lead its creation.

 

>> and our intended potential use cases include automated domain-specific compliance verification.

 

The Conformance working group is constructing an online certification system. Perhaps a machine readable format would be useful in that context.  

 

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Joseph Potvin
Sent: Thursday, March 23, 2017 5:47 AM
To: openchain@...
Cc: Joseph Potvin
Subject: Re: [OpenChain] Compliance Texts that are Machine Readable [WAS: New definition for...]

 

John et.al.

Glad you mentioned that, and recently I came across the RASE (Requirement, Applicability, Selection and Exceptions) method of a Norwegian named Eilif Hjelseth with applications in building code compliance. (We're using it for table-oriented rules expression, and our intended potential use cases include automated domain-specific compliance verification. Are there others here who want to explore & advance this?

(Meanwhile, apologies for having just been silent on the list for a long time. Congratulations to the active participants on moving it all so far ahead! And also congratulations to Shane in the coordination role.)

 

Joseph Potvin
Executive Director, Xalgorithms Foundation
Mobile: 819-593-5983
jpotvin@...
https://www.xalgorithms.org

 

 

On Thu, Mar 23, 2017 at 8:25 AM, John Scott <john@...> wrote:

Has there been any thought to putting all this in a machine readable format like .yml?

recently the US gov has published Compliance Masonry : 

as a way to make machine readable compliance documents that are inheritable 

 

js

 

On March 23, 2017 at 1:19:19 AM, Gisi, Mark (mark.gisi@...) wrote:

Hi,

 

At the last OpenChain spec meeting it was decided to try and rewrite section 4.1 to include SPDX documents in the Compliance Artifacts definition. This is one of the most important definitions of the specification. The rewrite of section 4.1 is presented below. We are seeking your feedback.

 

best,

Mark

 

4.1         Prepare the set of artifacts which represent the output of the of the FOSS review program for each Supplied Software release. This set is referred to as the Compliance Artifacts which may include (but not limited to) the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers, SPDX documents and so forth.

 

Verification Artifact(s):

ð      4.1.1 A documented procedure exists describing a process that ensures the Compliance Artifacts are prepared and distributed with Supplied Software as required by the Identified Licenses.

 

ð      4.1.2 Copies of the Compliance Artifacts of the Supplied Software are archived and easily retrievable, and the archive is planned to exist for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer).

 

Rationale:

Ensure the complete collection of Compliance Artifacts accompany the Supplied Software as required by the Identified Licenses that govern the Supplied Software along with other reports created as part of the FOSS review process.

       

 

 

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

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

 

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

 


Re: New definition for section 4.1 Compliance Artifacts

Kate Stewart
 



On Thu, Mar 23, 2017 at 12:19 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Hi,

 

At the last OpenChain spec meeting it was decided to try and rewrite section 4.1 to include SPDX documents in the Compliance Artifacts definition. This is one of the most important definitions of the specification. The rewrite of section 4.1 is presented below. We are seeking your feedback.

 

best,

Mark

 

4.1         Prepare the set of artifacts which represent the output of the of the FOSS review program for each Supplied Software release. This set is referred to as the Compliance Artifacts which may include (but not limited to) the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers, SPDX documents and so forth.

 

Verification Artifact(s):

ð      4.1.1 A documented procedure exists describing a process that ensures the Compliance Artifacts are prepared and distributed with Supplied Software as required by the Identified Licenses.

 

ð      4.1.2 Copies of the Compliance Artifacts of the Supplied Software are archived and easily retrievable, and the archive is planned to exist for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer).

 

Rationale:

Ensure the complete collection of Compliance Artifacts accompany the Supplied Software as required by the Identified Licenses that govern the Supplied Software along with other reports created as part of the FOSS review process.

       


Thanks Mark.   Looks good to me!

Kate


Re: Compliance Texts that are Machine Readable [WAS: New definition for...]

Mark Gisi
 

>> Has there been any thought to putting all this in a machine readable format like .yml?

 

This is the first suggestion that I am aware of. If there is sufficient demand for a machine readable format then we might treat it similar to a language translation task where, for a given format (e.g., .yml), we designate a maintainer to lead its creation.

 

>> and our intended potential use cases include automated domain-specific compliance verification.

 

The Conformance working group is constructing an online certification system. Perhaps a machine readable format would be useful in that context.  

 

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Joseph Potvin
Sent: Thursday, March 23, 2017 5:47 AM
To: openchain@...
Cc: Joseph Potvin
Subject: Re: [OpenChain] Compliance Texts that are Machine Readable [WAS: New definition for...]

 

John et.al.

Glad you mentioned that, and recently I came across the RASE (Requirement, Applicability, Selection and Exceptions) method of a Norwegian named Eilif Hjelseth with applications in building code compliance. (We're using it for table-oriented rules expression, and our intended potential use cases include automated domain-specific compliance verification. Are there others here who want to explore & advance this?

(Meanwhile, apologies for having just been silent on the list for a long time. Congratulations to the active participants on moving it all so far ahead! And also congratulations to Shane in the coordination role.)

 

Joseph Potvin
Executive Director, Xalgorithms Foundation
Mobile: 819-593-5983
jpotvin@...
https://www.xalgorithms.org

 

 

On Thu, Mar 23, 2017 at 8:25 AM, John Scott <john@...> wrote:

Has there been any thought to putting all this in a machine readable format like .yml?

recently the US gov has published Compliance Masonry : 

as a way to make machine readable compliance documents that are inheritable 

 

js

 

On March 23, 2017 at 1:19:19 AM, Gisi, Mark (mark.gisi@...) wrote:

Hi,

 

At the last OpenChain spec meeting it was decided to try and rewrite section 4.1 to include SPDX documents in the Compliance Artifacts definition. This is one of the most important definitions of the specification. The rewrite of section 4.1 is presented below. We are seeking your feedback.

 

best,

Mark

 

4.1         Prepare the set of artifacts which represent the output of the of the FOSS review program for each Supplied Software release. This set is referred to as the Compliance Artifacts which may include (but not limited to) the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers, SPDX documents and so forth.

 

Verification Artifact(s):

ð      4.1.1 A documented procedure exists describing a process that ensures the Compliance Artifacts are prepared and distributed with Supplied Software as required by the Identified Licenses.

 

ð      4.1.2 Copies of the Compliance Artifacts of the Supplied Software are archived and easily retrievable, and the archive is planned to exist for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer).

 

Rationale:

Ensure the complete collection of Compliance Artifacts accompany the Supplied Software as required by the Identified Licenses that govern the Supplied Software along with other reports created as part of the FOSS review process.

       

 

 

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

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

 

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

 

4281 - 4300 of 5017