OpenChain Specification 1.1 draft updates & status


Mark Gisi
 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 


Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

HI Mark,

One small edit: 3.1.2 should be “documented” not “document”  :)

Otherwise, changes look good.

Jilayne

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@...>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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.


Malcolm Bain
 

Doing the translation to Spanish, I have quite a few comments regarding coherence of language and capital letters, etc.  

 

(e.g. conformity, compliance, certification are often used as synonyms but elsewhere as specific concepts, there is a “FOSS Management Program” which looks like a defined term, but never else mentioned… )

 

I think there is also a style coherence point, regarding what is the Requirement (existence of X) and what is an Evidence/Artefact (cannot be the same “existence of X” – must be “document evidencing existence of X). I think this goes wrong once or twice, towards the end).

 

I’ll put them all together and highlight when I send the Spanish version - shortly (ETA tomorrow)

 

malcolm

 

De: openchain-bounces@... [mailto:openchain-bounces@...] En nombre de Jilayne Lovejoy
Enviado el: miércoles, 15 de marzo de 2017 15:01
Para: Gisi, Mark <Mark.Gisi@...>; openchain@...
Asunto: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@...>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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.


Dave Marr
 

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@...>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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.


Kate Stewart
 

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@lists.linuxfoundation.org
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@lists.linuxfoundation.org> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@lists.linuxfoundation.org>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain




--
Kate Stewart
Sr. Director of Strategic Programs,  The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: kstewart@...


J Lovejoy
 

I agree with Kate. 
I don't even recall why it when it was dropped. 

To add to Kate's point about the overall story: in response to my keynote at the Open Source Leadership Summit where I gave an update on SPDX, FOSSology, and OpenChain, I got quite a few very positive comments about how it was very helpful to see how these things fit together, "I get it", and general interest. 


I think we want to continue to reinforce this overall picture, not recede from it. 

Jilayne 



Sent from my phone, please excuse my brevity

On Mar 15, 2017, at 11:56 PM, Kate Stewart <kstewart@...> wrote:

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@lists.linuxfoundation.org
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@lists.linuxfoundation.org> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@lists.linuxfoundation.org>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain




--
Kate Stewart
Sr. Director of Strategic Programs,  The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: kstewart@...
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Shane Coughlan <shane@...>
 

I concur with Kate and Jilayne.

Shane 

On 17 Mar 2017, at 14:02, J Lovejoy <opensource@...> wrote:

I agree with Kate. 
I don't even recall why it when it was dropped. 

To add to Kate's point about the overall story: in response to my keynote at the Open Source Leadership Summit where I gave an update on SPDX, FOSSology, and OpenChain, I got quite a few very positive comments about how it was very helpful to see how these things fit together, "I get it", and general interest. 


I think we want to continue to reinforce this overall picture, not recede from it. 

Jilayne 



Sent from my phone, please excuse my brevity

On Mar 15, 2017, at 11:56 PM, Kate Stewart <kstewart@...> wrote:

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@lists.linuxfoundation.org
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@lists.linuxfoundation.org> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@lists.linuxfoundation.org>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain




--
Kate Stewart
Sr. Director of Strategic Programs,  The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: kstewart@...
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Dave Marr
 

Sure and if we add it back I would support keeping the definition.  Good points.

Dave

On Mar 16, 2017, at 10:31 PM, Shane Coughlan <shane@...> wrote:

I concur with Kate and Jilayne.

Shane 

On 17 Mar 2017, at 14:02, J Lovejoy <opensource@...> wrote:

I agree with Kate. 
I don't even recall why it when it was dropped. 

To add to Kate's point about the overall story: in response to my keynote at the Open Source Leadership Summit where I gave an update on SPDX, FOSSology, and OpenChain, I got quite a few very positive comments about how it was very helpful to see how these things fit together, "I get it", and general interest. 


I think we want to continue to reinforce this overall picture, not recede from it. 

Jilayne 



Sent from my phone, please excuse my brevity

On Mar 15, 2017, at 11:56 PM, Kate Stewart <kstewart@...> wrote:

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@lists.linuxfoundation.org
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@lists.linuxfoundation.org> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@lists.linuxfoundation.org>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain




--
Kate Stewart
Sr. Director of Strategic Programs,  The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: kstewart@...
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Mark Gisi
 

 

Sorry for the delayed response. I am working on several deliverables due tomorrow. I will follow up with this week’s comments by end of tomorrow (Friday).

 

best,

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of David Marr
Sent: Thursday, March 16, 2017 10:35 PM
To: Shane Coughlan
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Sure and if we add it back I would support keeping the definition.  Good points.

Dave


On Mar 16, 2017, at 10:31 PM, Shane Coughlan <shane@...> wrote:

I concur with Kate and Jilayne.

 

Shane 


On 17 Mar 2017, at 14:02, J Lovejoy <opensource@...> wrote:

I agree with Kate. 

I don't even recall why it when it was dropped. 

 

To add to Kate's point about the overall story: in response to my keynote at the Open Source Leadership Summit where I gave an update on SPDX, FOSSology, and OpenChain, I got quite a few very positive comments about how it was very helpful to see how these things fit together, "I get it", and general interest. 

 

 

I think we want to continue to reinforce this overall picture, not recede from it. 

 

Jilayne 

 

 

 

Sent from my phone, please excuse my brevity


On Mar 15, 2017, at 11:56 PM, Kate Stewart <kstewart@...> wrote:

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

 

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@...>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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



 

--

Kate Stewart

Sr. Director of Strategic Programs,  The Linux Foundation

Mobile: +1.512.657.3669

Email / Google Talk: kstewart@...

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

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

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


Mark Gisi
 

Kate,

 

>> Please insert the reference to SPDX documents back into the specification in section 4

 

Section 4.1 was rewritten several months back to accommodate moving the Compliance Artifacts definition from the Definitions section 4.1 where it is used exclusively.

4.1 Prepare the set of artifacts that each Identified License requires accompany the Supplied Software. They include but are not limited to the following: source code, attribution notices, copyright notices, copy of licenses, modification notifications, written offers and so forth (Compliance Artifacts).

 

SPDX was not included in the definition because it is not a requirement of any open source license. 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 specifications. Suggestions?

 

- Mark

 

 

From: Kate Stewart [mailto:kstewart@...]
Sent: Wednesday, March 15, 2017 10:57 PM
To: David Marr
Cc: Jilayne Lovejoy; Gisi, Mark; openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

 

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 


Mark Gisi
 

>> I think we want to continue to reinforce this overall picture, not recede from it. 

 

We need to careful here not to conflate a specification for a marketing doc. The specification serves one purpose – define the core set of requirements one should expect every quality open source compliance program must satisfy. The integrity and success of the specification depends upon our ability to maintain that focus in its evolution. We want to avoid diluting  the “product” with marketing spin. That is, the specification does not tell a story.  On the other hand, the OpenChain “project” has a much bigger mission which includes telling stories and making connections using various vehicles  including presentations, white papers, best practice materials and so forth.

 

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of J Lovejoy
Sent: Thursday, March 16, 2017 10:02 PM
To: Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I agree with Kate. 

I don't even recall why it when it was dropped. 

 

To add to Kate's point about the overall story: in response to my keynote at the Open Source Leadership Summit where I gave an update on SPDX, FOSSology, and OpenChain, I got quite a few very positive comments about how it was very helpful to see how these things fit together, "I get it", and general interest. 

 

 

I think we want to continue to reinforce this overall picture, not recede from it. 

 

Jilayne 

 

 

 

Sent from my phone, please excuse my brevity


On Mar 15, 2017, at 11:56 PM, Kate Stewart <kstewart@...> wrote:

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

 

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@...>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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



 

--

Kate Stewart

Sr. Director of Strategic Programs,  The Linux Foundation

Mobile: +1.512.657.3669

Email / Google Talk: kstewart@...

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


Sami Atabani
 

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

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gisi, Mark
Sent: 18 March 2017 03:44
To: J Lovejoy; Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

>> I think we want to continue to reinforce this overall picture, not recede from it. 

 

We need to careful here not to conflate a specification for a marketing doc. The specification serves one purpose – define the core set of requirements one should expect every quality open source compliance program must satisfy. The integrity and success of the specification depends upon our ability to maintain that focus in its evolution. We want to avoid diluting  the “product” with marketing spin. That is, the specification does not tell a story.  On the other hand, the OpenChain “project” has a much bigger mission which includes telling stories and making connections using various vehicles  including presentations, white papers, best practice materials and so forth.

 

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of J Lovejoy
Sent: Thursday, March 16, 2017 10:02 PM
To: Kate Stewart
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

I agree with Kate. 

I don't even recall why it when it was dropped. 

 

To add to Kate's point about the overall story: in response to my keynote at the Open Source Leadership Summit where I gave an update on SPDX, FOSSology, and OpenChain, I got quite a few very positive comments about how it was very helpful to see how these things fit together, "I get it", and general interest. 

 

 

I think we want to continue to reinforce this overall picture, not recede from it. 

 

Jilayne 

 

 

 

Sent from my phone, please excuse my brevity


On Mar 15, 2017, at 11:56 PM, Kate Stewart <kstewart@...> wrote:

Please insert the reference to SPDX documents back into the specification in section 4, and leave the definition in the specification.   Dropping it is not yellow lined in the 1.1 version of the specification, and not providing an example on how these artifacts can be distributed in a consistent manner weakens the overall story.

 

On Wed, Mar 15, 2017 at 7:07 PM, David Marr <dmarr@...> wrote:

Also we should also consider removing the definition of SPDX since it's no longer specifically referenced in the body of the spec itself.  Credit to Jeff Kaufman from Redhat.  Thanks,

 

Dave

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Wednesday, March 15, 2017 7:01 AM
To: Gisi, Mark <Mark.Gisi@...>; openchain@...
Subject: Re: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

HI Mark,

 

One small edit: 3.1.2 should be “documented” not “document”  :)

 

Otherwise, changes look good.

 

Jilayne

 

From: <openchain-bounces@...> on behalf of Mark Gisi <Mark.Gisi@...>
Date: Monday, March 13, 2017 at 6:24 AM
To: OpenChain <openchain@...>
Subject: [OpenChain] OpenChain Specification 1.1 draft updates & status

 

The near final version of the OpenChain Specification 1.1 is available at:

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

 

The most recent changes can be found in yellow highlights. We have gone through about 75% of the public comments. We expect to complete  the review of the comments at the upcoming spec group discussion on March 20th. The public comments along with responses can be found on the following wiki page:

    https://wiki.linuxfoundation.org/openchain/spec-1.1-draft-public-comments

 

best,

- Mark

 

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

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

 

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



 

--

Kate Stewart

Sr. Director of Strategic Programs,  The Linux Foundation

Mobile: +1.512.657.3669

Email / Google Talk: kstewart@...

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

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.


Mark Gisi
 

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


Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

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.


Mark Gisi
 

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.


Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

Hi All,

Here are some suggested edits in red with the relevant section in quotations, as well as comments in blue.

Look forward to discussing later.

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 – does everyone else agree?


"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)


Alternative wording:

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.


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


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”?


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


"4.1 Prepare the set of artifacts that each Identified License requires and ensure such artifacts accompany the Supplied

Software as required. They include but are not limited to the following: source code, attribution notices,

copyright notices, copy of licenses, modification notifications, written offers and so forth

(Compliance Artifacts)."


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.


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.


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.


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


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