Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)


Miriam Ballhausen
 

Hi All,

thanks for comments. They are very helpful.

We’ve discussed a couple of times whether we wanted to ask organizations to provide artifacts and I have had a couple of discussions about this offline. The consensus so far was that we would not ask for them (at least not now), but rather rely on the market and complaints. If a complaint was raised, we would look further into the company and potentially ask for the artifacts. I am happy to put this discussion back on the agenda though. 

For the time being, would it be sufficient to clarify or explain in more detail:
a) that you can raise complaints, if you have concerns that someone who is claiming to be OpenChain compliant is indeed not, and
b) that you need to have documentation, especially artifacts available and need to provide them in case of a complaint?

Kind regards,
Miriam

-- 
Rechtsanwältin Dr. Miriam Ballhausen
Software Compliance Academy

Mobile: +49 151 270 67 650
www.scompliance.com





Am 09.08.2017 um 00:50 schrieb Foster, Jeremiah <JFoster@...>:

On Tue, 2017-08-08 at 15:22 -0400, John Scott wrote:
Blockchain doesn’t really get you anything since the software components are always changing, js

If one is doing continuous integration and continuous delivery, yes, the components are changing. Still, even with typical CI/CD, there are often releases that are frozen and distributed. Here the blockchain is quite useful. For example, releases can be defined into manifests, as we do here: https://github.com/Pelagicore/pelux-manifests/blob/master/pelux-base.xml. Then you can use a manifest, along with other artifacts to create a release, like GENIVI does here: https://github.com/GENIVI/genivi-dev-platform/releases. Those releases are ideal candidates for a blockchain since they are frozen and their contents don't vary a great deal. Yes, often there are point releases, but those benefit from the same blockchain. 

Putting software releases, and the release manifests, on a blockchain would be help determining provenance. For example, one can envision a scenario where a typical FOSS product would begin with a vendor kernel. That kernel would be shipped with a manifest of all the files, a certificate of origin, hashsums of binaries, etc. to create a first hashsum that would be the first block on the chain. Then as middleware and other components are brought in, additional blocks would be created. Blocks for HMI, testing, and various other blocks in the chain would be added, potentially each from a different vendor. Finally you'd reach a the point where you want to cut a release and instead of tracking all the contents merely through semantic versioning and code diving, you could instead make your release with the blockchain and anyone who is on that chain could verify their delivery and the provenance of the entire release.

This scenario I think is likely only useful in products made of open source that have sufficiently long supply chains to warrant it, but there are an increasing amount of products like this as more and more products are built with open source and more and more supply chains become global. Plenty of industries have supply chain management as a competitive advantage and I think in fact some blockchains were explicitly designed for this use: https://wiki.hyperledger.org/requirements/use-cases/use-case-supply-chain-logistics Combine the blockchain with reproducible builds and you would have a trusted, verifiable, distributed software supply chain.

Cheers,

Jeremiah



On August 8, 2017 at 10:35:04 AM, Foster, Jeremiah (jfoster@...) wrote:

On Tue, 2017-08-08 at 07:31 -0500, Shane Martin Coughlan wrote: 
> Hi Matija 

> Thanks for your notes! Your comment about the compliance artifacts 
> resonated. Two of the organizations that recently became conformant 
> was unsure if they needed to submit the compliance artifacts *to* the 
> OpenChain Project. Perhaps we need to make it more explicit that the 
> compliance artifacts do not need to be centrally submitted but need 
> to be prepared for potential review by customers/suppliers or 
> OpenChain auditors in the future. 

+1 


> On a related note, a central repository of compliance artifacts may 
> cause concern to some entities because they may not wish to provide 
> any internal business process information to the public-at-large. 
> Showing such artefacts to customers and so on would likely be far 
> more acceptable. 

A high-level SPDX document that serves as a BoM signed, on a blockchain 
channel (like Sawtooth) might provide a degree of assurance for due 
diligence. This way the high-level artifact, prettified for human 
consumption, can be publicly shared with a degree of trust. 

Of course such a solution needs to be engineered, but if it is let this 
serve as prior art so we don't get people who want to patent it. (Its 
not worth patenting.) 

Cheers, 

Jeremiah 

> Regards 

> Shane 

> -- 
> Shane Coughlan 
> OpenChain Program Manager 
> e: coughlan@... 
> p: +81 (0) 80 4035 8083 
> w: www.openchainproject.org 

> Professional profile: http://www.linkedin.com/in/shanecoughlan 

> Get my free book on open source compliance here: 
https://www.linuxfoundation.org/news-media/research/practical-gpl-com 
> pliance 

> > On Aug 8, 2017, at 5:10, Matija Šuklje <matija@...> wrote: 
> > 
> > Awesome stuff, Nathan and everyone involved! Thank you :D 
> > 
> > I found the document short enough and to the point. 
> > 
> > As for the slide deck, I am not much of a fan of slides as learning 
> > materials 
> > by themselves. How about – once we’re happy enough with the content 
> > of the 
> > Onboarding material – if we provided a short lightning-talk video 
> > of someone 
> > presenting OpenChain using those slides? 
> > 
> > Dne torek, 08. avgust 2017 ob 02:30:23 CEST je Nathan Kumagai 
> > napisal(a): 
> > > * Bring feedback about your own experiences promoting 
> > > OpenChain - tell 
> > > us what worked, and what type of hurdles or questions you faced 
> > 
> > One question I have repeatedly faced is since OpenChain conformance 
> > (>=1.1) is 
> > based on a self-certification without the need to make the 
> > verification or 
> > compliance artifacts public (or at least deposited in escrow), how 
> > is it not 
> > simply a toothless tiger? 
> > 
> > While we are still a coalition of the willing, this is perfectly 
> > fine, but if 
> > we want to have a broader reach, we need good answers to those 
> > kinds of 
> > questions. 
> > 
> > The FAQ already addresses this to some extent, but I just wanted to 
> > point that 
> > out as probably the biggest hurdle of wider adoption. 
> > 
> > 
> > cheers, 
> > Matija 
> > -- 
> > gsm: tel:+386-41-849-552 
> > www: http://matija.suklje.name 
> > xmpp: matija.suklje@... 
> > sip: matija_suklje@...__________________________________ 
> > _____________ 
> > OpenChain mailing list 
> > OpenChain@... 
> > https://lists.linuxfoundation.org/mailman/listinfo/openchain 

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

________________________________ 

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. 
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain



This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Steve Cropper
 

A very interesting thread but I think we need to walk before we run on this.

First you have to consider the adoption curve of both Open Chain and SPDX. If you want adoption then you can't throw new levels of complexity at the intended practitioners. Software Asset Management is still a nascent art and seems to have more focus in the IT world than in a typical manufacturing organization. Even then SAM is still not standard across most companies.

While automation and tooling are very helpful, they also create limitations and restrictions upon how something should be done. The blockchain example, for instance, while being an interesting proposed solution for artefact handling is probably not practical. Why? Because many of the organizations, who you want to adopt OpenChain, probably do not have the skill set or the budget to go there. It is probably all they can do to have a 'responsible adult' to over see the compliance and that person may not be dedicated. So let's think about the audience and our expectations of them, and their expectations of OpenChain. In many cases I think the fact that they implement and document a process and follow it (a la ISO 9001) is probably a step in the right direction. How they do it and with what tools should be independent of OpenChain purview.

As far as proving compliance goes, I think this is required for assurance purposes. However, not many companies, that I know of, will allow you to examine their processes and 'books' without appropriate paperwork (legal documentation - NDAs etc.) in place. So you now approach the realms of auditing, which is a requirement of any standardisation activity and needs a formal definition and process to go with it.

Many countries have a learner driver system in place. While you are driving and have not passed your test you attach a "Learner" badge to your car. When you have been approved and fully licensed you can remove the Learner plate. In some countries a 'Provisional" badge might be required for newly qualified drivers for upto a year after qualification to verify adherence to the traffic laws..

You could apply this type of certification as a way of asserting levels of confidence in the OpenChain compliance claim. 

1. Self Certified with no evidence -> 'Novice' not to be trusted fully but obviously heading in the right direction.
2. Self Certified with evidence (what evidence should this be and how trustworthy will it be?) -> 'Provisional' higher level of trust but still likely to be non-conforming
3. Audited and Approved -> 'Fully Licensed' and have been independently reviewed by an OpenChain approved auditor for compliance.

Whatever the decision here, we should try not to build a wall too high for the intended users to climb thereby defeating the objective of OpenChain :-).

Cheers
Steve


On Wed, Aug 9, 2017 at 8:17 AM, Miriam Ballhausen <mballhausen@...> wrote:
Hi All,

thanks for comments. They are very helpful.

We’ve discussed a couple of times whether we wanted to ask organizations to provide artifacts and I have had a couple of discussions about this offline. The consensus so far was that we would not ask for them (at least not now), but rather rely on the market and complaints. If a complaint was raised, we would look further into the company and potentially ask for the artifacts. I am happy to put this discussion back on the agenda though. 

For the time being, would it be sufficient to clarify or explain in more detail:
a) that you can raise complaints, if you have concerns that someone who is claiming to be OpenChain compliant is indeed not, and
b) that you need to have documentation, especially artifacts available and need to provide them in case of a complaint?

Kind regards,
Miriam

-- 
Rechtsanwältin Dr. Miriam Ballhausen
Software Compliance Academy

Mobile: +49 151 270 67 650
www.scompliance.com





Am 09.08.2017 um 00:50 schrieb Foster, Jeremiah <JFoster@...>:

On Tue, 2017-08-08 at 15:22 -0400, John Scott wrote:
Blockchain doesn’t really get you anything since the software components are always changing, js

If one is doing continuous integration and continuous delivery, yes, the components are changing. Still, even with typical CI/CD, there are often releases that are frozen and distributed. Here the blockchain is quite useful. For example, releases can be defined into manifests, as we do here: https://github.com/Pelagicore/pelux-manifests/blob/master/pelux-base.xml. Then you can use a manifest, along with other artifacts to create a release, like GENIVI does here: https://github.com/GENIVI/genivi-dev-platform/releases. Those releases are ideal candidates for a blockchain since they are frozen and their contents don't vary a great deal. Yes, often there are point releases, but those benefit from the same blockchain. 

Putting software releases, and the release manifests, on a blockchain would be help determining provenance. For example, one can envision a scenario where a typical FOSS product would begin with a vendor kernel. That kernel would be shipped with a manifest of all the files, a certificate of origin, hashsums of binaries, etc. to create a first hashsum that would be the first block on the chain. Then as middleware and other components are brought in, additional blocks would be created. Blocks for HMI, testing, and various other blocks in the chain would be added, potentially each from a different vendor. Finally you'd reach a the point where you want to cut a release and instead of tracking all the contents merely through semantic versioning and code diving, you could instead make your release with the blockchain and anyone who is on that chain could verify their delivery and the provenance of the entire release.

This scenario I think is likely only useful in products made of open source that have sufficiently long supply chains to warrant it, but there are an increasing amount of products like this as more and more products are built with open source and more and more supply chains become global. Plenty of industries have supply chain management as a competitive advantage and I think in fact some blockchains were explicitly designed for this use: https://wiki.hyperledger.org/requirements/use-cases/use-case-supply-chain-logistics Combine the blockchain with reproducible builds and you would have a trusted, verifiable, distributed software supply chain.

Cheers,

Jeremiah



On August 8, 2017 at 10:35:04 AM, Foster, Jeremiah (jfoster@...) wrote:

On Tue, 2017-08-08 at 07:31 -0500, Shane Martin Coughlan wrote: 
> Hi Matija 

> Thanks for your notes! Your comment about the compliance artifacts 
> resonated. Two of the organizations that recently became conformant 
> was unsure if they needed to submit the compliance artifacts *to* the 
> OpenChain Project. Perhaps we need to make it more explicit that the 
> compliance artifacts do not need to be centrally submitted but need 
> to be prepared for potential review by customers/suppliers or 
> OpenChain auditors in the future. 

+1 


> On a related note, a central repository of compliance artifacts may 
> cause concern to some entities because they may not wish to provide 
> any internal business process information to the public-at-large. 
> Showing such artefacts to customers and so on would likely be far 
> more acceptable. 

A high-level SPDX document that serves as a BoM signed, on a blockchain 
channel (like Sawtooth) might provide a degree of assurance for due 
diligence. This way the high-level artifact, prettified for human 
consumption, can be publicly shared with a degree of trust. 

Of course such a solution needs to be engineered, but if it is let this 
serve as prior art so we don't get people who want to patent it. (Its 
not worth patenting.) 

Cheers, 

Jeremiah 

> Regards 

> Shane 

> -- 
> Shane Coughlan 
> OpenChain Program Manager 
> e: coughlan@... 
> p: +81 (0) 80 4035 8083 
> w: www.openchainproject.org 

> Professional profile: http://www.linkedin.com/in/shanecoughlan 

> Get my free book on open source compliance here: 
https://www.linuxfoundation.org/news-media/research/practical-gpl-com 
> pliance 

> > On Aug 8, 2017, at 5:10, Matija Šuklje <matija@...> wrote: 
> > 
> > Awesome stuff, Nathan and everyone involved! Thank you :D 
> > 
> > I found the document short enough and to the point. 
> > 
> > As for the slide deck, I am not much of a fan of slides as learning 
> > materials 
> > by themselves. How about – once we’re happy enough with the content 
> > of the 
> > Onboarding material – if we provided a short lightning-talk video 
> > of someone 
> > presenting OpenChain using those slides? 
> > 
> > Dne torek, 08. avgust 2017 ob 02:30:23 CEST je Nathan Kumagai 
> > napisal(a): 
> > > * Bring feedback about your own experiences promoting 
> > > OpenChain - tell 
> > > us what worked, and what type of hurdles or questions you faced 
> > 
> > One question I have repeatedly faced is since OpenChain conformance 
> > (>=1.1) is 
> > based on a self-certification without the need to make the 
> > verification or 
> > compliance artifacts public (or at least deposited in escrow), how 
> > is it not 
> > simply a toothless tiger? 
> > 
> > While we are still a coalition of the willing, this is perfectly 
> > fine, but if 
> > we want to have a broader reach, we need good answers to those 
> > kinds of 
> > questions. 
> > 
> > The FAQ already addresses this to some extent, but I just wanted to 
> > point that 
> > out as probably the biggest hurdle of wider adoption. 
> > 
> > 
> > cheers, 
> > Matija 
> > -- 
> > gsm: tel:+386-41-849-552 
> > www: http://matija.suklje.name 
> > xmpp: matija.suklje@gabbler.org 
> > sip: matija_suklje@...__________________________________ 
> > _____________ 
> > OpenChain mailing list 
> > OpenChain@lists.linuxfoundation.org 
> > https://lists.linuxfoundation.org/mailman/listinfo/openchain 

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

________________________________ 

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. 
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain



This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain


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



john
 

There are a number of projects the US government is working on. Essentially these projects are about creating artifacts to approve system to operate (Authority to Operate) - ATO). I’m involved in most of these 
themes useful one right now is Project Boise aims to update the federal government’s software security compliance process that require an agency to obtain an ATO and comply with additional requirements prior to adoption of new commercial software.

there is also rumor that the upcoming NIST RMF rev 5 will have a lot of detail about forcing vendors to provide their software supply chain. 

IMO automation vi artifacts is the only way to go IF you want real security versus just compliance 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >
www.selectpress.net

On August 9, 2017 at 5:32:12 AM, Steve Cropper (stcroppe@...) wrote:

A very interesting thread but I think we need to walk before we run on this.

First you have to consider the adoption curve of both Open Chain and SPDX. If you want adoption then you can't throw new levels of complexity at the intended practitioners. Software Asset Management is still a nascent art and seems to have more focus in the IT world than in a typical manufacturing organization. Even then SAM is still not standard across most companies.

While automation and tooling are very helpful, they also create limitations and restrictions upon how something should be done. The blockchain example, for instance, while being an interesting proposed solution for artefact handling is probably not practical. Why? Because many of the organizations, who you want to adopt OpenChain, probably do not have the skill set or the budget to go there. It is probably all they can do to have a 'responsible adult' to over see the compliance and that person may not be dedicated. So let's think about the audience and our expectations of them, and their expectations of OpenChain. In many cases I think the fact that they implement and document a process and follow it (a la ISO 9001) is probably a step in the right direction. How they do it and with what tools should be independent of OpenChain purview.

As far as proving compliance goes, I think this is required for assurance purposes. However, not many companies, that I know of, will allow you to examine their processes and 'books' without appropriate paperwork (legal documentation - NDAs etc.) in place. So you now approach the realms of auditing, which is a requirement of any standardisation activity and needs a formal definition and process to go with it.

Many countries have a learner driver system in place. While you are driving and have not passed your test you attach a "Learner" badge to your car. When you have been approved and fully licensed you can remove the Learner plate. In some countries a 'Provisional" badge might be required for newly qualified drivers for upto a year after qualification to verify adherence to the traffic laws..

You could apply this type of certification as a way of asserting levels of confidence in the OpenChain compliance claim. 

1. Self Certified with no evidence -> 'Novice' not to be trusted fully but obviously heading in the right direction.
2. Self Certified with evidence (what evidence should this be and how trustworthy will it be?) -> 'Provisional' higher level of trust but still likely to be non-conforming
3. Audited and Approved -> 'Fully Licensed' and have been independently reviewed by an OpenChain approved auditor for compliance.

Whatever the decision here, we should try not to build a wall too high for the intended users to climb thereby defeating the objective of OpenChain :-).

Cheers
Steve


On Wed, Aug 9, 2017 at 8:17 AM, Miriam Ballhausen <mballhausen@...> wrote:
Hi All,

thanks for comments. They are very helpful.

We’ve discussed a couple of times whether we wanted to ask organizations to provide artifacts and I have had a couple of discussions about this offline. The consensus so far was that we would not ask for them (at least not now), but rather rely on the market and complaints. If a complaint was raised, we would look further into the company and potentially ask for the artifacts. I am happy to put this discussion back on the agenda though. 

For the time being, would it be sufficient to clarify or explain in more detail:
a) that you can raise complaints, if you have concerns that someone who is claiming to be OpenChain compliant is indeed not, and
b) that you need to have documentation, especially artifacts available and need to provide them in case of a complaint?

Kind regards,
Miriam

-- 
Rechtsanwältin Dr. Miriam Ballhausen
Software Compliance Academy

Mobile: +49 151 270 67 650
www.scompliance.com





Am 09.08.2017 um 00:50 schrieb Foster, Jeremiah <JFoster@...>:

On Tue, 2017-08-08 at 15:22 -0400, John Scott wrote:
Blockchain doesn’t really get you anything since the software components are always changing, js

If one is doing continuous integration and continuous delivery, yes, the components are changing. Still, even with typical CI/CD, there are often releases that are frozen and distributed. Here the blockchain is quite useful. For example, releases can be defined into manifests, as we do here: https://github.com/Pelagicore/pelux-manifests/blob/master/pelux-base.xml. Then you can use a manifest, along with other artifacts to create a release, like GENIVI does here: https://github.com/GENIVI/genivi-dev-platform/releases. Those releases are ideal candidates for a blockchain since they are frozen and their contents don't vary a great deal. Yes, often there are point releases, but those benefit from the same blockchain. 

Putting software releases, and the release manifests, on a blockchain would be help determining provenance. For example, one can envision a scenario where a typical FOSS product would begin with a vendor kernel. That kernel would be shipped with a manifest of all the files, a certificate of origin, hashsums of binaries, etc. to create a first hashsum that would be the first block on the chain. Then as middleware and other components are brought in, additional blocks would be created. Blocks for HMI, testing, and various other blocks in the chain would be added, potentially each from a different vendor. Finally you'd reach a the point where you want to cut a release and instead of tracking all the contents merely through semantic versioning and code diving, you could instead make your release with the blockchain and anyone who is on that chain could verify their delivery and the provenance of the entire release.

This scenario I think is likely only useful in products made of open source that have sufficiently long supply chains to warrant it, but there are an increasing amount of products like this as more and more products are built with open source and more and more supply chains become global. Plenty of industries have supply chain management as a competitive advantage and I think in fact some blockchains were explicitly designed for this use: https://wiki.hyperledger.org/requirements/use-cases/use-case-supply-chain-logistics Combine the blockchain with reproducible builds and you would have a trusted, verifiable, distributed software supply chain.

Cheers,

Jeremiah



On August 8, 2017 at 10:35:04 AM, Foster, Jeremiah (jfoster@...) wrote:

On Tue, 2017-08-08 at 07:31 -0500, Shane Martin Coughlan wrote: 
> Hi Matija 

> Thanks for your notes! Your comment about the compliance artifacts 
> resonated. Two of the organizations that recently became conformant 
> was unsure if they needed to submit the compliance artifacts *to* the 
> OpenChain Project. Perhaps we need to make it more explicit that the 
> compliance artifacts do not need to be centrally submitted but need 
> to be prepared for potential review by customers/suppliers or 
> OpenChain auditors in the future. 

+1 


> On a related note, a central repository of compliance artifacts may 
> cause concern to some entities because they may not wish to provide 
> any internal business process information to the public-at-large. 
> Showing such artefacts to customers and so on would likely be far 
> more acceptable. 

A high-level SPDX document that serves as a BoM signed, on a blockchain 
channel (like Sawtooth) might provide a degree of assurance for due 
diligence. This way the high-level artifact, prettified for human 
consumption, can be publicly shared with a degree of trust. 

Of course such a solution needs to be engineered, but if it is let this 
serve as prior art so we don't get people who want to patent it. (Its 
not worth patenting.) 

Cheers, 

Jeremiah 

> Regards 

> Shane 

> -- 
> Shane Coughlan 
> OpenChain Program Manager 
> e: coughlan@... 
> p: +81 (0) 80 4035 8083 
> w: www.openchainproject.org 

> Professional profile: http://www.linkedin.com/in/shanecoughlan 

> Get my free book on open source compliance here: 
https://www.linuxfoundation.org/news-media/research/practical-gpl-com 
> pliance 

> > On Aug 8, 2017, at 5:10, Matija Šuklje <matija@...> wrote: 
> > 
> > Awesome stuff, Nathan and everyone involved! Thank you :D 
> > 
> > I found the document short enough and to the point. 
> > 
> > As for the slide deck, I am not much of a fan of slides as learning 
> > materials 
> > by themselves. How about – once we’re happy enough with the content 
> > of the 
> > Onboarding material – if we provided a short lightning-talk video 
> > of someone 
> > presenting OpenChain using those slides? 
> > 
> > Dne torek, 08. avgust 2017 ob 02:30:23 CEST je Nathan Kumagai 
> > napisal(a): 
> > > * Bring feedback about your own experiences promoting 
> > > OpenChain - tell 
> > > us what worked, and what type of hurdles or questions you faced 
> > 
> > One question I have repeatedly faced is since OpenChain conformance 
> > (>=1.1) is 
> > based on a self-certification without the need to make the 
> > verification or 
> > compliance artifacts public (or at least deposited in escrow), how 
> > is it not 
> > simply a toothless tiger? 
> > 
> > While we are still a coalition of the willing, this is perfectly 
> > fine, but if 
> > we want to have a broader reach, we need good answers to those 
> > kinds of 
> > questions. 
> > 
> > The FAQ already addresses this to some extent, but I just wanted to 
> > point that 
> > out as probably the biggest hurdle of wider adoption. 
> > 
> > 
> > cheers, 
> > Matija 
> > -- 
> > gsm: tel:+386-41-849-552 
> > www: http://matija.suklje.name 
> > xmpp: matija.suklje@gabbler.org 
> > sip: matija_suklje@...__________________________________ 
> > _____________ 
> > OpenChain mailing list 
> > OpenChain@lists.linuxfoundation.org 
> > https://lists.linuxfoundation.org/mailman/listinfo/openchain 

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

________________________________ 

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. 
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain



This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain


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


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


Shane Martin Coughlan <coughlan@...>
 

Hi Miriam

My understanding has been the company stores the reference copy of the artifacts in-house, so there is no need to be concerned about privacy. A customer/supplier to an entity or OpenChain Project may ask to see the artifacts at some point, but there is no automatic sharing, distribution or redistribution. In short, the artifacts should exist and be collected for reference internally at the company, but that’a it.

I do think we need to clarify this point and communicate it clearly on the certification process page and in the FAQ as it is quickly becoming our most popular question.

Regards

Shane

On Aug 9, 2017, at 2:17, Miriam Ballhausen <mballhausen@...> wrote:

Hi All,

thanks for comments. They are very helpful.

We’ve discussed a couple of times whether we wanted to ask organizations to provide artifacts and I have had a couple of discussions about this offline. The consensus so far was that we would not ask for them (at least not now), but rather rely on the market and complaints. If a complaint was raised, we would look further into the company and potentially ask for the artifacts. I am happy to put this discussion back on the agenda though.

For the time being, would it be sufficient to clarify or explain in more detail:
a) that you can raise complaints, if you have concerns that someone who is claiming to be OpenChain compliant is indeed not, and
b) that you need to have documentation, especially artifacts available and need to provide them in case of a complaint?

Kind regards,
Miriam

--
Rechtsanwältin Dr. Miriam Ballhausen
Software Compliance Academy

Mobile: +49 151 270 67 650
www.scompliance.com




Am 09.08.2017 um 00:50 schrieb Foster, Jeremiah <JFoster@...>:

On Tue, 2017-08-08 at 15:22 -0400, John Scott wrote:
Blockchain doesn’t really get you anything since the software components are always changing, js
If one is doing continuous integration and continuous delivery, yes, the components are changing. Still, even with typical CI/CD, there are often releases that are frozen and distributed. Here the blockchain is quite useful. For example, releases can be defined into manifests, as we do here: https://github.com/Pelagicore/pelux-manifests/blob/master/pelux-base.xml. Then you can use a manifest, along with other artifacts to create a release, like GENIVI does here: https://github.com/GENIVI/genivi-dev-platform/releases. Those releases are ideal candidates for a blockchain since they are frozen and their contents don't vary a great deal. Yes, often there are point releases, but those benefit from the same blockchain.

Putting software releases, and the release manifests, on a blockchain would be help determining provenance. For example, one can envision a scenario where a typical FOSS product would begin with a vendor kernel. That kernel would be shipped with a manifest of all the files, a certificate of origin, hashsums of binaries, etc. to create a first hashsum that would be the first block on the chain. Then as middleware and other components are brought in, additional blocks would be created. Blocks for HMI, testing, and various other blocks in the chain would be added, potentially each from a different vendor. Finally you'd reach a the point where you want to cut a release and instead of tracking all the contents merely through semantic versioning and code diving, you could instead make your release with the blockchain and anyone who is on that chain could verify their delivery and the provenance of the entire release.

This scenario I think is likely only useful in products made of open source that have sufficiently long supply chains to warrant it, but there are an increasing amount of products like this as more and more products are built with open source and more and more supply chains become global. Plenty of industries have supply chain management as a competitive advantage and I think in fact some blockchains were explicitly designed for this use: https://wiki.hyperledger.org/requirements/use-cases/use-case-supply-chain-logistics Combine the blockchain with reproducible builds and you would have a trusted, verifiable, distributed software supply chain.

Cheers,

Jeremiah



On August 8, 2017 at 10:35:04 AM, Foster, Jeremiah (jfoster@...) wrote:

On Tue, 2017-08-08 at 07:31 -0500, Shane Martin Coughlan wrote:
Hi Matija

Thanks for your notes! Your comment about the compliance artifacts
resonated. Two of the organizations that recently became conformant
was unsure if they needed to submit the compliance artifacts *to* the
OpenChain Project. Perhaps we need to make it more explicit that the
compliance artifacts do not need to be centrally submitted but need
to be prepared for potential review by customers/suppliers or
OpenChain auditors in the future.
+1


On a related note, a central repository of compliance artifacts may
cause concern to some entities because they may not wish to provide
any internal business process information to the public-at-large.
Showing such artefacts to customers and so on would likely be far
more acceptable.
A high-level SPDX document that serves as a BoM signed, on a blockchain
channel (like Sawtooth) might provide a degree of assurance for due
diligence. This way the high-level artifact, prettified for human
consumption, can be publicly shared with a degree of trust.

Of course such a solution needs to be engineered, but if it is let this
serve as prior art so we don't get people who want to patent it. (Its
not worth patenting.)

Cheers,

Jeremiah

Regards

Shane

--
Shane Coughlan
OpenChain Program Manager
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Professional profile: http://www.linkedin.com/in/shanecoughlan

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-com
pliance

On Aug 8, 2017, at 5:10, Matija Šuklje <matija@...> wrote:

Awesome stuff, Nathan and everyone involved! Thank you :D

I found the document short enough and to the point.

As for the slide deck, I am not much of a fan of slides as learning
materials
by themselves. How about – once we’re happy enough with the content
of the
Onboarding material – if we provided a short lightning-talk video
of someone
presenting OpenChain using those slides?

Dne torek, 08. avgust 2017 ob 02:30:23 CEST je Nathan Kumagai
napisal(a):
* Bring feedback about your own experiences promoting
OpenChain - tell
us what worked, and what type of hurdles or questions you faced
One question I have repeatedly faced is since OpenChain conformance
(>=1.1) is
based on a self-certification without the need to make the
verification or
compliance artifacts public (or at least deposited in escrow), how
is it not
simply a toothless tiger?

While we are still a coalition of the willing, this is perfectly
fine, but if
we want to have a broader reach, we need good answers to those
kinds of
questions.

The FAQ already addresses this to some extent, but I just wanted to
point that
out as probably the biggest hurdle of wider adoption.


cheers,
Matija
--
gsm: tel:+386-41-849-552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...
_____________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Foster, Jeremiah <JFoster@...>
 

On Wed, 2017-08-09 at 10:32 +0100, Steve Cropper wrote:
A very interesting thread but I think we need to walk before we run on this.

I agree. I answered the original email with what I think might be a solution in the long run. I don't want us to get off topic I just wanted to outline an idea in the open.


First you have to consider the adoption curve of both Open Chain and SPDX. If you want adoption then you can't throw new levels of complexity at the intended practitioners. Software Asset Management is still a nascent art and seems to have more focus in the IT world than in a typical manufacturing organization. Even then SAM is still not standard across most companies.

+1

While automation and tooling are very helpful, they also create limitations and restrictions upon how something should be done. The blockchain example, for instance, while being an interesting proposed solution for artefact handling is probably not practical. Why? Because many of the organizations, who you want to adopt OpenChain, probably do not have the skill set or the budget to go there. It is probably all they can do to have a 'responsible adult' to over see the compliance and that person may not be dedicated. So let's think about the audience and our expectations of them, and their expectations of OpenChain. In many cases I think the fact that they implement and document a process and follow it (a la ISO 9001) is probably a step in the right direction. How they do it and with what tools should be independent of OpenChain purview.

+1

As far as proving compliance goes, I think this is required for assurance purposes. However, not many companies, that I know of, will allow you to examine their processes and 'books' without appropriate paperwork (legal documentation - NDAs etc.) in place. So you now approach the realms of auditing, which is a requirement of any standardisation activity and needs a formal definition and process to go with it.

Many countries have a learner driver system in place. While you are driving and have not passed your test you attach a "Learner" badge to your car. When you have been approved and fully licensed you can remove the Learner plate. In some countries a 'Provisional" badge might be required for newly qualified drivers for upto a year after qualification to verify adherence to the traffic laws..

You could apply this type of certification as a way of asserting levels of confidence in the OpenChain compliance claim. 

1. Self Certified with no evidence -> 'Novice' not to be trusted fully but obviously heading in the right direction.
2. Self Certified with evidence (what evidence should this be and how trustworthy will it be?) -> 'Provisional' higher level of trust but still likely to be non-conforming
3. Audited and Approved -> 'Fully Licensed' and have been independently reviewed by an OpenChain approved auditor for compliance.

Whatever the decision here, we should try not to build a wall too high for the intended users to climb thereby defeating the objective of OpenChain :-).

+1

Cheers,

Jeremiah

Cheers
Steve


On Wed, Aug 9, 2017 at 8:17 AM, Miriam Ballhausen <mballhausen@...> wrote:
Hi All,

thanks for comments. They are very helpful.

We’ve discussed a couple of times whether we wanted to ask organizations to provide artifacts and I have had a couple of discussions about this offline. The consensus so far was that we would not ask for them (at least not now), but rather rely on the market and complaints. If a complaint was raised, we would look further into the company and potentially ask for the artifacts. I am happy to put this discussion back on the agenda though. 

For the time being, would it be sufficient to clarify or explain in more detail:
a) that you can raise complaints, if you have concerns that someone who is claiming to be OpenChain compliant is indeed not, and
b) that you need to have documentation, especially artifacts available and need to provide them in case of a complaint?

Kind regards,
Miriam

-- 
Rechtsanwältin Dr. Miriam Ballhausen
Software Compliance Academy

Mobile: +49 151 270 67 650
www.scompliance.com





Am 09.08.2017 um 00:50 schrieb Foster, Jeremiah <JFoster@...>:

On Tue, 2017-08-08 at 15:22 -0400, John Scott wrote:
Blockchain doesn’t really get you anything since the software components are always changing, js

If one is doing continuous integration and continuous delivery, yes, the components are changing. Still, even with typical CI/CD, there are often releases that are frozen and distributed. Here the blockchain is quite useful. For example, releases can be defined into manifests, as we do here: https://github.com/Pelagicore/pelux-manifests/blob/master/pelux-base.xml. Then you can use a manifest, along with other artifacts to create a release, like GENIVI does here: https://github.com/GENIVI/genivi-dev-platform/releases. Those releases are ideal candidates for a blockchain since they are frozen and their contents don't vary a great deal. Yes, often there are point releases, but those benefit from the same blockchain. 

Putting software releases, and the release manifests, on a blockchain would be help determining provenance. For example, one can envision a scenario where a typical FOSS product would begin with a vendor kernel. That kernel would be shipped with a manifest of all the files, a certificate of origin, hashsums of binaries, etc. to create a first hashsum that would be the first block on the chain. Then as middleware and other components are brought in, additional blocks would be created. Blocks for HMI, testing, and various other blocks in the chain would be added, potentially each from a different vendor. Finally you'd reach a the point where you want to cut a release and instead of tracking all the contents merely through semantic versioning and code diving, you could instead make your release with the blockchain and anyone who is on that chain could verify their delivery and the provenance of the entire release.

This scenario I think is likely only useful in products made of open source that have sufficiently long supply chains to warrant it, but there are an increasing amount of products like this as more and more products are built with open source and more and more supply chains become global. Plenty of industries have supply chain management as a competitive advantage and I think in fact some blockchains were explicitly designed for this use: https://wiki.hyperledger.org/requirements/use-cases/use-case-supply-chain-logistics Combine the blockchain with reproducible builds and you would have a trusted, verifiable, distributed software supply chain.

Cheers,

Jeremiah



On August 8, 2017 at 10:35:04 AM, Foster, Jeremiah (jfoster@...) wrote:

On Tue, 2017-08-08 at 07:31 -0500, Shane Martin Coughlan wrote: 
> Hi Matija 

> Thanks for your notes! Your comment about the compliance artifacts 
> resonated. Two of the organizations that recently became conformant 
> was unsure if they needed to submit the compliance artifacts *to* the 
> OpenChain Project. Perhaps we need to make it more explicit that the 
> compliance artifacts do not need to be centrally submitted but need 
> to be prepared for potential review by customers/suppliers or 
> OpenChain auditors in the future. 

+1 


> On a related note, a central repository of compliance artifacts may 
> cause concern to some entities because they may not wish to provide 
> any internal business process information to the public-at-large. 
> Showing such artefacts to customers and so on would likely be far 
> more acceptable. 

A high-level SPDX document that serves as a BoM signed, on a blockchain 
channel (like Sawtooth) might provide a degree of assurance for due 
diligence. This way the high-level artifact, prettified for human 
consumption, can be publicly shared with a degree of trust. 

Of course such a solution needs to be engineered, but if it is let this 
serve as prior art so we don't get people who want to patent it. (Its 
not worth patenting.) 

Cheers, 

Jeremiah 

> Regards 

> Shane 

> -- 
> Shane Coughlan 
> OpenChain Program Manager 
> e: coughlan@... 
> p: +81 (0) 80 4035 8083 
> w: www.openchainproject.org 

> Professional profile: http://www.linkedin.com/in/shanecoughlan 

> Get my free book on open source compliance here: 
https://www.linuxfoundation.org/news-media/research/practical-gpl-com 
> pliance 

> > On Aug 8, 2017, at 5:10, Matija Šuklje <matija@...> wrote: 
> > 
> > Awesome stuff, Nathan and everyone involved! Thank you :D 
> > 
> > I found the document short enough and to the point. 
> > 
> > As for the slide deck, I am not much of a fan of slides as learning 
> > materials 
> > by themselves. How about – once we’re happy enough with the content 
> > of the 
> > Onboarding material – if we provided a short lightning-talk video 
> > of someone 
> > presenting OpenChain using those slides? 
> > 
> > Dne torek, 08. avgust 2017 ob 02:30:23 CEST je Nathan Kumagai 
> > napisal(a): 
> > > * Bring feedback about your own experiences promoting 
> > > OpenChain - tell 
> > > us what worked, and what type of hurdles or questions you faced 
> > 
> > One question I have repeatedly faced is since OpenChain conformance 
> > (>=1.1) is 
> > based on a self-certification without the need to make the 
> > verification or 
> > compliance artifacts public (or at least deposited in escrow), how 
> > is it not 
> > simply a toothless tiger? 
> > 
> > While we are still a coalition of the willing, this is perfectly 
> > fine, but if 
> > we want to have a broader reach, we need good answers to those 
> > kinds of 
> > questions. 
> > 
> > The FAQ already addresses this to some extent, but I just wanted to 
> > point that 
> > out as probably the biggest hurdle of wider adoption. 
> > 




This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.


Foster, Jeremiah <JFoster@...>
 

On Wed, 2017-08-09 at 08:33 -0400, John Scott wrote:
There are a number of projects the US government is working on. Essentially these projects are about creating artifacts to approve system to operate (Authority to Operate) - ATO). I’m involved in most of these 
themes useful one right now is Project Boise aims to update the federal government’s software security compliance process that require an agency to obtain an ATO and comply with additional requirements prior to adoption of new commercial software.

there is also rumor that the upcoming NIST RMF rev 5 will have a lot of detail about forcing vendors to provide their software supply chain. 

IMO automation vi artifacts is the only way to go IF you want real security versus just compliance 

Exactly. And not just security, but also regulatory compliance. Let's look at the recent VW case; software was written to get around regulations. Regulatory bodies could not inspect the software and could not find the reason for the regulatory discrepancy. After a year of work, they received information from the software designers themselves on how they defeated the inspection regime. This points to the necessity of understanding what every line of code does in your system for regulatory reasons. We already know we need this for security. But customers will need this, at least to certain degree, for the autonomous vehicles they ride in. Insurers will need it for the vehicles they insure. The list of stakeholders in complex autonomous systems running artificial intelligence algorithms in the functional safety domain is long. What are the tools that those stakeholders can use today?

Perhaps OpenChain is not the "solution" here, and I apologize if I'm off-topic, but OpenChain holds the keys to nascent and established best practices around introspection of complex software systems. We have code scanning tools and a way to package their results. We have a way to determine a one to one correspondence between license and software component. We have a way to determine the contents of git repos by examinging SHA sums. I think that there may be a way to build upon OpenChain to provide some degree of assurance that the contents of a given system are consistent with its attestations and claims to functionality, certification, etc. Yes, this may not be in the OpenChain mission, but where then is the best forum for this discussion?

Regards,

Jeremiah

<snip>



This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.


Martin Callinan
 

It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX

When I worked at Microsoft we created a maturity Assessment (see attached) which rated different processes with a maturity rating rather than a binary yes/no.

I still have a connection with the working group for ISO SAM/ITAM standards (WG 21) and have tried to get open source software on their radar.

In UK and Europe SAM is broadly adopted. There are full time employees and in some cases teams solely dedicated to SAM/ITAM. The principles as regards processes for SAM are similar to what is required to managed SAM.

If you think there is mileage in a liaison with WG21 I could pursue it.

Kind Regards,

Martin


From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Foster, Jeremiah
Sent: 09 August 2017 16:28
To: mballhausen@...; stcroppe@...; john@...
Cc: openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)

On Wed, 2017-08-09 at 08:33 -0400, John Scott wrote:
There are a number of projects the US government is working on. Essentially these projects are about creating artifacts to approve system to operate (Authority to Operate) - ATO). I’m involved in most of these 
themes useful one right now is Project Boise aims to update the federal government’s software security compliance process that require an agency to obtain an ATO and comply with additional requirements prior to adoption of new commercial software.

http://www.executivegov.com/2017/07/18f-launches-interagency-project-to-accelerate-govt-adoption-of-commercial-tech/


there is also rumor that the upcoming NIST RMF rev 5 will have a lot of detail about forcing vendors to provide their software supply chain. 


IMO automation vi artifacts is the only way to go IF you want real security versus just compliance 

Exactly. And not just security, but also regulatory compliance. Let's look at the recent VW case; software was written to get around regulations. Regulatory bodies could not inspect the software and could not find the reason for the regulatory discrepancy. After a year of work, they received information from the software designers themselves on how they defeated the inspection regime. This points to the necessity of understanding what every line of code does in your system for regulatory reasons. We already know we need this for security. But customers will need this, at least to certain degree, for the autonomous vehicles they ride in. Insurers will need it for the vehicles they insure. The list of stakeholders in complex autonomous systems running artificial intelligence algorithms in the functional safety domain is long. What are the tools that those stakeholders can use today?

Perhaps OpenChain is not the "solution" here, and I apologize if I'm off-topic, but OpenChain holds the keys to nascent and established best practices around introspection of complex software systems. We have code scanning tools and a way to package their results. We have a way to determine a one to one correspondence between license and software component. We have a way to determine the contents of git repos by examinging SHA sums. I think that there may be a way to build upon OpenChain to provide some degree of assurance that the contents of a given system are consistent with its attestations and claims to functionality, certification, etc. Yes, this may not be in the OpenChain mission, but where then is the best forum for this discussion?

Regards,

Jeremiah

<snip>

________________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.


Shane Martin Coughlan <coughlan@...>
 

Hi Steve

On Aug 9, 2017, at 4:32, Steve Cropper <stcroppe@...> wrote:
A very interesting thread but I think we need to walk before we run on this.
Agreed. We are purposefully pursuing self-certification with limited “proof” for OpenChain Conformance to have a minimal barrier to entry. We want to make it as easy as possible for organizations to confirm they have the processes for open source compliance in the supply chain in place.

First you have to consider the adoption curve of both Open Chain and SPDX. If you want adoption then you can't throw new levels of complexity at the intended practitioners. Software Asset Management is still a nascent art and seems to have more focus in the IT world than in a typical manufacturing organization. Even then SAM is still not standard across most companies.
While automation and tooling are very helpful, they also create limitations and restrictions upon how something should be done. […] In many cases I think the fact that they implement and document a process and follow it (a la ISO 9001) is probably a step in the right direction. How they do it and with what tools should be independent of OpenChain purview.
Precisely.

As far as proving compliance goes, I think this is required for assurance purposes. However, not many companies, that I know of, will allow you to examine their processes and 'books' without appropriate paperwork (legal documentation - NDAs etc.) in place. So you now approach the realms of auditing, which is a requirement of any standardisation activity and needs a formal definition and process to go with it.
Indeed.

[…]
You could apply this type of certification as a way of asserting levels of confidence in the OpenChain compliance claim.
1. Self Certified with no evidence -> 'Novice' not to be trusted fully but obviously heading in the right direction.
2. Self Certified with evidence (what evidence should this be and how trustworthy will it be?) -> 'Provisional' higher level of trust but still likely to be non-conforming
3. Audited and Approved -> 'Fully Licensed' and have been independently reviewed by an OpenChain approved auditor for compliance.
Whatever the decision here, we should try not to build a wall too high for the intended users to climb thereby defeating the objective of OpenChain :-).
Absolutely.

I would envision something like this:

Self-certified OpenChain conformance for the next 24 months. Partner network built out at the same time to help support organizations with this process. Around the 24 month mark we explore having a secondary badge: audited conformance. This is where a third party verifies conformance.

Is this a value add? Too early to tell. It may be, or we may want to leave the entire question of audits and verification between customers/suppliers. Let’s discuss in more detail after we pass the much earlier hurdle of continuing to build general adoption.

Regards

Shane


Shane Martin Coughlan <coughlan@...>
 

Hi Martin

On Aug 9, 2017, at 12:44, Martin Callinan <martin.callinan@...> wrote:

It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX

When I worked at Microsoft we created a maturity Assessment (see attached) which rated different processes with a maturity rating rather than a binary yes/no.

I still have a connection with the working group for ISO SAM/ITAM standards (WG 21) and have tried to get open source software on their radar.

In UK and Europe SAM is broadly adopted. There are full time employees and in some cases teams solely dedicated to SAM/ITAM. The principles as regards processes for SAM are similar to what is required to managed SAM.

If you think there is mileage in a liaison with WG21 I could pursue it.
I think it’s too early for us. However, it is useful to know we can pick your brain when the time comes!

Regards

Shane


Matija Šuklje
 

Dne četrtek, 10. avgust 2017 ob 18:26:25 CEST je Shane Martin Coughlan
napisal(a):
Self-certified OpenChain conformance for the next 24 months. Partner network
built out at the same time to help support organizations with this process.
Around the 24 month mark we explore having a secondary badge: audited
conformance. This is where a third party verifies conformance.
Sounds like a plan to me :)


cheers,
Matija
--
gsm: tel:+386-41-849-552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Kate Stewart
 

Hi Martin,

On Wed, Aug 9, 2017 at 12:44 PM, Martin Callinan <martin.callinan@sourcecodecontrol.co> wrote:
It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of  ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX

The challenge with using SWIDs is you have to pay for access to the specification.
https://www.iso.org/standard/65666.html     SWIDs also don't have a good human
readable equivalent, as you'll need to use a tool to read one.

Also, as I understand it (please correct me) in order to get an SWID tag assigned,  
you need to join an organization (tagvault) and pay a fee.   Which isn't necessarily viable
for open source upstream projects and hence supply chains with open source 
component dependencies. 

Thanks, Kate
 


Martin Callinan
 

Hi Kate,

 

The standard was produced so anybody could create a tag. I once considered it as a service offering. TagVault was started by Steve Klos who was convener for the writing of ISO 19770-2 and have positioned themselves certification authority but that does not stop anybody creating tags without going through TagVault.

 

I was not meaning to suggest we go down the same route as SWIDs for Open Source but thought there may be some learnings we can take from the work they have done.

 

ISO always charges for standards but their standards have a lot of credibility and a lot of work goes into having a standard recognised.

 

In the UK there is an organisation called the British Standards Institute https://www.bsigroup.com/en-GB/our-services/certification/how-to-get-certified/ where they support groups creating standards which can then me moved up to ISO to evolve into an ISO ratified standard. I though as OpenChain matures it may be logical to aim for ISO certification.

 

Kind Regards,

 

Martin

 

 

 

 

From: Kate Stewart [mailto:kstewart@...]
Sent: 11 August 2017 16:22
To: Martin Callinan <martin.callinan@...>
Cc: Foster, Jeremiah <JFoster@...>; mballhausen@...; stcroppe@...; john@...; openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)

 

Hi Martin,

 

On Wed, Aug 9, 2017 at 12:44 PM, Martin Callinan <martin.callinan@...> wrote:

It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of  ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX

 

The challenge with using SWIDs is you have to pay for access to the specification.

https://www.iso.org/standard/65666.html     SWIDs also don't have a good human

readable equivalent, as you'll need to use a tool to read one.

 

Also, as I understand it (please correct me) in order to get an SWID tag assigned,  

you need to join an organization (tagvault) and pay a fee.   Which isn't necessarily viable

for open source upstream projects and hence supply chains with open source 

component dependencies. 

 

Thanks, Kate

 


William Weinberg <bill@...>
 

Hi Martin

It has been the tradition of the Linux Foundation to sponsor projects that implement existing paper standards and create new de facto ones.   A de jure, paper path that you suggest suffers from cost, slowness and the honor of being a “leading” vs. a following standard, thus engendering multiple, usually variously forked implementations, each with its own “secret sauce”.  Even ISO process-oriented (vs. technology) standards suffer from this same ill.

Is there a real value in slogging through a full ISO certification?  Would an ISO process certification really carry extra cachet at this point in history?

Bill W.


On Aug 11, 2017, at 1:32 PM, Martin Callinan <martin.callinan@...> wrote:

Hi Kate,
 
The standard was produced so anybody could create a tag. I once considered it as a service offering. TagVault was started by Steve Klos who was convener for the writing of ISO 19770-2 and have positioned themselves certification authority but that does not stop anybody creating tags without going through TagVault.
 
I was not meaning to suggest we go down the same route as SWIDs for Open Source but thought there may be some learnings we can take from the work they have done.
 
ISO always charges for standards but their standards have a lot of credibility and a lot of work goes into having a standard recognised.
 
In the UK there is an organisation called the British Standards Institute https://www.bsigroup.com/en-GB/our-services/certification/how-to-get-certified/ where they support groups creating standards which can then me moved up to ISO to evolve into an ISO ratified standard. I though as OpenChain matures it may be logical to aim for ISO certification.
 
Kind Regards,
 
Martin
 
 
 
 
From: Kate Stewart [mailto:kstewart@...] 
Sent: 11 August 2017 16:22
To: Martin Callinan <martin.callinan@...>
Cc: Foster, Jeremiah <JFoster@...>; mballhausen@...; stcroppe@...; john@...; openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)
 
Hi Martin,
 
On Wed, Aug 9, 2017 at 12:44 PM, Martin Callinan <martin.callinan@...> wrote:
It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of  ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX
 
The challenge with using SWIDs is you have to pay for access to the specification.
https://www.iso.org/standard/65666.html     SWIDs also don't have a good human
readable equivalent, as you'll need to use a tool to read one.
 
Also, as I understand it (please correct me) in order to get an SWID tag assigned,  
you need to join an organization (tagvault) and pay a fee.   Which isn't necessarily viable
for open source upstream projects and hence supply chains with open source 
component dependencies. 
 
Thanks, Kate
 
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Kate Stewart
 

Hi Martin,

On Fri, Aug 11, 2017 at 12:32 PM, Martin Callinan <martin.callinan@...> wrote:

Hi Kate,

 

The standard was produced so anybody could create a tag. I once considered it as a service offering. TagVault was started by Steve Klos who was convener for the writing of ISO 19770-2 and have positioned themselves certification authority but that does not stop anybody creating tags without going through TagVault.


Thanks for clarifying this Martin.   
 

 

I was not meaning to suggest we go down the same route as SWIDs for Open Source but thought there may be some learnings we can take from the work they have done.


Completely agree. 
 
Thanks, Kate


Martin Callinan
 

Hi Bill,

 

It is a fair point that ISO certification are  a slog to bring to market.

 

I do think there is a lot we can learn about how ISO 19770-1 has been structured and regardless of ISO could be leveraged in OpenChain. I have an attached an early draft of the standard from when I was involved.

 

The overall process they lay out is similar in principle to OpenChain’s processes

 

 

 

From: William Weinberg [mailto:bill@...]
Sent: 11 August 2017 19:54
To: Martin Callinan <martin.callinan@...>
Cc: Kate Stewart <kstewart@...>; openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)

 

Hi Martin

 

It has been the tradition of the Linux Foundation to sponsor projects that implement existing paper standards and create new de facto ones.   A de jure, paper path that you suggest suffers from cost, slowness and the honor of being a “leading” vs. a following standard, thus engendering multiple, usually variously forked implementations, each with its own “secret sauce”.  Even ISO process-oriented (vs. technology) standards suffer from this same ill.

 

Is there a real value in slogging through a full ISO certification?  Would an ISO process certification really carry extra cachet at this point in history?

 

Bill W.

 

 

On Aug 11, 2017, at 1:32 PM, Martin Callinan <martin.callinan@...> wrote:

 

Hi Kate,

 

The standard was produced so anybody could create a tag. I once considered it as a service offering. TagVault was started by Steve Klos who was convener for the writing of ISO 19770-2 and have positioned themselves certification authority but that does not stop anybody creating tags without going through TagVault.

 

I was not meaning to suggest we go down the same route as SWIDs for Open Source but thought there may be some learnings we can take from the work they have done.

 

ISO always charges for standards but their standards have a lot of credibility and a lot of work goes into having a standard recognised.

 

In the UK there is an organisation called the British Standards Institute https://www.bsigroup.com/en-GB/our-services/certification/how-to-get-certified/ where they support groups creating standards which can then me moved up to ISO to evolve into an ISO ratified standard. I though as OpenChain matures it may be logical to aim for ISO certification.

 

Kind Regards,

 

Martin

 

 

 

 

From: Kate Stewart [mailto:kstewart@...] 
Sent: 11 August 2017 16:22
To: Martin Callinan <martin.callinan@...>
Cc: Foster, Jeremiah <JFoster@...>; mballhausen@...; stcroppe@...; john@...; openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)

 

Hi Martin,

 

On Wed, Aug 9, 2017 at 12:44 PM, Martin Callinan <martin.callinan@...> wrote:

It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of  ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX

 

The challenge with using SWIDs is you have to pay for access to the specification.

https://www.iso.org/standard/65666.html     SWIDs also don't have a good human

readable equivalent, as you'll need to use a tool to read one.

 

Also, as I understand it (please correct me) in order to get an SWID tag assigned,  

you need to join an organization (tagvault) and pay a fee.   Which isn't necessarily viable

for open source upstream projects and hence supply chains with open source 

component dependencies. 

 

Thanks, Kate

 

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

 


Shane Martin Coughlan <coughlan@...>
 

Hi Martin

As a shorthand way of describing OpenChain I saw “this is like ISO 9001 for open source compliance in the supply chain.” I would envision us continue our current path of pushing market adoption and maintaining de facto growth until we reach a certain tipping point, and then examining whether going down the ISO path makes sense.

Meanwhile, I concur with your note that we can learn from existing standards and existing processes. This will both help ensure we relearn lessons and it will help ensure that - when the day comes - we are able to easily align with de jure standard organizations. Your insight will be appreciate and invaluable in this regard.

Regards

Shane

--
Shane Coughlan
OpenChain Program Manager
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

Professional profile: http://www.linkedin.com/in/shanecoughlan

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance

On Aug 13, 2017, at 20:47, Martin Callinan <martin.callinan@...> wrote:

Hi Bill,



It is a fair point that ISO certification are a slog to bring to market.



I do think there is a lot we can learn about how ISO 19770-1 has been structured and regardless of ISO could be leveraged in OpenChain. I have an attached an early draft of the standard from when I was involved.



The overall process they lay out is similar in principle to OpenChain’s processes

<image001.png>






From: William Weinberg [mailto:bill@...]
Sent: 11 August 2017 19:54
To: Martin Callinan <martin.callinan@...>
Cc: Kate Stewart <kstewart@...>; openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)



Hi Martin



It has been the tradition of the Linux Foundation to sponsor projects that implement existing paper standards and create new de facto ones. A de jure, paper path that you suggest suffers from cost, slowness and the honor of being a “leading” vs. a following standard, thus engendering multiple, usually variously forked implementations, each with its own “secret sauce”. Even ISO process-oriented (vs. technology) standards suffer from this same ill.



Is there a real value in slogging through a full ISO certification? Would an ISO process certification really carry extra cachet at this point in history?



Bill W.





On Aug 11, 2017, at 1:32 PM, Martin Callinan <martin.callinan@...> wrote:



Hi Kate,



The standard was produced so anybody could create a tag. I once considered it as a service offering. TagVault was started by Steve Klos who was convener for the writing of ISO 19770-2 and have positioned themselves certification authority but that does not stop anybody creating tags without going through TagVault.



I was not meaning to suggest we go down the same route as SWIDs for Open Source but thought there may be some learnings we can take from the work they have done.



ISO always charges for standards but their standards have a lot of credibility and a lot of work goes into having a standard recognised.



In the UK there is an organisation called the British Standards Institute https://www.bsigroup.com/en-GB/our-services/certification/how-to-get-certified/ where they support groups creating standards which can then me moved up to ISO to evolve into an ISO ratified standard. I though as OpenChain matures it may be logical to aim for ISO certification.



Kind Regards,



Martin









From: Kate Stewart [mailto:kstewart@...]
Sent: 11 August 2017 16:22
To: Martin Callinan <martin.callinan@...>
Cc: Foster, Jeremiah <JFoster@...>; mballhausen@...; stcroppe@...; john@...; openchain@...
Subject: Re: [OpenChain] Verification/Providing Artifacts (was: Onboarding work team - CALL FOR MATERIALS)



Hi Martin,



On Wed, Aug 9, 2017 at 12:44 PM, Martin Callinan <martin.callinan@...> wrote:

It is interesting to see Software Asset Management being referenced. I have been involved in SAM since the late 90's. I was part of a non-profit call Investors in Software that formed to drive standards in managing software (at the time proprietary) which led to the publication of ISO/IEC 19770-1 Standard for Software Asset Management which is a process standard
https://www.iso.org/standard/56000.html

There is also ISO/IEC 19770-2 Software ID Tagging Standard which is an XML Tag definition to tag software that needs to be licensed. https://www.iso.org/standard/53670.html which in a way is similar to SPDX



The challenge with using SWIDs is you have to pay for access to the specification.

https://www.iso.org/standard/65666.html SWIDs also don't have a good human

readable equivalent, as you'll need to use a tool to read one.



Also, as I understand it (please correct me) in order to get an SWID tag assigned,

you need to join an organization (tagvault) and pay a fee. Which isn't necessarily viable

for open source upstream projects and hence supply chains with open source

component dependencies.



Thanks, Kate



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



<19770-1 UK Draft 20050508.pdf>_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain