OpenChain meeting 11/21


Kelly Williams
 

Hi Everyone,
 
Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 
Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
Regards,
Kelly
 
 


Kelly Williams
 

Please find attached the slides for today’s call. 
 
_____________________________________________
From: Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: OpenChain meeting 11/21
 
 
Hi Everyone,
 
Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 
Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
Regards,
Kelly
 
 


Jeremiah Foster <jeremiah.foster@...>
 

Hi Kelly,

I send my apologies for missing the call today. It was on my calendar but came at my daughters bed time which is sacrosanct. :-) I will read the slides you sent.

I very much look forward to the next call.

Regards,

Jeremiah


On Mon, 21 Nov 2016 at 19:45 Williams, Kelly <kellyw@...> wrote:
Please find attached the slides for today’s call. 
 
_____________________________________________
From: Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: OpenChain meeting 11/21
 
 
Hi Everyone,
 
Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 
Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
Regards,
Kelly
 
 
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Kelly Williams
 

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.

 

Let me know if I missed anything or if you have any questions.

 

Thanks!

Kelly

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21

 

Hi Everyone,

 

Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 

Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011
No PIN needed

If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.

1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.

 

Regards,

Kelly

 

 


Steve Cropper
 

Kelly, Mark, Kate et al:

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

1. Open Chain Concept

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:
  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

2. Proprietary Licensed Works

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

5. The Timing of FOSS reviews and managing FOSS in M&A

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

6. FOSS and hardware 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

7. Scoping the program to US Law

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

Cheers
Steve

Google Search: OpenChain ——>

Openchain - Blockchain technology for the enterprise

https://www.openchain.org/
Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain
Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service
Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...
You visited this page on 11/22/16.


On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.
 
Let me know if I missed anything or if you have any questions.
 
Thanks!
Kelly
 
 
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21
 
Hi Everyone,
 
Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 
Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
Regards,
Kelly
 
 
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Mark Gisi
 

Hi Steve,

 

Good to hear from you again. You cover a lot ground in your comments below which reflects a lot experience working with the supply chain. Experience from which OpenChain working groups could benefit from as the spec evolves. One challenge we face is that we want OpenChain to appeal to both small and large organizations. The reality is that many companies do not have all current core requirements implemented. The best way to view the current spec is as a minimum set of requirements one would expect a quality compliance program to satisfy. The intent is to incrementally add other “must have” requirements overtime.

 

>> 2. Proprietary Licensed Works ... AND the implications of Open Source arriving inside/alongside

>>Proprietary Licensed works.

 

I agree that the spec does not address the frequent occurrence for which composite licensing (the mixture of open source and proprietary software)  is typically found in the supply chain. This is an example of a topic that I believe in due time will be addressed by the spec training requirement and supporting materials. There was a brief discussion at the last meeting to include conjunctive and disjunctive licensing concepts in the IP training but it did not have sufficient support. For now I take comfort that composite licensing is supported in the SPDX spec.

 

>> 3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment… My

>> recommendation is that the curriculum documentation addresses Agility and DevOps

>> and tackles the need for pre-approval to use software before it gets into the development flow.

 

You are recommending a how/when action vs. a what/why requirement. The spec was designed to address the latter.  Although it is in the OpenChain charter to offer best practices overtime, it is not in the spec’s charter. So it is conceivable that the OpenChain project could potentially publish a document emphasizing the practice you have identified (or perhaps you might). However, the OpenChain spec is a set of requirements which provides lots of flexibility on how an organization implements them. There is no requirement that prevents one from implementing the practice you proposed.

 

>> 4. The timing of FOSS reviews and managing FOSS in Commercially licensed

>> Proprietary Software/ Hardware… If a Supplier is Open Chain certified

>> (not a concept that I have seen in the material) vs. Open Chain compliant

>> (what I understand the current Open Chain model to be since it has a

>> ‘self-certifying’ model) then the contract terms can be simplified and

>> Suppliers can optimise their ability to comply with Customer compliance obligations.

 

The ability for an organization to achieve spec conformance is one of the core objectives of  the OpenChain project. Currently we are supporting ‘self-certifying’ with the ability for one’s customer or partner to audit that claim. The audit should be straight forward in that the spec spells out what one is required to maintain as evidence. The OpenChain project has left the door wide open to permit third party certifications. It was felt that self-certification supported by customer audits should initially lower the barrier to adoption yet still provide the required credibility. Third party certification makes sense once a certain traction threshold has been achieved.

 

>> 5. The Timing of FOSS reviews and managing FOSS in M&A…While

>>  OpenChain may not need a formal section here it is probably worth

>> mentioning in Compliance Curriculum and process creation.

 

I agree in that the spec should not have a formal section on this topic but it represents another good example of where the Project could publish a best practice process (a how/when matter).

 

>> 6. FOSS and hardware 

 

We are considering organizing the spec to handle other “optional”  open source program related matters such as export licensing and security vulnerabilities. Open Hardware presents another opportunity for expansion.

 

>> Perhaps the Curriculum FAQ needs a question following the USLaw one that

>> answers “Why is the Curriculum/Specification US Centric"?

 

That is a good suggestion to be considered by the Curriculum working group

 

>> I think should be a consideration and that is the name of the program: OpenChain

>> is not a good brand

 

This is a worthy topic for the project’s Governing Board to consider.

 

Thank you Steve for the insightful feedback. We look forward to your participation.

 

cheers,

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Steve Cropper
Sent: Wednesday, November 23, 2016 3:15 AM
To: Williams, Kelly
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain meeting 11/21

 

Kelly, Mark, Kate et al:

 

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

 

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

 

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

 

1. Open Chain Concept

 

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

 

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:

  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

 

2. Proprietary Licensed Works

 

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

 

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

 

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

 

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

 

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

 

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

 

5. The Timing of FOSS reviews and managing FOSS in M&A

 

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

 

6. FOSS and hardware 

 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

 

7. Scoping the program to US Law

 

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

 

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

 

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

 

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

 

Cheers

Steve

 

Google Search: OpenChain ——>

 

Openchain - Blockchain technology for the enterprise

https://www.openchain.org/

1.      

2.      

Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://github.com/openchain

1.      

2.      

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain

1.      

2.      

Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service

1.      

2.      

Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

https://wiki.linuxfoundation.org/openchain/start

1.      

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...

You visited this page on 11/22/16.

 

 

On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

 

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.

 

Let me know if I missed anything or if you have any questions.

 

Thanks!

Kelly

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21

 

Hi Everyone,

 

Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 

Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed

If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.

1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.

 

Regards,

Kelly

 

 

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

 


Gary O'Neall
 

Hi Steve and all,

 

I agree with your comment #3 below.  The topic of Agile development and open source compliance is a topic I am also quite interested in.  I agree there more work we can do on this topic to share best practices to help adoption of open source compliance within an Agile engineering organization.  I’m thinking that the next revision of the training materials could include some of this information.  It may also be a good topic for a best practices style document.  Let me know if there is interest and if anyone would like to collaborate on this.

 

Thanks,
Gary

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Steve Cropper
Sent: Wednesday, November 23, 2016 3:15 AM
To: Williams, Kelly
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain meeting 11/21

 

Kelly, Mark, Kate et al:

 

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

 

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

 

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

 

1. Open Chain Concept

 

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

 

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:

  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

 

2. Proprietary Licensed Works

 

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

 

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

 

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

 

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

 

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

 

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

 

5. The Timing of FOSS reviews and managing FOSS in M&A

 

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

 

6. FOSS and hardware 

 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

 

7. Scoping the program to US Law

 

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

 

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

 

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

 

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

 

Cheers

Steve

 

Google Search: OpenChain ——>

 

Openchain - Blockchain technology for the enterprise

https://www.openchain.org/

1.      

2.      

Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://github.com/openchain

1.      

2.      

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain

1.      

2.      

Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service

1.      

2.      

Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

https://wiki.linuxfoundation.org/openchain/start

1.      

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...

You visited this page on 11/22/16.

 

 

On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

 

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.

 

Let me know if I missed anything or if you have any questions.

 

Thanks!

Kelly

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21

 

Hi Everyone,

 

Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 

Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed

If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.

1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.

 

Regards,

Kelly

 

 

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

 


Jeremiah Foster <jeremiah.foster@...>
 



On Fri, Dec 2, 2016 at 1:03 PM, <gary@...> wrote:

Hi Steve and all,

 

I agree with your comment #3 below.  The topic of Agile development and open source compliance is a topic I am also quite interested in.  I agree there more work we can do on this topic to share best practices to help adoption of open source compliance within an Agile engineering organization.  I’m thinking that the next revision of the training materials could include some of this information.  It may also be a good topic for a best practices style document.  Let me know if there is interest and if anyone would like to collaborate on this.


​IMHO having a compliance process that takes into consideration the development process and agile is smart. The two need to work well together especially since in many software development engineers are responsible for both. Google has a term for this type of person; engi-lawyer. I think OpenChain can help this person a lot, not least by educating their managers on compliance. If that can fit in with the agile process, which is what most software development now uses, even automotive, that will bring faster time to market and cost savings I believe.

Cheers,

Jeremiah

 

Thanks,
Gary

 

From: openchain-bounces@...oundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Steve Cropper
Sent: Wednesday, November 23, 2016 3:15 AM
To: Williams, Kelly
Cc: openchain@...n.org
Subject: Re: [OpenChain] OpenChain meeting 11/21

 

Kelly, Mark, Kate et al:

 

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

 

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

 

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

 

1. Open Chain Concept

 

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

 

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:

  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

 

2. Proprietary Licensed Works

 

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

 

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

 

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

 

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

 

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

 

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

 

5. The Timing of FOSS reviews and managing FOSS in M&A

 

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

 

6. FOSS and hardware 

 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

 

7. Scoping the program to US Law

 

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

 

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

 

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

 

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

 

Cheers

Steve

 

Google Search: OpenChain ——>

 

https://www.openchain.org/

1.      

2.      

Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://github.com/openchain

1.      

2.      

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain

1.      

2.      

Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service

1.      

2.      

Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

https://wiki.linuxfoundation.org/openchain/start

1.      

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...

You visited this page on 11/22/16.

 

 

On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

 

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.

 

Let me know if I missed anything or if you have any questions.

 

Thanks!

Kelly

 

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...ation.org
Subject: [OpenChain] OpenChain meeting 11/21

 

Hi Everyone,

 

Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 

Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed

If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.

1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.

 

Regards,

Kelly

 

 

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

 


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




--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden


Steve Cropper
 

Hi Mark, Gary, Jeremiah, et al:

Thanks for the feedback and thoughts. 

I will try to join your next call and initially be a fly on the wall so I can get the lie of the land. I would be happy to collaborate in pushing this forward anyway I can.

I think that it is important to not only deliver an outline in the form of the Specification but it was good to see a curriculum helping create a template to implement the spec.

This template I also agree with the notion of starting with a K.I.S.S. approach but I also think adding a touch of agility might be worth while. Look for ways to tackle objections and push back head on and fix them, develop a marketing and roll out plan that hopefully becomes more acceptable to your target audience and drives success.

Cheers.
Steve 


On 2 Dec 2016, at 20:15, Jeremiah Foster <jeremiah.foster@...> wrote:



On Fri, Dec 2, 2016 at 1:03 PM,  <gary@...> wrote:

Hi Steve and all,

 

I agree with your comment #3 below.  The topic of Agile development and open source compliance is a topic I am also quite interested in.  I agree there more work we can do on this topic to share best practices to help adoption of open source compliance within an Agile engineering organization.  I’m thinking that the next revision of the training materials could include some of this information.  It may also be a good topic for a best practices style document.  Let me know if there is interest and if anyone would like to collaborate on this.


​IMHO having a compliance process that takes into consideration the development process and agile is smart. The two need to work well together especially since in many software development engineers are responsible for both. Google has a term for this type of person; engi-lawyer. I think OpenChain can help this person a lot, not least by educating their managers on compliance. If that can fit in with the agile process, which is what most software development now uses, even automotive, that will bring faster time to market and cost savings I believe.

Cheers,

Jeremiah

 

Thanks,
Gary 

 

From: openchain-bounces@...oundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Steve Cropper
Sent: Wednesday, November 23, 2016 3:15 AM
To: Williams, Kelly
Cc: openchain@...n.org
Subject: Re: [OpenChain] OpenChain meeting 11/21

 

Kelly, Mark, Kate et al:

 

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

 

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

 

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

 

1. Open Chain Concept

 

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

 

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:

  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

 

2. Proprietary Licensed Works

 

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

 

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

 

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

 

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

 

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

 

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

 

5. The Timing of FOSS reviews and managing FOSS in M&A

 

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

 

6. FOSS and hardware 

 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

 

7. Scoping the program to US Law

 

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

 

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

 

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

 

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

 

Cheers

Steve

 

Google Search: OpenChain ——>

 

https://www.openchain.org/

1.      

2.      

Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://github.com/openchain

1.      

2.      

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain

1.      

2.      

Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service

1.      

2.      

Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

https://wiki.linuxfoundation.org/openchain/start

1.      

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...

You visited this page on 11/22/16.

 

 

On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

 

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.

 

Let me know if I missed anything or if you have any questions.

 

Thanks!

Kelly

 

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...ation.org
Subject: [OpenChain] OpenChain meeting 11/21

 

Hi Everyone,

 

Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 

Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed

If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.

1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.

 

Regards,

Kelly

 

 

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

 


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




-- 
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 
Gothenburg, Sweden
<PELAGICORE_RGB_Black_horizontal.png>


Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

Steve!

So great to hear from you again and I do hope you will participate and lend your wealth of experience here!

Apologies for the slow response (to this email and others), as I’ve been stuck under a few heavy objects, but now I can conveniently hop on the coattails of the excellent responses from Gary, Mark, and Jeremiah now :)

As to your comment:

7. Scoping the program to US Law

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

The curriculum started out (and still currently is) more generalized as to the concepts in the first section on IP law.  We discussed this approach v. having a starting point jurisdiction at the F2F meeting in Berlin, which I raised as I was afraid that some of the IP law concepts had gotten too generalized to the point of potentially being warped and representing “no jurisdiction”.  It was my suggestion to provide a starting point as US law and just state this, with the hope that we could then get attorneys familiar with other jurisdictions to either add a similar section for their jurisdiction or a comparative analysis using the US as a starting point. In the best case scenario, over time, people could choose to use all, some, or just one jurisdiction as they see fit. 

The decision was to go with this idea and I tasked myself with revising the slides to have them squarely reflect the US law perspective – at least this way, it’s clear. I am vastly behind in my delivery here… :(  (but I will have time shortly to come through, Shane, I promise!!)

In any case, glad to have you!

Cheers,
Jilayne


From: <openchain-bounces@...> on behalf of Steve Cropper <stcroppe@...>
Date: Wednesday, November 23, 2016 at 11:15 AM
To: Kelly Williams <kellyw@...>
Cc: "openchain@..." <openchain@...>
Subject: Re: [OpenChain] OpenChain meeting 11/21

Kelly, Mark, Kate et al:

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

1. Open Chain Concept

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:
  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

2. Proprietary Licensed Works

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

5. The Timing of FOSS reviews and managing FOSS in M&A

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

6. FOSS and hardware 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

7. Scoping the program to US Law

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

Cheers
Steve

Google Search: OpenChain ——>

Openchain - Blockchain technology for the enterprise

https://www.openchain.org/
Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain
Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service
Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...
You visited this page on 11/22/16.


On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.
 
Let me know if I missed anything or if you have any questions.
 
Thanks!
Kelly
 
 
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21
 
Hi Everyone,
 
Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 
Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
Regards,
Kelly
 
 
_______________________________________________
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.


Steve Cropper
 

Hi Jilayne!

Thanks for your comprehensive feedback on my notes.

Now I just have to figure out how to join calls that start at 2am for me ;-).

In the meantime I will monitor the mailer. I may be in CA for a couple of weeks in January so will try to be on the call then.

If there are any Euro centric render-vous or calls - happy to join in.

Steve

On 5 Dec 2016, at 22:43, Jilayne Lovejoy <Jilayne.Lovejoy@...> wrote:

Steve!

So great to hear from you again and I do hope you will participate and lend your wealth of experience here!

Apologies for the slow response (to this email and others), as I’ve been stuck under a few heavy objects, but now I can conveniently hop on the coattails of the excellent responses from Gary, Mark, and Jeremiah now :)

As to your comment:

7. Scoping the program to US Law

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

The curriculum started out (and still currently is) more generalized as to the concepts in the first section on IP law.  We discussed this approach v. having a starting point jurisdiction at the F2F meeting in Berlin, which I raised as I was afraid that some of the IP law concepts had gotten too generalized to the point of potentially being warped and representing “no jurisdiction”.  It was my suggestion to provide a starting point as US law and just state this, with the hope that we could then get attorneys familiar with other jurisdictions to either add a similar section for their jurisdiction or a comparative analysis using the US as a starting point. In the best case scenario, over time, people could choose to use all, some, or just one jurisdiction as they see fit. 

The decision was to go with this idea and I tasked myself with revising the slides to have them squarely reflect the US law perspective – at least this way, it’s clear. I am vastly behind in my delivery here… :(  (but I will have time shortly to come through, Shane, I promise!!)

In any case, glad to have you!

Cheers,
Jilayne


From: <openchain-bounces@...> on behalf of Steve Cropper <stcroppe@...>
Date: Wednesday, November 23, 2016 at 11:15 AM
To: Kelly Williams <kellyw@...>
Cc: "openchain@..." <openchain@...>
Subject: Re: [OpenChain] OpenChain meeting 11/21

Kelly, Mark, Kate et al:

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

1. Open Chain Concept

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:
  1. ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.
  2. Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

2. Proprietary Licensed Works

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

5. The Timing of FOSS reviews and managing FOSS in M&A

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

6. FOSS and hardware 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

7. Scoping the program to US Law

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

Cheers
Steve

Google Search: OpenChain ——>

Openchain - Blockchain technology for the enterprise

https://www.openchain.org/
Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain
Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service
Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...
You visited this page on 11/22/16.


On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.
 
Let me know if I missed anything or if you have any questions.
 
Thanks!
Kelly
 
 
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21
 
Hi Everyone,
 
Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 
Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed
If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.
 
Regards,
Kelly
 
 
_______________________________________________
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.


Miriam Ballhausen <Miriam.Ballhausen@...>
 

Hi Steve,

 

there’s a call at 6 p.m. CET the first Monday of each month. That might work for you. It’d be great, if you joined.

 

Kind regards,

Miriam

 

Dr. Miriam Ballhausen

Legal Counsel

 

Telefon: +49 30 200 566 205

Mobil: +49 173 38 567 56
miriam.ballhausen@...

 

 

Alte Jakobstraße 85/86,
10179 Berlin
Deutschland

Telefonzentrale +49 30 200 566 0 Fax +49 30 200 566 1 


www.lumesse.de

 

 

Lumesse

 

 

Lumesse GmbH,
Sitz der Gesellschaft: Flughafenstraße 103, 40474 Düsseldorf
Amtsgericht Düsseldorf, HRB 40857
Geschäftsführer: Dr. Carsten Busch, Michael Hunt.

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Steve Cropper
Sent: Donnerstag, 8. Dezember 2016 18:58
To: Jilayne Lovejoy <Jilayne.Lovejoy@...>
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain meeting 11/21

 

Hi Jilayne!

 

Thanks for your comprehensive feedback on my notes.

 

Now I just have to figure out how to join calls that start at 2am for me ;-).

 

In the meantime I will monitor the mailer. I may be in CA for a couple of weeks in January so will try to be on the call then.

 

If there are any Euro centric render-vous or calls - happy to join in.

 

Steve

 

On 5 Dec 2016, at 22:43, Jilayne Lovejoy <Jilayne.Lovejoy@...> wrote:

 

Steve!

 

So great to hear from you again and I do hope you will participate and lend your wealth of experience here!

 

Apologies for the slow response (to this email and others), as I’ve been stuck under a few heavy objects, but now I can conveniently hop on the coattails of the excellent responses from Gary, Mark, and Jeremiah now :)

 

As to your comment:

 

7. Scoping the program to US Law

 

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

 

The curriculum started out (and still currently is) more generalized as to the concepts in the first section on IP law.  We discussed this approach v. having a starting point jurisdiction at the F2F meeting in Berlin, which I raised as I was afraid that some of the IP law concepts had gotten too generalized to the point of potentially being warped and representing “no jurisdiction”.  It was my suggestion to provide a starting point as US law and just state this, with the hope that we could then get attorneys familiar with other jurisdictions to either add a similar section for their jurisdiction or a comparative analysis using the US as a starting point. In the best case scenario, over time, people could choose to use all, some, or just one jurisdiction as they see fit. 

 

The decision was to go with this idea and I tasked myself with revising the slides to have them squarely reflect the US law perspective – at least this way, it’s clear. I am vastly behind in my delivery here… :(  (but I will have time shortly to come through, Shane, I promise!!)

 

In any case, glad to have you!

 

Cheers,

Jilayne

 

 

From: <openchain-bounces@...> on behalf of Steve Cropper <stcroppe@...>
Date: Wednesday, November 23, 2016 at 11:15 AM
To: Kelly Williams <kellyw@...>
Cc: "openchain@..." <openchain@...>
Subject: Re: [OpenChain] OpenChain meeting 11/21

 

Kelly, Mark, Kate et al:

 

Long time since I have delved into the Open Source Spec development and working with some of you on SPDX.

 

I bumped into Jim Zemler at Web Summit in Lisbon and he suggested that I take a look at the work that you are doing here. So I have joined the mailing list and studied the work product so far.

 

Here are some of my thoughts and if you are OK with an Independent joining the calls I am happy to do so.

 

1. Open Chain Concept

 

I think that there is a lot of value in creating background info on the “Supply Chain” in general and include Hardware (you’ll see why in a moment).

 

Why would I suggest this? Well while I was working at Cisco it became evident that, while everyone was trained on FOSS (at times much more deeply than the Open Chain Spec calls for) they were not very clear on how the SupplyChain works and importantly how software is sourced, combined, merged throughout the Supply Chain AND the implications of Open Source arriving inside/along side Proprietary Licensed works. In some cases Engineering leaders and most engineers assumed that they didn’t have to worry about Open Source arriving in Proprietary Software and we had to train them on this. Importantly we also had to make sure that the Business Teams and Legal teams (some of whom were not knowledgeable about Software and Open Source) made a point of addressing Open Source content used in Proprietary software. I can think of at least two dangerous routes into the organization:

1.     ODM Outsourced Products (which was the foundation of Cisco’s legal issues following the acquisition of Linksys). Cisco had to implement a comprehensive training program and contractual model with all outsourced suppliers to ensure that Open Source was accounted for and documented through into the supply chain.

2.     Utility Software Libraries and Tools downloaded in binary form from foreign web sites (often in Asia). Some tools required a base library that a compiler might require for some specialist application. Since these were “Free” binary products often made available without source code and without any obvious license or agreement. We had to train engineers that they could not use this software unless they could contact the company/individual and get a full list of ingredient software. I led an effort at one point to evaluate binary scanning software to try to determine open source content in such code but as you are all well aware there is no fool proof mechanism to discover FOSS in binary images.

 

2. Proprietary Licensed Works

 

As mentioned above. It is very easy for business leaders and program managers to jump to the conclusion that Proprietary Licenses cover them for any Open Source compliance issues and that they can push back to the Supplier as being culpable if an Open Source violation occurs. Cisco learned that you can’t do this the hard way! I think it is important (per my comments above) that more guidance is provided in the Curriculum documentation in this area. I would argue that this is one of the weakest area of FOSS compliance analysis.

 

3. Timing of FOSS reviews and managing FOSS in an Agile / DevOps engineering environment.

 

These days development teams move very quickly and do not like being slowed down by “bureaucracy”. They want software now and often will not want to wait for assessments and approvals before grabbing software and using it. However, perhaps the worse place to apply any “bureaucracy” is at code release and the run up to a production run. My recommendation is that the curriculum documentation addresses Agility and DevOps and tackles the need for pre-approval to use software before it gets into the development flow. Better to implement legal oversight before the product is baked than at pre-release! More over one of the aspects of Cisco’s compliance program that was very important was the idea of having pre-approved OpenSource components. These were mostly components with benign licenses or widely used GPL (e.g. v2) where the company had good compliance programs in place or prior experience with compliance. Engineers were trained to look internally for this information before going outside to download software components.

 

4. The timing of FOSS reviews and managing FOSS in Commercially licensed Proprietary Software/ Hardware

 

Whether dealing with an ODM or engaging in a direct OEM relationship with a third party it is important that FOSS factors into the software elements of any deal. We had to build contractual language into hardware (think BSPs, driver libraries etc) and software agreements that obligated the supplier into maintaining Open Source compliance processes that met minimum standards and provided Cisco with appropriate notices of addition or modification of Open Source components and supplier audits to ensure that they were meeting these obligations. This is perhaps THE MAIN area where Open Chain can have a positive impact. If a Supplier is Open Chain certified (not a concept that I have seen in the material) vs. Open Chain compliant (what I understand the current Open Chain model to be since it has a ‘self-certifying’ model) then the contract terms can be simplified and Suppliers can optimise their ability to comply with Customer compliance obligations.

 

Often deals with hardware suppliers and ODMs are done with non-software skilled employees. These are performed by commodity managers and legal teams with a completely different mind set and often software provided with hardware is overlooked.

 

5. The Timing of FOSS reviews and managing FOSS in M&A

 

Most sophisticated Fortune 500 companies are well versed in the need for FOSS scanning and reviews as part of the due diligence process in the Acquisition process. Acquisition can often be part of the Supply chain process and is being practised more and more by smaller companies and some startups with decent VC funding. While OpenChain may not need a formal section here it is probably worth mentioning in Compliance Curriculum and process creation.

 

6. FOSS and hardware 

 

Now days with the advent of maker boards like RaspberryPi and MinnowBoard there is additional Open Source licensing being applied to design documents and board schematics and some chip designs etc. FOSS is no longer a Software only domain. It is completely possible that some start ups are taking advantage of these community projects and deriving new hardware designs from these projects. The hardware engineering and Supply Chain procurement organisations are the next frontier for FOSS and it would be a great idea to add Hardware into this project. :-)

 

7. Scoping the program to US Law

 

Again, I understand that you need to start somewhere. I would be interested in Jilayne’s perspective here. As an employee of ARM (now/soon to be Softbank) I imagine that she deals with many non-US licenses and sources of open source. The UK, Eastern Europe and Israel are all big sources of Open Source programs and contribution (most BlockChain work for example I believe is largely UK driven). Also many of the companies that you will want to adopt Open Chain are multi nationals and, at least commercially, have a growing number of agreements with non-US companies and not all of them are adjudicated in US jurisdictions. Also the EU (as we all know) has its own way of looking at copyright etc. which multi-nationals cannot avoid and whose compliance programs should accommodate out of the gate.

 

Perhaps the Curriculum FAQ needs a question following the USLaw one that answers “Why is the Curriculum/Specification US Centric"?

 

I am sure I will come up with other thoughts but in summary looks like there is some good work here and I am interested to learn more.

 

Final thought which I think should be a consideration and that is the name of the program: OpenChain is not a good brand and really doesn’t describe the program effectively. I searched for OpenChain in google and got the following result. This program came up in the number 5 position and was surrounded by BlockChain results. I would propose changing the name/branding to something more obvious like OpenSupplyChain, CommunitySupplyChain? A good brand will aid in adoption!

 

Cheers

Steve

 

Google Search: OpenChain ——>

 

Openchain - Blockchain technology for the enterprise

https://www.openchain.org/

1.     

2.     

Openchain is an open source, enterprise-ready Blockchain technology platform.

Openchain · GitHub

https://github.com/openchain

1.     

2.     

https://www.openchain.org/ · Repositories ... Docker deployment for Openchain. C# 11 11 ... JavaScript Openchain client library for Node.js and the browser.

GitHub - openchain/openchain: Openchain node reference ...

https://github.com/openchain/openchain

1.     

2.     

Openchain node reference implementation. Contribute to openchain development by creating an account on GitHub.

Openchain: Enterprise-Ready Blockchain Technology - Bitcoin News

https://news.bitcoin.com › Bitcoin Service

1.     

2.     

Oct 20, 2015 - SAN MATEO, Ca. — Coinprism has released an enterprise-ready blockchain technology called “Openchain.” In contrast to Bitcoin, the service ...

openchain:start [Linux Foundation Wiki]

https://wiki.linuxfoundation.org/openchain/start

1.     

Nov 3, 2016 - The OpenChain Project focuses on identifying common best practices in compliance programs that should be applied across a supply chain for ...

You visited this page on 11/22/16.

 

 

On 23 Nov 2016, at 01:47, Williams, Kelly <kellyw@...> wrote:

 

The minutes are posted on the wiki https://wiki.linuxfoundation.org/openchain/minutes.

 

Let me know if I missed anything or if you have any questions.

 

Thanks!

Kelly

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Friday, November 18, 2016 2:36 PM
To: openchain@...
Subject: [OpenChain] OpenChain meeting 11/21

 

Hi Everyone,

 

Reminder the focus on the upcoming call on Mon, 11/21 at 5pm PST will be on the Specification and Curriculum. 

Join the call: https://www.uberconference.com/kellyw (Note – audio only works with Chrome)
Optional dial in number: 855-889-3011 
No PIN needed

If you need to use a local phone number, please consult:
https://www.uberconference.com/international for the specific country numbers.

1. Dial the local number based on your location.
2. Enter 855 889 3011, then #.

 

Regards,

Kelly

 

 

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