1. main@lists.openchainproject.org
  2. Messages
   Date   
Invitation: OpenChain Working Group (First and Third Tuesday of each ... @ Monthly from 11am to 12pm on the first Tuesday from Tue Oct 7 to Tue Dec 5, 2017 (Michael Dolan)

Michael Dolan <mdolan@...>
 

OpenChain Working Group (First and Third Tuesday of each Month)

Audio portion:

Conference Number: +1 (415) 906-5657 Pin: 88326
UberConference URL: http://uberconference.com/mdolan

For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions:
http://www.uberconference.com/international/access

Screen share (if used): go to http://uberconference.com/mdolan

When
Monthly from 11am to 12pm on the first Tuesday from Tue Oct 7 to Tue Dec 5, 2017 Eastern Time
Where
Conference Number: +1 (415) 906-5657 Pin: 88326 URL: http://uberconference.com/mdolan (map)
Calendar
Michael Dolan
Who
•
Michael Dolan - organizer
•
openchain@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account openchain@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Calendar
Calendar

OpenChain Meeting Schedule and Invites

Mike Dolan <mdolan@...>
 

Hi everyone, I just sent out invites to the mailing list for the OpenChain Working Group. Having worked on various projects with large groups from many companies, I am aware there are significant challenges between Outlook, Google Calendar, Lotus Notes and other calendaring systems companies use. Our own calendaring system required me to send two separate invitations so you should see two invites from me. There is one for the first Tuesday of each month. The second invite is for the third Tuesday of each month. Please accept both. 

If accepting the invite is a challenge due to calendaring system issues, feel free to block the days and time in your own system. The calls will be at 11am Eastern, 8am Pacific on the first and third Tuesday of each month. The conference call instructions and screen sharing information is below.

———
Audio portion:

Conference Number: +1 (415) 906-5657  Pin: 88326

For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions:

Screen share (if used): go to http://uberconference.com/mdolan
———

---
Mike Dolan
Director of Strategic Programs, The Linux Foundation
Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
Email / Google Talk: mdolan@...
---
Updated Invitation: OpenChain Working Group (First and Third Tuesday each month) @ Monthly from 11am to 12pm on the third Tuesday from Tue Sep 16 to Tue Dec 19, 2017 (Michael Dolan)

mdolan@linuxfoundation.org <mdolan@...>
 

This event has been changed.

OpenChain Working Group (First and Third Tuesday each month)

Audio portion:

Conference Number: +1 (415) 906-5657 Pin: 88326
UberConference URL: http://uberconference.com/mdolan

For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions:
http://www.uberconference.com/international/access

Screen share (if used): go to http://uberconference.com/mdolan

When
Changed: Monthly from 11am to 12pm on the third Tuesday from Tue Sep 16 to Tue Dec 19, 2017 Eastern Time
Where
Conference Number: +1 (415) 906-5657 Pin: 88326 UberConference URL: http://uberconference.com/mdolan (map)
Calendar
Michael Dolan
Who
•
Michael Dolan - organizer
•
openchain@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account openchain@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Calendar
Calendar

Re: Hello World!

Claus-Peter Wiedemann
 

Hi everyone,

 

Thank you for bringing this up. Having this clarified is vital for the open chain activities. Let me add one more aspect. As Mark pointed out, SPDX is a format (like, say, XML). There are some tools (and hopefully many more in the future) to process/convert SPDX files. And once V2.0 with important features like hierarchy is out,  the adoption rate will increase. But when dealing with license information in the supply chain, the format is only one side of the story. It greatly impacts efficiency but not so much effectiveness. The crucial factor is the quality of the content. As we all know, every member of the supply chain is responsible for the license compliance of its deliveries, including all pieces delivered by other members of the supply chain. Ideally, one would take the SPDX files delivered, add  additional content for the pieces produced and pass on the combined SPDX to the downstream recipients. This is very efficient and duplicate work is avoided. But is it effective? Nobody knows, since there are no quality standards for license information. How was it produced? How was it verified? I think that open chain must focus on the “content” aspect rather than on the “format” aspect (which is basically solved with SPDX). We need some standards (like ISO 9001, CMMI,…) for dealing with license information and certification for organizations adhering to these standards.


What do you think?

 

Best regards

Claus-Peter

 

Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Jilayne Lovejoy
Gesendet: Freitag, 29. August 2014 20:46
An: Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Betreff: Re: [OpenChain] Hello World!

 

Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!

 

Jilayne

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Jeremiah raised some common concerns about SPDX that, as an early adopter, I wanted to share my experiences.

 

>> while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX

>> version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development)

 

SPDX is a specification and not a tool.

 

Okay, I confess I view it more as a tool, good to have this clarified for me.

 

It is analogous to PDF, which is also a specification. Specification details are largely relevant to tool developers and not so much to the tool end users. Most of us view PDF files using one tool or another, but very few of us know what the specifications looks like (nor should we need to). Therefore updates to a specification largely only impact tool developers. Adobe released multiple versions of the PDF spec over the course of the first few years.  This is to be expected.

 

>> Being Java based (there is Go code and python code now) its better suited for those working in a

>> Windows environment and while I'm certain that is a highly lucrative market,

>> for Free Software developers it tends to be anathema.

 

Since SPDX is a specification I assume you are referring to tool support. I understand your concerns here. Additional tool support is a place where SPDX could benefit.

 

>> For example, while SPDX looks great, its not widely adopted.

 

Although the jury is still out on SPDX, it is progressing through the typical stages of technology adoption as described in Geoffrey Moore’s entrepreneurial bible: “Crossing the Chasm”.  At Wind River we see early adopter participation rapidly increasing.  We have seen a tripling in customer usage over the past 12 months which includes traffic to our free SPDX file generation website (spdx.windriver.com). Similarly, PDF too got off to a slow start, yet triumphed in the end.

 

>> and feels a bit like a solution looking for a problem.

 

Wind River’s adoption was heavily driven by a mission critical problem we faced. Wind River offers a Linux Distro kit consisting of more than 1000 software packages plus a kernel. In the beginning, customers demanded contractually that we deliver “complete” licensing information using their “customized” format. This was a nightmare. We were required to rummage through millions of source files to grab the specified licensing information to be put into the customer’s “custom” format.  After we preformed this task it was repeated by other organizations downstream in the supply chain. We understood this cost could be significantly mitigated if there was a commonly accepted file format we could use to record and exchange licensing information. SPDX directly solved this problem. We also utilize SPDX data in our internal compliance program.

 

Thanks very much for this email. Puts SPDX into the right perspective for me. I've sort of viewed it from a software engineer's view as this thing I have to add not knowing really why. If it does provide a software Bill of Materials that can effectively provide assurance in the supply chain then clearly its a solution to a very real problem.

 

Regards,

 

Jeremiah

 


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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

Re: Hello World!

Soeren_Rabenstein@...
 

Hi Peter

 

Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them and may merely convey the information which quality standards have been complied with, they may also include a verification code or the like, but should not define the standards in any way.

Maybe the “creator”-identifier could be used for QA information?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

____________________________________________________________

 

Sören Rabenstein, LL.M.
Senior Legal Counsel

ASUS Legal Affairs Center - Europe

Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...

 

ASUS Computer GmbH
Harkortstr. 21-23, 40880 Ratingen

Geschäftsführer: Eric Chen

Amtsgericht Düsseldorf: HRB43472
____________________________________________________________

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Wiedemann, Claus-Peter
Sent: Montag, 8. September 2014 10:43
To: Jilayne Lovejoy; Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

Hi everyone,

 

Thank you for bringing this up. Having this clarified is vital for the open chain activities. Let me add one more aspect. As Mark pointed out, SPDX is a format (like, say, XML). There are some tools (and hopefully many more in the future) to process/convert SPDX files. And once V2.0 with important features like hierarchy is out,  the adoption rate will increase. But when dealing with license information in the supply chain, the format is only one side of the story. It greatly impacts efficiency but not so much effectiveness. The crucial factor is the quality of the content. As we all know, every member of the supply chain is responsible for the license compliance of its deliveries, including all pieces delivered by other members of the supply chain. Ideally, one would take the SPDX files delivered, add  additional content for the pieces produced and pass on the combined SPDX to the downstream recipients. This is very efficient and duplicate work is avoided. But is it effective? Nobody knows, since there are no quality standards for license information. How was it produced? How was it verified? I think that open chain must focus on the “content” aspect rather than on the “format” aspect (which is basically solved with SPDX). We need some standards (like ISO 9001, CMMI,…) for dealing with license information and certification for organizations adhering to these standards.


What do you think?

 

Best regards

Claus-Peter

 

Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Jilayne Lovejoy
Gesendet: Freitag, 29. August 2014 20:46
An: Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Betreff: Re: [OpenChain] Hello World!

 

Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!

 

Jilayne

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Jeremiah raised some common concerns about SPDX that, as an early adopter, I wanted to share my experiences.

 

>> while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX

>> version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development)

 

SPDX is a specification and not a tool.

 

Okay, I confess I view it more as a tool, good to have this clarified for me.

 

It is analogous to PDF, which is also a specification. Specification details are largely relevant to tool developers and not so much to the tool end users. Most of us view PDF files using one tool or another, but very few of us know what the specifications looks like (nor should we need to). Therefore updates to a specification largely only impact tool developers. Adobe released multiple versions of the PDF spec over the course of the first few years.  This is to be expected.

 

>> Being Java based (there is Go code and python code now) its better suited for those working in a

>> Windows environment and while I'm certain that is a highly lucrative market,

>> for Free Software developers it tends to be anathema.

 

Since SPDX is a specification I assume you are referring to tool support. I understand your concerns here. Additional tool support is a place where SPDX could benefit.

 

>> For example, while SPDX looks great, its not widely adopted.

 

Although the jury is still out on SPDX, it is progressing through the typical stages of technology adoption as described in Geoffrey Moore’s entrepreneurial bible: “Crossing the Chasm”.  At Wind River we see early adopter participation rapidly increasing.  We have seen a tripling in customer usage over the past 12 months which includes traffic to our free SPDX file generation website (spdx.windriver.com). Similarly, PDF too got off to a slow start, yet triumphed in the end.

 

>> and feels a bit like a solution looking for a problem.

 

Wind River’s adoption was heavily driven by a mission critical problem we faced. Wind River offers a Linux Distro kit consisting of more than 1000 software packages plus a kernel. In the beginning, customers demanded contractually that we deliver “complete” licensing information using their “customized” format. This was a nightmare. We were required to rummage through millions of source files to grab the specified licensing information to be put into the customer’s “custom” format.  After we preformed this task it was repeated by other organizations downstream in the supply chain. We understood this cost could be significantly mitigated if there was a commonly accepted file format we could use to record and exchange licensing information. SPDX directly solved this problem. We also utilize SPDX data in our internal compliance program.

 

Thanks very much for this email. Puts SPDX into the right perspective for me. I've sort of viewed it from a software engineer's view as this thing I have to add not knowing really why. If it does provide a software Bill of Materials that can effectively provide assurance in the supply chain then clearly its a solution to a very real problem.

 

Regards,

 

Jeremiah

 


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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.


=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================
Re: Hello World!

Jeremiah Foster <jeremiah.foster@...>
 




On Fri, Aug 29, 2014 at 1:19 PM, Philip Odence <podence@...> wrote:
Hey Jeremiah,

It’s been a while. Forgive me for doing a lousy job educating you on SPDX.

Not at all! My misunderstanding is not due to your pedagogy. :P
 
Thanks, MarkG for filling in.

Having been involved in SPDX from the outset, I can tell you that there are many issues, but lack of a problem focus really isn’t one. Attached is the high level way we’ve expressed it. We’ve been well-focused, I believe, on providing a lingua franca for partners in a supply chain to exchange software BoM information. There’s been external pressure, by the way, to expand our focus, for example into OpenChain type activities—thanks, Dave Marr, for starting OC and thereby relieving the pressure. 

I think Open Chain might complement SPDX quite well.

Adoption is a challenge, a real chicken/egg problem. How do you get people to communicate in your language when it’s hard to find others who are fluent? That said Wind River, TI, Siemens, Samsung, Alcatel-Lucent and others have all started using SPDX internally and increasingly with partners. I have been heartened this year to learn of a number of companies using SPDX who have never been involved with the group developing the standard. We would love their involvement, but that fact that organizations can get value, without being in the middle of SPDX specification development, says to me we’ve turned a corner and that the virtuous cycles are starting to spin.

Version 2.0 does look promising. I think SPDX would benefit greatly from some more public roadmap description and perhaps a promise that the format churn might settle a little. Having to use version 1.1 in Yocto (with a paucity of good documentation) and wanting 2.0 features is a bit suboptimal, but then that is not SPDX's fault. Communicating a roadmap and promising some stability (1.1, 1.2, 2.0 seem to have come out rather quickly after each other) would potentially go a long way towards adoption.

Cheers,

Jeremiah
 

The SPDX group will stay close to the OpenChain activities. As Bogart said, “I think this is the beginning of a beautiful friendship.” 

Phil 
Re: Hello World!

Claus-Peter Wiedemann
 

Hi Soren,

 

I fully agree that SPDX should stay neutral wrt to quality of the “content”. It is not a matter of the format, it is a matter of the process creating the content. The “creator” identifier is useful to identify the origin. But in real life, it is important to know who conveyed the SPDX file to you and if that person/entity is “certified”, i.e. adheres to a certain standard for creating  the content.

 

Best regards

Claus-Peter

 

Von: Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Gesendet: Montag, 8. September 2014 11:08
An: Wiedemann, Claus-Peter; Jilayne.Lovejoy@...; jeremiah.foster@...; Mark.Gisi@...
Cc: openchain@...
Betreff: RE: [OpenChain] Hello World!

 

Hi Peter

 

Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them and may merely convey the information which quality standards have been complied with, they may also include a verification code or the like, but should not define the standards in any way.

Maybe the “creator”-identifier could be used for QA information?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

____________________________________________________________

 

Sören Rabenstein, LL.M.
Senior Legal Counsel

ASUS Legal Affairs Center - Europe

Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...

 

ASUS Computer GmbH
Harkortstr. 21-23, 40880 Ratingen

Geschäftsführer: Eric Chen

Amtsgericht Düsseldorf: HRB43472
____________________________________________________________

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Wiedemann, Claus-Peter
Sent: Montag, 8. September 2014 10:43
To: Jilayne Lovejoy; Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

Hi everyone,

 

Thank you for bringing this up. Having this clarified is vital for the open chain activities. Let me add one more aspect. As Mark pointed out, SPDX is a format (like, say, XML). There are some tools (and hopefully many more in the future) to process/convert SPDX files. And once V2.0 with important features like hierarchy is out,  the adoption rate will increase. But when dealing with license information in the supply chain, the format is only one side of the story. It greatly impacts efficiency but not so much effectiveness. The crucial factor is the quality of the content. As we all know, every member of the supply chain is responsible for the license compliance of its deliveries, including all pieces delivered by other members of the supply chain. Ideally, one would take the SPDX files delivered, add  additional content for the pieces produced and pass on the combined SPDX to the downstream recipients. This is very efficient and duplicate work is avoided. But is it effective? Nobody knows, since there are no quality standards for license information. How was it produced? How was it verified? I think that open chain must focus on the “content” aspect rather than on the “format” aspect (which is basically solved with SPDX). We need some standards (like ISO 9001, CMMI,…) for dealing with license information and certification for organizations adhering to these standards.


What do you think?

 

Best regards

Claus-Peter

 

Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Jilayne Lovejoy
Gesendet: Freitag, 29. August 2014 20:46
An: Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Betreff: Re: [OpenChain] Hello World!

 

Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!

 

Jilayne

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Jeremiah raised some common concerns about SPDX that, as an early adopter, I wanted to share my experiences.

 

>> while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX

>> version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development)

 

SPDX is a specification and not a tool.

 

Okay, I confess I view it more as a tool, good to have this clarified for me.

 

It is analogous to PDF, which is also a specification. Specification details are largely relevant to tool developers and not so much to the tool end users. Most of us view PDF files using one tool or another, but very few of us know what the specifications looks like (nor should we need to). Therefore updates to a specification largely only impact tool developers. Adobe released multiple versions of the PDF spec over the course of the first few years.  This is to be expected.

 

>> Being Java based (there is Go code and python code now) its better suited for those working in a

>> Windows environment and while I'm certain that is a highly lucrative market,

>> for Free Software developers it tends to be anathema.

 

Since SPDX is a specification I assume you are referring to tool support. I understand your concerns here. Additional tool support is a place where SPDX could benefit.

 

>> For example, while SPDX looks great, its not widely adopted.

 

Although the jury is still out on SPDX, it is progressing through the typical stages of technology adoption as described in Geoffrey Moore’s entrepreneurial bible: “Crossing the Chasm”.  At Wind River we see early adopter participation rapidly increasing.  We have seen a tripling in customer usage over the past 12 months which includes traffic to our free SPDX file generation website (spdx.windriver.com). Similarly, PDF too got off to a slow start, yet triumphed in the end.

 

>> and feels a bit like a solution looking for a problem.

 

Wind River’s adoption was heavily driven by a mission critical problem we faced. Wind River offers a Linux Distro kit consisting of more than 1000 software packages plus a kernel. In the beginning, customers demanded contractually that we deliver “complete” licensing information using their “customized” format. This was a nightmare. We were required to rummage through millions of source files to grab the specified licensing information to be put into the customer’s “custom” format.  After we preformed this task it was repeated by other organizations downstream in the supply chain. We understood this cost could be significantly mitigated if there was a commonly accepted file format we could use to record and exchange licensing information. SPDX directly solved this problem. We also utilize SPDX data in our internal compliance program.

 

Thanks very much for this email. Puts SPDX into the right perspective for me. I've sort of viewed it from a software engineer's view as this thing I have to add not knowing really why. If it does provide a software Bill of Materials that can effectively provide assurance in the supply chain then clearly its a solution to a very real problem.

 

Regards,

 

Jeremiah

 


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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.


=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

Re: Hello World!

Joseph Potvin
 

RE: "standards (like ISO 9001, CMMI,…)"  &  "Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them"

During the past year there has been ongoing work under the ISO umbrella towards a guideline on "Compliance management systems". We included some useful links about it in the OSI "FLOW Syllabus" for Management Education on Free/Libre/Open Works : http://wiki.opensource.org/bin/Projects/flow-syllabus#HAComplianceManagementProcess:ISO19600   

It's advantageous that ISO19600 is a guideline on compliance management systems generally, so that software license compliance management can more readily be operationalized and perceived as part of general corporate-wide conformance.

Perhaps it could be useful for the OpenChain community to work towards creatin sort of a "good housekeeping seal of approval" that aligns with the emerging ISO19600, but that includes the particulars required for software license compliance management, and then more particularly with open source software license compliance management.  This approach benefits from ISO19600, but remains separate from any eventual formal ISO certification in relation to that standard.

The gerenic compliance systems baseline provided by ISO 19600 can also be useful towards creating organizationally and inter-organizationally consistent approaches to data and database license compliance, and other areas.

--
Joseph Potvin
Chair, OSI Management Education Working Group

Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983





On Mon, Sep 8, 2014 at 5:57 AM, Wiedemann, Claus-Peter <claus-peter.wiedemann@...> wrote:

Hi Soren,

 

I fully agree that SPDX should stay neutral wrt to quality of the “content”. It is not a matter of the format, it is a matter of the process creating the content. The “creator” identifier is useful to identify the origin. But in real life, it is important to know who conveyed the SPDX file to you and if that person/entity is “certified”, i.e. adheres to a certain standard for creating  the content.

 

Best regards

Claus-Peter

 

Von: Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Gesendet: Montag, 8. September 2014 11:08
An: Wiedemann, Claus-Peter; Jilayne.Lovejoy@...; jeremiah.foster@...; Mark.Gisi@...
Cc: openchain@...
Betreff: RE: [OpenChain] Hello World!

 

Hi Peter

 

Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them and may merely convey the information which quality standards have been complied with, they may also include a verification code or the like, but should not define the standards in any way.

Maybe the “creator”-identifier could be used for QA information?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

____________________________________________________________

 

Sören Rabenstein, LL.M.
Senior Legal Counsel

ASUS Legal Affairs Center - Europe

Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...

 

ASUS Computer GmbH
Harkortstr. 21-23, 40880 Ratingen

Geschäftsführer: Eric Chen

Amtsgericht Düsseldorf: HRB43472
____________________________________________________________

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Wiedemann, Claus-Peter
Sent: Montag, 8. September 2014 10:43
To: Jilayne Lovejoy; Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

Hi everyone,

 

Thank you for bringing this up. Having this clarified is vital for the open chain activities. Let me add one more aspect. As Mark pointed out, SPDX is a format (like, say, XML). There are some tools (and hopefully many more in the future) to process/convert SPDX files. And once V2.0 with important features like hierarchy is out,  the adoption rate will increase. But when dealing with license information in the supply chain, the format is only one side of the story. It greatly impacts efficiency but not so much effectiveness. The crucial factor is the quality of the content. As we all know, every member of the supply chain is responsible for the license compliance of its deliveries, including all pieces delivered by other members of the supply chain. Ideally, one would take the SPDX files delivered, add  additional content for the pieces produced and pass on the combined SPDX to the downstream recipients. This is very efficient and duplicate work is avoided. But is it effective? Nobody knows, since there are no quality standards for license information. How was it produced? How was it verified? I think that open chain must focus on the “content” aspect rather than on the “format” aspect (which is basically solved with SPDX). We need some standards (like ISO 9001, CMMI,…) for dealing with license information and certification for organizations adhering to these standards.


What do you think?

 

Best regards

Claus-Peter

 

Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Jilayne Lovejoy
Gesendet: Freitag, 29. August 2014 20:46
An: Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Betreff: Re: [OpenChain] Hello World!

 

Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!

 

Jilayne

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Jeremiah raised some common concerns about SPDX that, as an early adopter, I wanted to share my experiences.

 

>> while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX

>> version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development)

 

SPDX is a specification and not a tool.

 

Okay, I confess I view it more as a tool, good to have this clarified for me.

 

It is analogous to PDF, which is also a specification. Specification details are largely relevant to tool developers and not so much to the tool end users. Most of us view PDF files using one tool or another, but very few of us know what the specifications looks like (nor should we need to). Therefore updates to a specification largely only impact tool developers. Adobe released multiple versions of the PDF spec over the course of the first few years.  This is to be expected.

 

>> Being Java based (there is Go code and python code now) its better suited for those working in a

>> Windows environment and while I'm certain that is a highly lucrative market,

>> for Free Software developers it tends to be anathema.

 

Since SPDX is a specification I assume you are referring to tool support. I understand your concerns here. Additional tool support is a place where SPDX could benefit.

 

>> For example, while SPDX looks great, its not widely adopted.

 

Although the jury is still out on SPDX, it is progressing through the typical stages of technology adoption as described in Geoffrey Moore’s entrepreneurial bible: “Crossing the Chasm”.  At Wind River we see early adopter participation rapidly increasing.  We have seen a tripling in customer usage over the past 12 months which includes traffic to our free SPDX file generation website (spdx.windriver.com). Similarly, PDF too got off to a slow start, yet triumphed in the end.

 

>> and feels a bit like a solution looking for a problem.

 

Wind River’s adoption was heavily driven by a mission critical problem we faced. Wind River offers a Linux Distro kit consisting of more than 1000 software packages plus a kernel. In the beginning, customers demanded contractually that we deliver “complete” licensing information using their “customized” format. This was a nightmare. We were required to rummage through millions of source files to grab the specified licensing information to be put into the customer’s “custom” format.  After we preformed this task it was repeated by other organizations downstream in the supply chain. We understood this cost could be significantly mitigated if there was a commonly accepted file format we could use to record and exchange licensing information. SPDX directly solved this problem. We also utilize SPDX data in our internal compliance program.

 

Thanks very much for this email. Puts SPDX into the right perspective for me. I've sort of viewed it from a software engineer's view as this thing I have to add not knowing really why. If it does provide a software Bill of Materials that can effectively provide assurance in the supply chain then clearly its a solution to a very real problem.

 

Regards,

 

Jeremiah

 


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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.


=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

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




--
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983

Re: Hello World!

Balaji Viswanathan <bviswanathan@...>
 

My first post in this chain here. I’m managing a new Blackduck initiative for the supply chain.

 

I would call attention to the IPC’s PDX standard that is already in used in the electronics industry. We could leverage some ideas from them to enable a seamless interaction between hardware & software supply chains in the same industry. Does anyone else have experience with this?

 

IPC-2570 Supply Chain Communication (PDX)

SUPPLY CHAIN COMMUNICATIONS (PDX) - IPC-257X

PDX is the Product Data eXchange standard for the e-supply chain. Product Data eXchange is a multi-part standard, represented by the IPC 2570 series of specifications. The Product Data eXchange standardization effort is focused on the problem of communicating product content information between Original Equipment Manufacturers, Electronics Manufacturing Services providers and component suppliers. The standard is based on XML because this provides a simple yet powerful and flexible way to encode structured data into a format that is both human and machine-readable.

The Product Data eXchange standard provides a way to describe product content (Bill of Materials (BOM), Approved Manufacturer Lists (AML), Drawings, etc.), Engineering Change Requests (ECR), Engineering Change Orders (ECO) and Deviations in an eXtensible Markup Language (XML) format. This standard will enable dramatic efficiency improvements throughout the supply chain since partners will have a way to exchange product content and changes in a common language.

 

http://webstds.ipc.org/standards.htm#x2570

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Joseph Potvin
Sent: Monday, September 08, 2014 12:50 PM
To: openchain@...
Cc: Patrick Masson
Subject: Re: [OpenChain] Hello World!

 

RE: "standards (like ISO 9001, CMMI,…)"  &  "Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them"


During the past year there has been ongoing work under the ISO umbrella towards a guideline on "Compliance management systems". We included some useful links about it in the OSI "FLOW Syllabus" for Management Education on Free/Libre/Open Works : http://wiki.opensource.org/bin/Projects/flow-syllabus#HAComplianceManagementProcess:ISO19600   


It's advantageous that ISO19600 is a guideline on compliance management systems generally, so that software license compliance management can more readily be operationalized and perceived as part of general corporate-wide conformance.

Perhaps it could be useful for the OpenChain community to work towards creatin sort of a "good housekeeping seal of approval" that aligns with the emerging ISO19600, but that includes the particulars required for software license compliance management, and then more particularly with open source software license compliance management.  This approach benefits from ISO19600, but remains separate from any eventual formal ISO certification in relation to that standard.

 

The gerenic compliance systems baseline provided by ISO 19600 can also be useful towards creating organizationally and inter-organizationally consistent approaches to data and database license compliance, and other areas.

--
Joseph Potvin
Chair, OSI Management Education Working Group


Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983



 

On Mon, Sep 8, 2014 at 5:57 AM, Wiedemann, Claus-Peter <claus-peter.wiedemann@...> wrote:

Hi Soren,

 

I fully agree that SPDX should stay neutral wrt to quality of the “content”. It is not a matter of the format, it is a matter of the process creating the content. The “creator” identifier is useful to identify the origin. But in real life, it is important to know who conveyed the SPDX file to you and if that person/entity is “certified”, i.e. adheres to a certain standard for creating  the content.

 

Best regards

Claus-Peter

 

Von: Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Gesendet: Montag, 8. September 2014 11:08
An: Wiedemann, Claus-Peter; Jilayne.Lovejoy@...; jeremiah.foster@...; Mark.Gisi@...
Cc: openchain@...
Betreff: RE: [OpenChain] Hello World!

 

Hi Peter

 

Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them and may merely convey the information which quality standards have been complied with, they may also include a verification code or the like, but should not define the standards in any way.

Maybe the “creator”-identifier could be used for QA information?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

____________________________________________________________

 

Sören Rabenstein, LL.M.
Senior Legal Counsel

ASUS Legal Affairs Center - Europe

Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...

 

ASUS Computer GmbH
Harkortstr. 21-23, 40880 Ratingen

Geschäftsführer: Eric Chen

Amtsgericht Düsseldorf: HRB43472
____________________________________________________________

 

 

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Wiedemann, Claus-Peter
Sent: Montag, 8. September 2014 10:43
To: Jilayne Lovejoy; Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

Hi everyone,

 

Thank you for bringing this up. Having this clarified is vital for the open chain activities. Let me add one more aspect. As Mark pointed out, SPDX is a format (like, say, XML). There are some tools (and hopefully many more in the future) to process/convert SPDX files. And once V2.0 with important features like hierarchy is out,  the adoption rate will increase. But when dealing with license information in the supply chain, the format is only one side of the story. It greatly impacts efficiency but not so much effectiveness. The crucial factor is the quality of the content. As we all know, every member of the supply chain is responsible for the license compliance of its deliveries, including all pieces delivered by other members of the supply chain. Ideally, one would take the SPDX files delivered, add  additional content for the pieces produced and pass on the combined SPDX to the downstream recipients. This is very efficient and duplicate work is avoided. But is it effective? Nobody knows, since there are no quality standards for license information. How was it produced? How was it verified? I think that open chain must focus on the “content” aspect rather than on the “format” aspect (which is basically solved with SPDX). We need some standards (like ISO 9001, CMMI,…) for dealing with license information and certification for organizations adhering to these standards.


What do you think?

 

Best regards

Claus-Peter

 

Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Jilayne Lovejoy
Gesendet: Freitag, 29. August 2014 20:46
An: Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Betreff: Re: [OpenChain] Hello World!

 

Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!

 

Jilayne

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!

 

On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Jeremiah raised some common concerns about SPDX that, as an early adopter, I wanted to share my experiences.

 

>> while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX

>> version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development)

 

SPDX is a specification and not a tool.

 

Okay, I confess I view it more as a tool, good to have this clarified for me.

 

It is analogous to PDF, which is also a specification. Specification details are largely relevant to tool developers and not so much to the tool end users. Most of us view PDF files using one tool or another, but very few of us know what the specifications looks like (nor should we need to). Therefore updates to a specification largely only impact tool developers. Adobe released multiple versions of the PDF spec over the course of the first few years.  This is to be expected.

 

>> Being Java based (there is Go code and python code now) its better suited for those working in a

>> Windows environment and while I'm certain that is a highly lucrative market,

>> for Free Software developers it tends to be anathema.

 

Since SPDX is a specification I assume you are referring to tool support. I understand your concerns here. Additional tool support is a place where SPDX could benefit.

 

>> For example, while SPDX looks great, its not widely adopted.

 

Although the jury is still out on SPDX, it is progressing through the typical stages of technology adoption as described in Geoffrey Moore’s entrepreneurial bible: “Crossing the Chasm”.  At Wind River we see early adopter participation rapidly increasing.  We have seen a tripling in customer usage over the past 12 months which includes traffic to our free SPDX file generation website (spdx.windriver.com). Similarly, PDF too got off to a slow start, yet triumphed in the end.

 

>> and feels a bit like a solution looking for a problem.

 

Wind River’s adoption was heavily driven by a mission critical problem we faced. Wind River offers a Linux Distro kit consisting of more than 1000 software packages plus a kernel. In the beginning, customers demanded contractually that we deliver “complete” licensing information using their “customized” format. This was a nightmare. We were required to rummage through millions of source files to grab the specified licensing information to be put into the customer’s “custom” format.  After we preformed this task it was repeated by other organizations downstream in the supply chain. We understood this cost could be significantly mitigated if there was a commonly accepted file format we could use to record and exchange licensing information. SPDX directly solved this problem. We also utilize SPDX data in our internal compliance program.

 

Thanks very much for this email. Puts SPDX into the right perspective for me. I've sort of viewed it from a software engineer's view as this thing I have to add not knowing really why. If it does provide a software Bill of Materials that can effectively provide assurance in the supply chain then clearly its a solution to a very real problem.

 

Regards,

 

Jeremiah

 


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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.


=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.


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




--
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983

OpenChain -- Agenda Bashing for Tuesday 9/16

Dave Marr
 

Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST.

 

In our last meeting we discussed that training materials would be on the agenda for the next meeting.  Additionally, may I suggest the topic of acceptance criteria.  Yixiong from Qualcomm Technologies has offered to join the call and provide a suggestion on how OpenChain might consider handling acceptance criteria and ways to create consistency.

 

Based on a review of the discussion on the OpenChain email alias, and adding those discussion topics to the above candidate agenda topics we have:

 

·         Training materials

·         Acceptance criteria and automation

·         Quality Standards (and how that connects to the process that generates content such as SPDX)

·         SPDX (probably good to discuss where SPDX ends and OpenChain begins)

·         ISO 19600

·         IPC 2570

 

Any additional proposed topics?  For the first two topics, we already have prepared materials.  For the third topic derived from the alias discussion, I hope to also cover in order to open the dialogue on quality standards as well as achievable goals. 

 

For the other topics (last three bullets) and any additional ones to be proposed, would much welcome a volunteer to lead an overview discussion. 

 

Kelly cc’d has offered to manage an ongoing list of agenda topics for us, and will also be helping with the roll call at the start.  If you have an agenda topic with materials that you would like to present during the call, please feel free to send those either to the alias or directly to Kelly, who will be helping us organize our topic pipeline.  She is also on the openchain@... alias.

 

Thanks,

Dave
Re: OpenChain -- Agenda Bashing for Tuesday 9/16

Joseph Potvin
 

David, I'm not sure of by "lead an overview discussion" you mean that someone would give a 5-min intro presentation.

If suitable I can explain the rationale for my recommendation to situate the OpenChain initiative as a sector-specific application (potentially with sector-specific extensions) of the emerging generic ISO 19600 guideline/standard on compliance management systems.

As I've not myself been involved in the development process of ISO 19600, possibly the most efficient use of limited time on a conf call if participants could, ahead of time, scan this 6-pg summary about its origins:
Author: Dick Hortensius, +31 15 2 690 115, e-mail: dick.hortensius@...

I think the practical suggestion I'll bring forward for discussion during the call is that the OpenChain community identify and resource formal liaison with the ISO's Project Committee (PC) that is working on development of ISO 19600, identified as ISO/PC 271 Compliance management systems.
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee.htm?commid=4395782

The ISO work is carried out via Technical Committees (TC), Subcommittees (SC) and Project Committees (PC). If the 19600 framework seems relevant to the team, a connection with the "training materials" part of the conf call is this ANSI 2013 Refresher Counse on "Changes to the ISO Directives":
http://www.standardslearn.org/Presentations/ISODirectivesUpdates2013/2013-ISO-Refresher-Course.pdf

And as mentioned earler, we've started maintaining links to useful learning resources on the topic of compliance management within the FLOW Syllabus (and any additional top recommendations to this collection will be most welcome):
http://wiki.opensource.org/bin/Projects/flow-syllabus#HManagementofResponsibility

-
Joseph Potvin, M.Phil. MCPM
Doctoral Candidate, Project Management
Département des sciences administratives
Université du Québec en Outaouais - UQO

Chair, OSI Management Education Working Group

The Open Source Initiative


Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983


On Fri, Sep 12, 2014 at 11:22 PM, Marr, David <dmarr@...> wrote:

Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST.

 

In our last meeting we discussed that training materials would be on the agenda for the next meeting.  Additionally, may I suggest the topic of acceptance criteria.  Yixiong from Qualcomm Technologies has offered to join the call and provide a suggestion on how OpenChain might consider handling acceptance criteria and ways to create consistency.

 

Based on a review of the discussion on the OpenChain email alias, and adding those discussion topics to the above candidate agenda topics we have:

 

·         Training materials

·         Acceptance criteria and automation

·         Quality Standards (and how that connects to the process that generates content such as SPDX)

·         SPDX (probably good to discuss where SPDX ends and OpenChain begins)

·         ISO 19600

·         IPC 2570

 

Any additional proposed topics?  For the first two topics, we already have prepared materials.  For the third topic derived from the alias discussion, I hope to also cover in order to open the dialogue on quality standards as well as achievable goals. 

 

For the other topics (last three bullets) and any additional ones to be proposed, would much welcome a volunteer to lead an overview discussion. 

 

Kelly cc’d has offered to manage an ongoing list of agenda topics for us, and will also be helping with the roll call at the start.  If you have an agenda topic with materials that you would like to present during the call, please feel free to send those either to the alias or directly to Kelly, who will be helping us organize our topic pipeline.  She is also on the openchain@... alias.

 

Thanks,

Dave


_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
Re: OpenChain -- Agenda Bashing for Tuesday 9/16

Dave Marr
 

Thanks Joseph, I think that would be great.  Will try to review the suggested ISO materials prior to the call.  BTW nice collection of general FOSS materials on that wiki page.

On Sep 13, 2014, at 6:13 AM, Joseph Potvin <jpotvin@...> wrote:

David, I'm not sure of by "lead an overview discussion" you mean that someone would give a 5-min intro presentation.

If suitable I can explain the rationale for my recommendation to situate the OpenChain initiative as a sector-specific application (potentially with sector-specific extensions) of the emerging generic ISO 19600 guideline/standard on compliance management systems.

As I've not myself been involved in the development process of ISO 19600, possibly the most efficient use of limited time on a conf call if participants could, ahead of time, scan this 6-pg summary about its origins:
Author: Dick Hortensius, +31 15 2 690 115, e-mail: dick.hortensius@...

I think the practical suggestion I'll bring forward for discussion during the call is that the OpenChain community identify and resource formal liaison with the ISO's Project Committee (PC) that is working on development of ISO 19600, identified as ISO/PC 271 Compliance management systems.
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee.htm?commid=4395782

The ISO work is carried out via Technical Committees (TC), Subcommittees (SC) and Project Committees (PC). If the 19600 framework seems relevant to the team, a connection with the "training materials" part of the conf call is this ANSI 2013 Refresher Counse on "Changes to the ISO Directives":
http://www.standardslearn.org/Presentations/ISODirectivesUpdates2013/2013-ISO-Refresher-Course.pdf

And as mentioned earler, we've started maintaining links to useful learning resources on the topic of compliance management within the FLOW Syllabus (and any additional top recommendations to this collection will be most welcome):
http://wiki.opensource.org/bin/Projects/flow-syllabus#HManagementofResponsibility

-
Joseph Potvin, M.Phil. MCPM
Doctoral Candidate, Project Management
Département des sciences administratives
Université du Québec en Outaouais - UQO

Chair, OSI Management Education Working Group

The Open Source Initiative


Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983


On Fri, Sep 12, 2014 at 11:22 PM, Marr, David <dmarr@...> wrote:

Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST.

 

In our last meeting we discussed that training materials would be on the agenda for the next meeting.  Additionally, may I suggest the topic of acceptance criteria.  Yixiong from Qualcomm Technologies has offered to join the call and provide a suggestion on how OpenChain might consider handling acceptance criteria and ways to create consistency.

 

Based on a review of the discussion on the OpenChain email alias, and adding those discussion topics to the above candidate agenda topics we have:

 

·         Training materials

·         Acceptance criteria and automation

·         Quality Standards (and how that connects to the process that generates content such as SPDX)

·         SPDX (probably good to discuss where SPDX ends and OpenChain begins)

·         ISO 19600

·         IPC 2570

 

Any additional proposed topics?  For the first two topics, we already have prepared materials.  For the third topic derived from the alias discussion, I hope to also cover in order to open the dialogue on quality standards as well as achievable goals. 

 

For the other topics (last three bullets) and any additional ones to be proposed, would much welcome a volunteer to lead an overview discussion. 

 

Kelly cc’d has offered to manage an ongoing list of agenda topics for us, and will also be helping with the roll call at the start.  If you have an agenda topic with materials that you would like to present during the call, please feel free to send those either to the alias or directly to Kelly, who will be helping us organize our topic pipeline.  She is also on the openchain@... alias.

 

Thanks,

Dave


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

Kelly Williams
 

Attached is the slide deck for tomorrow’s discussion. 

 

Phone bridge info:

Conference Number: +1 (415) 906-5657 Pin: 88326


UberConference URL: http://uberconference.com/mdolan

 

For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions:
http://www.uberconference.com/international/access

 

Screen share (if used): go to http://uberconference.com/mdolan

 

Regards,

Kelly

PDF
OpenChain_2014-09-16.pdf

Re: OpenChain -- Agenda Bashing for Tuesday 9/16

Joseph Potvin
 

RE: "Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST"

Very sorry -- I read the info incorrectly when I made my e-calendar note, and thus registered it as being at 3 PM EDT, which I see now was the UTC time.

Joseph Potvin




On Mon, Sep 15, 2014 at 9:49 PM, Williams, Kelly <kellyw@...> wrote:

Phone bridge info:

 

Conference Number: +1 (415) 906-5657

Pin: 88326

 

Looking forward to having you on the call tomorrow.

 

From: Joseph Potvin [mailto:jpotvin@...]
Sent: Monday, September 15, 2014 6:30 PM
To: Williams, Kelly
Subject: Re: [OpenChain] OpenChain -- Agenda Bashing for Tuesday 9/16

 

Is there 1-800 number I can call into?  I'll be downtown on my cell phone at that time.

Joseph

 

On Mon, Sep 15, 2014 at 9:21 PM, Williams, Kelly <kellyw@...> wrote:

Great!  I’ve scheduled you in for 10 mins on the ISO 19600 discussion.  I will send out the agenda shortly.

 

Thanks!

Kelly

 

 

On Mon, Sep 15, 2014 at 3:05 PM, Williams, Kelly <kellyw@...> wrote:

Hi Joseph,

 

I am working on the agenda for tomorrow’s OpenChain meeting and will add this to the agenda.  Will you be able to join the meeting tomorrow, 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST? 

 

If time runs out, would you be available to discuss at the next meeting on Tuesday, 10/7 at 8am PT, 11am ET, 3pm UTC, 5pm CEST?

 

Regards,

Kelly Williams

Project Analyst

Open Source Group

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Marr, David
Sent: Saturday, September 13, 2014 7:34 AM
To: Joseph Potvin
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain -- Agenda Bashing for Tuesday 9/16

 

Thanks Joseph, I think that would be great.  Will try to review the suggested ISO materials prior to the call.  BTW nice collection of general FOSS materials on that wiki page.

 

On Sep 13, 2014, at 6:13 AM, Joseph Potvin <jpotvin@...> wrote:

 

David, I'm not sure of by "lead an overview discussion" you mean that someone would give a 5-min intro presentation.

If suitable I can explain the rationale for my recommendation to situate the OpenChain initiative as a sector-specific application (potentially with sector-specific extensions) of the emerging generic ISO 19600 guideline/standard on compliance management systems.

 

As I've not myself been involved in the development process of ISO 19600, possibly the most efficient use of limited time on a conf call if participants could, ahead of time, scan this 6-pg summary about its origins:

Author: Dick Hortensius, +31 15 2 690 115, e-mail: dick.hortensius@...

 

I think the practical suggestion I'll bring forward for discussion during the call is that the OpenChain community identify and resource formal liaison with the ISO's Project Committee (PC) that is working on development of ISO 19600, identified as ISO/PC 271 Compliance management systems.
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee.htm?commid=4395782

The ISO work is carried out via Technical Committees (TC), Subcommittees (SC) and Project Committees (PC). If the 19600 framework seems relevant to the team, a connection with the "training materials" part of the conf call is this ANSI 2013 Refresher Counse on "Changes to the ISO Directives":
http://www.standardslearn.org/Presentations/ISODirectivesUpdates2013/2013-ISO-Refresher-Course.pdf

And as mentioned earler, we've started maintaining links to useful learning resources on the topic of compliance management within the FLOW Syllabus (and any additional top recommendations to this collection will be most welcome):

http://wiki.opensource.org/bin/Projects/flow-syllabus#HManagementofResponsibility

-
Joseph Potvin, M.Phil. MCPM
Doctoral Candidate, Project Management
Département des sciences administratives
Université du Québec en Outaouais - UQO

Chair, OSI Management Education Working Group

The Open Source Initiative


Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983

 

On Fri, Sep 12, 2014 at 11:22 PM, Marr, David <dmarr@...> wrote:

Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST.

 

In our last meeting we discussed that training materials would be on the agenda for the next meeting.  Additionally, may I suggest the topic of acceptance criteria.  Yixiong from Qualcomm Technologies has offered to join the call and provide a suggestion on how OpenChain might consider handling acceptance criteria and ways to create consistency.

 

Based on a review of the discussion on the OpenChain email alias, and adding those discussion topics to the above candidate agenda topics we have:

 

·         Training materials

·         Acceptance criteria and automation

·         Quality Standards (and how that connects to the process that generates content such as SPDX)

·         SPDX (probably good to discuss where SPDX ends and OpenChain begins)

·         ISO 19600

·         IPC 2570

 

Any additional proposed topics?  For the first two topics, we already have prepared materials.  For the third topic derived from the alias discussion, I hope to also cover in order to open the dialogue on quality standards as well as achievable goals. 

 

For the other topics (last three bullets) and any additional ones to be proposed, would much welcome a volunteer to lead an overview discussion. 

 

Kelly cc’d has offered to manage an ongoing list of agenda topics for us, and will also be helping with the roll call at the start.  If you have an agenda topic with materials that you would like to present during the call, please feel free to send those either to the alias or directly to Kelly, who will be helping us organize our topic pipeline.  She is also on the openchain@... alias.

 

Thanks,

Dave


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



 
Re: OpenChain -- Agenda Bashing for Tuesday 9/16

Kelly Williams
 

We can discuss ISO 19600 and continue discussion on Acceptance Criteria at our next meeting on 10/7.

 

Regards,

Kelly

 

From: Joseph Potvin [mailto:jpotvin@...]
Sent: Tuesday, September 16, 2014 12:21 PM
To: Williams, Kelly; openchain@...
Subject: Re: [OpenChain] OpenChain -- Agenda Bashing for Tuesday 9/16

 

RE: "Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST"

Very sorry -- I read the info incorrectly when I made my e-calendar note, and thus registered it as being at 3 PM EDT, which I see now was the UTC time.

Joseph Potvin



 

On Mon, Sep 15, 2014 at 9:49 PM, Williams, Kelly <kellyw@...> wrote:

Phone bridge info:

 

Conference Number: +1 (415) 906-5657

Pin: 88326

 

Looking forward to having you on the call tomorrow.

 

From: Joseph Potvin [mailto:jpotvin@...]
Sent: Monday, September 15, 2014 6:30 PM
To: Williams, Kelly
Subject: Re: [OpenChain] OpenChain -- Agenda Bashing for Tuesday 9/16

 

Is there 1-800 number I can call into?  I'll be downtown on my cell phone at that time.

Joseph

 

On Mon, Sep 15, 2014 at 9:21 PM, Williams, Kelly <kellyw@...> wrote:

Great!  I’ve scheduled you in for 10 mins on the ISO 19600 discussion.  I will send out the agenda shortly.

 

Thanks!

Kelly

 

 

On Mon, Sep 15, 2014 at 3:05 PM, Williams, Kelly <kellyw@...> wrote:

Hi Joseph,

 

I am working on the agenda for tomorrow’s OpenChain meeting and will add this to the agenda.  Will you be able to join the meeting tomorrow, 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST? 

 

If time runs out, would you be available to discuss at the next meeting on Tuesday, 10/7 at 8am PT, 11am ET, 3pm UTC, 5pm CEST?

 

Regards,

Kelly Williams

Project Analyst

Open Source Group

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Marr, David
Sent: Saturday, September 13, 2014 7:34 AM
To: Joseph Potvin
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain -- Agenda Bashing for Tuesday 9/16

 

Thanks Joseph, I think that would be great.  Will try to review the suggested ISO materials prior to the call.  BTW nice collection of general FOSS materials on that wiki page.

 

On Sep 13, 2014, at 6:13 AM, Joseph Potvin <jpotvin@...> wrote:

 

David, I'm not sure of by "lead an overview discussion" you mean that someone would give a 5-min intro presentation.

If suitable I can explain the rationale for my recommendation to situate the OpenChain initiative as a sector-specific application (potentially with sector-specific extensions) of the emerging generic ISO 19600 guideline/standard on compliance management systems.

 

As I've not myself been involved in the development process of ISO 19600, possibly the most efficient use of limited time on a conf call if participants could, ahead of time, scan this 6-pg summary about its origins:

Author: Dick Hortensius, +31 15 2 690 115, e-mail: dick.hortensius@...

 

I think the practical suggestion I'll bring forward for discussion during the call is that the OpenChain community identify and resource formal liaison with the ISO's Project Committee (PC) that is working on development of ISO 19600, identified as ISO/PC 271 Compliance management systems.
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee.htm?commid=4395782

The ISO work is carried out via Technical Committees (TC), Subcommittees (SC) and Project Committees (PC). If the 19600 framework seems relevant to the team, a connection with the "training materials" part of the conf call is this ANSI 2013 Refresher Counse on "Changes to the ISO Directives":
http://www.standardslearn.org/Presentations/ISODirectivesUpdates2013/2013-ISO-Refresher-Course.pdf

And as mentioned earler, we've started maintaining links to useful learning resources on the topic of compliance management within the FLOW Syllabus (and any additional top recommendations to this collection will be most welcome):

http://wiki.opensource.org/bin/Projects/flow-syllabus#HManagementofResponsibility

-
Joseph Potvin, M.Phil. MCPM
Doctoral Candidate, Project Management
Département des sciences administratives
Université du Québec en Outaouais - UQO

Chair, OSI Management Education Working Group

The Open Source Initiative


Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983

 

On Fri, Sep 12, 2014 at 11:22 PM, Marr, David <dmarr@...> wrote:

Hi, our next meeting is on Tuesday 9/16 at 8am PT, 11am ET, 3pm UTC, 5pm CEST.

 

In our last meeting we discussed that training materials would be on the agenda for the next meeting.  Additionally, may I suggest the topic of acceptance criteria.  Yixiong from Qualcomm Technologies has offered to join the call and provide a suggestion on how OpenChain might consider handling acceptance criteria and ways to create consistency.

 

Based on a review of the discussion on the OpenChain email alias, and adding those discussion topics to the above candidate agenda topics we have:

 

·         Training materials

·         Acceptance criteria and automation

·         Quality Standards (and how that connects to the process that generates content such as SPDX)

·         SPDX (probably good to discuss where SPDX ends and OpenChain begins)

·         ISO 19600

·         IPC 2570

 

Any additional proposed topics?  For the first two topics, we already have prepared materials.  For the third topic derived from the alias discussion, I hope to also cover in order to open the dialogue on quality standards as well as achievable goals. 

 

For the other topics (last three bullets) and any additional ones to be proposed, would much welcome a volunteer to lead an overview discussion. 

 

Kelly cc’d has offered to manage an ongoing list of agenda topics for us, and will also be helping with the roll call at the start.  If you have an agenda topic with materials that you would like to present during the call, please feel free to send those either to the alias or directly to Kelly, who will be helping us organize our topic pipeline.  She is also on the openchain@... alias.

 

Thanks,

Dave


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



 

 
How Medieval-Style Guilds Will Remake the Tech Behind Facebook and Google | WIRED

Mark Radcliffe
 

More about the Facebook/Google initiative: http://www.wired.com/2014/09/medieval-style-guilds-will-remake-tech-behind-facebook-google/
Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.
Re: How Medieval-Style Guilds Will Remake the Tech Behind Facebook and Google | WIRED

Kelly Williams
 

Thanks, Mark. I will add this to the agenda.

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Radcliffe, Mark
Sent: Wednesday, September 17, 2014 3:02 PM
To: openchain@...
Subject: [OpenChain] How Medieval-Style Guilds Will Remake the Tech Behind Facebook and Google | WIRED

More about the Facebook/Google initiative: http://www.wired.com/2014/09/medieval-style-guilds-will-remake-tech-behind-facebook-google/
Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
OpenChain - Next meeting Tuesday 10/7

Kelly Williams
 

Hi Everyone,

 

Reminder our next meeting will be Tuesday, October 7th at 8am PT, 11am ET, 3pm UTC, 5pm CEST.

 

Topics for 10/7

·         Continue discussion on acceptance criteria (Yixiong Zou)

·         TODO project (Mark Radcliffe)

·         ISO 19600 (Joseph Potvin)

 

Additional discussion topics:

·         Training materials

·         Quality Standards (and how that connects to the process that generates content such as SPDX)

·         SPDX (probably good to discuss where SPDX ends and OpenChain begins)

·         IPC 2570

Please send me any additional proposed topics.

Thanks,

Kelly

 

 

 

 

 

 

 
OpenChain call on 10/21

Kelly Williams
 

Hi,

 

We would like to accommodate a guest speaker on Tues, 10/21.  Would it be okay for folks if we move the meeting to 9am PT, 12pm ET, 4pm UTC, 6pm CEST?

 

Thanks,

Kelly
Re: OpenChain call on 10/21

Mark Radcliffe
 

I have a conflict at 9 am.

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, October 03, 2014 2:07 PM
To: openchain@...
Subject: [OpenChain] OpenChain call on 10/21

 

Hi,

 

We would like to accommodate a guest speaker on Tues, 10/21.  Would it be okay for folks if we move the meeting to 9am PT, 12pm ET, 4pm UTC, 6pm CEST?

 

Thanks,

Kelly

Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.

21 - 40 of 5145