OpenChain meeting today


Kelly Williams
 

Hi Everyone,

 

Reminder the Spec and Curriculum meeting is today at 5pm PST.  Please find attached the slides. 

 

Join the call: https://www.uberconference.com/katestewart

Optional dial in number: 877-297-7470

Alternate number: 512-910-4433

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 512 910 4433, then #.

 

Thanks,

Kelly

 


Gary O'Neall
 

Hi Kelly and openchain team,

 

It turns out I’ll be on a plane during today’s call, so I’ll miss this one. 

 

I did a quick review of the slides and they look good to me – I especially like the improved graphics.

 

Although it isn’t on the agenda, if anyone is curious about the self certification questionnaire website – We did meet with Raghu Madabushi from the Linux Foundation on setting up a web server.  They are currently deciding on the technology to be used for the main openchain website.  They have the use cases and will provide a recommendation to me on what technology we should to implement the self certification survey Once that I have the recommendations, I’ll start working on the self-certification survey forms.

 

Let me know if there are any follow-up questions or actions for me from the call.

 

Thanks,

Gary

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Monday, September 19, 2016 8:53 AM
To: openchain@...
Subject: [OpenChain] OpenChain meeting today

 

Hi Everyone,

 

Reminder the Spec and Curriculum meeting is today at 5pm PST.  Please find attached the slides. 

 

Join the call: https://www.uberconference.com/katestewart

Optional dial in number: 877-297-7470

Alternate number: 512-910-4433

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 512 910 4433, then #.

 

Thanks,

Kelly

 


Shane Martin Coughlan <shane@...>
 

Hi Gary

Sounds good. Let’s coordinate on the self-certification item. Mike Dolan recently introduced me to Clyde Seepersad, who runs training programs at Linux Foundation, and we are just beginning a dialogue about how they may be able to assist. Let me bring you into CC on that thread.

Regards

Shane

On Sep 20, 2016, at 2:10 AM, gary@... wrote:

Hi Kelly and openchain team,

It turns out I’ll be on a plane during today’s call, so I’ll miss this one.

I did a quick review of the slides and they look good to me – I especially like the improved graphics.

Although it isn’t on the agenda, if anyone is curious about the self certification questionnaire website – We did meet with Raghu Madabushi from the Linux Foundation on setting up a web server. They are currently deciding on the technology to be used for the main openchain website. They have the use cases and will provide a recommendation to me on what technology we should to implement the self certification survey Once that I have the recommendations, I’ll start working on the self-certification survey forms.

Let me know if there are any follow-up questions or actions for me from the call.

Thanks,
Gary

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Williams, Kelly
Sent: Monday, September 19, 2016 8:53 AM
To: openchain@...
Subject: [OpenChain] OpenChain meeting today

Hi Everyone,

Reminder the Spec and Curriculum meeting is today at 5pm PST. Please find attached the slides.

Join the call: https://www.uberconference.com/katestewart
Optional dial in number: 877-297-7470
Alternate number: 512-910-4433
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 512 910 4433, then #.

Thanks,
Kelly

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


Kelly Williams
 

Hi Everyone,

 

Reminder the Spec and Curriculum meeting is today at 5pm PST.  Please find attached the slides. 

 

Join the call: https://www.uberconference.com/katestewart

Optional dial in number: 877-297-7470

Alternate number: 512-910-4433

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 512 910 4433, then #.

 

Thanks,

Kelly

 


Jeremiah Foster <jeremiah.foster@...>
 

Hi,

I can't make the meeting today due to prior commitments for GENIVI. I have some questions about the "extensions" of OpenChain though -- is there more information on extending OpenChain to "security"? I ask because security is a software development domain, not a compliance or standards domain. Not least because security has to be holistic in the product and is a negative goal. 

Is there more information on how and why OpenChain would incorporate the security topic?

Thank you,

Jeremiah

On Mon, Oct 17, 2016 at 11:36 AM, Williams, Kelly <kellyw@...> wrote:

Hi Everyone,

 

Reminder the Spec and Curriculum meeting is today at 5pm PST.  Please find attached the slides. 

 

Join the call: https://www.uberconference.com/katestewart

Optional dial in number: 877-297-7470

Alternate number: 512-910-4433

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 512 910 4433, then #.

 

Thanks,

Kelly

 


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




--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +1.860.772.9242


Mark Gisi
 

Hi Jeremiah,

 

>> I have some questions about the "extensions" of OpenChain

 

This is a new consideration that needs to be discussed. Without committing to any one new extension, the idea is to set up a framework where we could experiment (pilot) new types of program requirements where one wants to establish trust around handling lots of open source with respect to a given extension type (e.g., security, export, …) . For example, when delivering a solution a recipient  may want some level of assurance that the distributor has a sufficient process for managing security vulnerabilities for the open source included in that solution. That is, an OpenChain Security added-on option. It is an option in that not everyone using the spec needs to conform with that section of the spec. Only those that decide they want to certify their process to be trusted with respect to how they handle security vulnerabilities.

 

>> "? I ask because security is a software development domain, not a compliance or standards domain.

 

It will depend on how we define security. The current thinking is that a security option would focus on defining a standard set of requirements for a program that manages (tracks) security vulnerabilities in the open source software.

 

>> Is there more information on how and why OpenChain would incorporate the security topic?

 

Not yet. It is wide open and just a potential consideration. Your questions are very much in line with the discussion we need to have to determine if this approach makes sense or not.

 

Best,

- Mark

 

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Monday, October 17, 2016 1:16 PM
To: Williams, Kelly
Cc: openchain@...
Subject: Re: [OpenChain] OpenChain meeting today

 

Hi,

 

I can't make the meeting today due to prior commitments for GENIVI. I have some questions about the "extensions" of OpenChain though -- is there more information on extending OpenChain to "security"? I ask because security is a software development domain, not a compliance or standards domain. Not least because security has to be holistic in the product and is a negative goal. 

 

Is there more information on how and why OpenChain would incorporate the security topic?

 

Thank you,

 

Jeremiah

 

On Mon, Oct 17, 2016 at 11:36 AM, Williams, Kelly <kellyw@...> wrote:

Hi Everyone,

 

Reminder the Spec and Curriculum meeting is today at 5pm PST.  Please find attached the slides. 

 

Join the call: https://www.uberconference.com/katestewart

Optional dial in number: 877-297-7470

Alternate number: 512-910-4433

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 512 910 4433, then #.

 

Thanks,

Kelly

 


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



 

--

Jeremiah C. Foster

GENIVI COMMUNITY MANAGER

 

Pelagicore AB

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

M: +1.860.772.9242


Jonas Oberg <jonas@...>
 

Hi Mark, others,

by way of introduction first: for those of you who do not know me,
I'm the executive director for the FSFE, but for my participation
on this list, I'm speaking for Morus AB, a small consulting firm
in Sweden which help companies in their understanding of FOSS.

Without committing to any one new extension, the idea is to set up
a framework where we could experiment (pilot) new types of program
requirements where one wants to establish trust around handling lots
of open source with respect to a given extension type (e.g., security,
export, …)
I do believe this makes sense in principle, but it may lead to confusion
around the OpenChain mark if this becomes wide spread and used for many
different areas.

Especially security does seem like a useful area to experiment with this
on though, and I'd be interested in this. Whether such an experiment then
leads to an extension of OpenChain or a certification in itself is
probably a later question, and both are certainly possible.


--
Jonas Öberg, Styrelseordförande
Morus konsult AB | jonas@...
E-mail is the fastest way to my attention


Jeremiah Foster <jeremiah.foster@...>
 



On Tue, Oct 18, 2016 at 12:13 AM, Jonas Oberg <jonas@...> wrote:
Hi Mark, others,

by way of introduction first: for those of you who do not know me,
I'm the executive director for the FSFE, but for my participation
on this list, I'm speaking for Morus AB, a small consulting firm
in Sweden which help companies in their understanding of FOSS.

> Without committing to any one new extension, the idea is to set up
> a framework where we could experiment (pilot) new types of program
> requirements where one wants to establish trust around handling lots
> of open source with respect to a given extension type (e.g., security,
> export, …)

I do believe this makes sense in principle, but it may lead to confusion
around the OpenChain mark if this becomes wide spread and used for many
different areas.

Especially security does seem like a useful area to experiment with this
on though, and I'd be interested in this. Whether such an experiment then
leads to an extension of OpenChain or a certification in itself is
probably a later question, and both are certainly possible.

​I agree this makes sense on principle, and many vendors will include this data, not least because it is of great interest now. But we're wandering into an area that has lots of standards, certifications, established practices, and tooling already. What is OpenChain planning to bring that those other organizations do not bring?

 It seems that OpenChain is trying to justify an additional field in the already verbose SPDX output that might hold a hash to a CVE database entry or so. In the companies that I work with, they feel that there needs to be a much more stark separation of concerns since the largest security issue is connectivity where license compliance has a very limited role to play. A link to some CVE is useless in compliance and the security team never sees it.

Security discussion in OpenChain feels like feature creep and is as bad as license proliferation that many of us have railed against for years. If vendors want to sell it, by all means, but it poses some risks to OpenChain if compliance is going to try to enter the security domain.

Regards,

Jeremiah​
 


Dave Marr
 

Hi Jeremiah,

 

Those are all sensible points.  As Mark indicated, as a group we’re far from saying that security ought to be brought into frame.  Right now we’re just talking about whether a modular architecture to the specification might better allow for future extensibility.  Can you join the next spec call?  It will be at a time more compatible with Europe.

 

Dave


Jeremiah Foster <jeremiah.foster@...>
 

Hi,

On Oct 18, 2016 11:17, "Marr, David" <dmarr@...> wrote:
>
> Hi Jeremiah,
>
>  
>
> Those are all sensible points.  As Mark indicated, as a group we’re far from saying that security ought to be brought into frame.  Right now we’re just talking about whether a modular architecture to the specification might better allow for future extensibility.  Can you join the next spec call?  It will be at a time more compatible with Europe.

I'm now permanently in the US Penobscot Bay for sale Portland so far so good time zone so OpenChain times have been fine for me. I'm happy to join the next call.

I agree with the modular architecture approach for OpenChain and I'm sorry if I'm unnecessarily  slowing progress, that is not my intention. My intention is to ensure we have a separation of concerns in the security and the compliance domain. I believe the important and worthy goal of compliance certification is impossible in security since the domain is so much larger, more complex and has well financed actors -- all things that would jeopardize the value and may even bring liability to any standard that claims compliance or conformance.

I also hope my dear friend Jonas Öberg tolerates my vehemence. :-)

Regards,

Jeremiah

>  
>
> Dave


Shane Martin Coughlan <shane@...>
 

Hi Jeremiah

On 2016 Oct 19, at 7:39, Jeremiah Foster <jeremiah.foster@...> wrote:
On Oct 18, 2016 11:17, "Marr, David" <dmarr@...> wrote:
Those are all sensible points. As Mark indicated, as a group we’re far from saying that security ought to be brought into frame. Right now we’re just talking about whether a modular architecture to the specification might better allow for future extensibility. Can you join the next spec call? It will be at a time more compatible with Europe.
I agree with the modular architecture approach for OpenChain and I'm sorry if I'm unnecessarily slowing progress, that is not my intention. My intention is to ensure we have a separation of concerns in the security and the compliance domain. I believe the important and worthy goal of compliance certification is impossible in security since the domain is so much larger, more complex and has well financed actors -- all things that would jeopardize the value and may even bring liability to any standard that claims compliance or conformance.
As Mark and Dave said, at this juncture the idea is to discuss whether a modular architecture approach for OpenChain makes sense, and what may be included in a series of experimental modules that may later graduate to extensions of OpenChain for areas beyond compliance. Contribution processes, Security processes, Export Compliance and ISO 26262 (functional safety) were all included as possible avenues in our discussion of experimental modules.

I believe it is important to stress that we are not talking about "trying to justify an additional field in the already verbose SPDX output that might hold a hash to a CVE database entry.” As you correctly pointed out, security and compliance teams (and export or development teams) often operate separately inside organizations. However, I would equally stress that SPDX and OpenChain are two different things. OpenChain has had a wider scope from inception. More specifically, SPDX is a standard format for communicating the components, licenses and copyrights associated with software packages. Meanwhile, OpenChain’s mission is to establish requirements to achieve effective management of free/open source software (FOSS) for software supply chain participants.

In OpenChain we are always trying to describe the minimal process required to accomplish a goal around Open Source. In the first instance, we have created a specification describing the minimal process required for what is necessary for due diligence around compliance. Any extensions to OpenChain (or experimental modules that might take a later life of their own) would follow a similar pattern. When talking about security, the idea would not to be to attempt to describe a Software Development Security Domain (ref: http://resources.infosecinstitute.com/cissp-2015-update-software-development-security/) but rather to talk about the type of minimal process required to address security vulnerabilities around Open Source Software (ref:
https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html).

By the same thinking, any extensions to address Export Compliance focused on cryptography or ISO 26262 would not be intended to replace or compete with existing standards, but rather to describe the minimal set of processes we would expect to see around companies deploying Open Source software in these contexts. Anyone adhering to existing standards and best practices would essentially already surpass the minimal requirements laid out. As always, the real goal is to make sure that even the smallest stakeholder in Open Source can introduce or complex with the type of best practices that the largest and most experienced entities have access to, and in the process we gradually transform the global supply chain.

In conclusion, the question is really whether we explore processes beyond compliance. The consensus at our face-to-face was that such further development should not be part of the core specification, but may be worthwhile as extensions. This is not a firm decision that OpenChain should go beyond license compliance. We may come to consensus that OpenChain as a process specification should remain compliance-only and we would cease work on any extensions after a period of experimentation or - as Jonas referenced - such experimental modules may take on a life of their own as another process specification for minimal adherence to requirements for accomplishing other goals around Open Source.

I believe we are all on the same page:
(1) Let’s not confuse compliance with other things
(2) Let’s keep the OpenChain specification clear and focused
(3) But let’s keep an open mind regarding other ways we can make a difference around Open Source in the supply chain

Regards

Shane


Shane Martin Coughlan <shane@...>
 

Oh dear. What a typo.

"As always, the real goal is to make sure that even the smallest stakeholder in Open Source can introduce or complex with the type of best practices that the largest and most experienced entities have access to, and in the process we gradually transform the global supply chain. “

Should be

"As always, the real goal is to make sure that even the smallest stakeholder in Open Source can introduce or comply with the type of best practices that the largest and most experienced entities have access to, and in the process we gradually transform the global supply chain. “

Regards

Shane

On 2016 Oct 19, at 13:49, Shane Martin Coughlan <shane@...> wrote:

Hi Jeremiah

On 2016 Oct 19, at 7:39, Jeremiah Foster <jeremiah.foster@...> wrote:
On Oct 18, 2016 11:17, "Marr, David" <dmarr@...> wrote:
Those are all sensible points. As Mark indicated, as a group we’re far from saying that security ought to be brought into frame. Right now we’re just talking about whether a modular architecture to the specification might better allow for future extensibility. Can you join the next spec call? It will be at a time more compatible with Europe.
I agree with the modular architecture approach for OpenChain and I'm sorry if I'm unnecessarily slowing progress, that is not my intention. My intention is to ensure we have a separation of concerns in the security and the compliance domain. I believe the important and worthy goal of compliance certification is impossible in security since the domain is so much larger, more complex and has well financed actors -- all things that would jeopardize the value and may even bring liability to any standard that claims compliance or conformance.
As Mark and Dave said, at this juncture the idea is to discuss whether a modular architecture approach for OpenChain makes sense, and what may be included in a series of experimental modules that may later graduate to extensions of OpenChain for areas beyond compliance. Contribution processes, Security processes, Export Compliance and ISO 26262 (functional safety) were all included as possible avenues in our discussion of experimental modules.

I believe it is important to stress that we are not talking about "trying to justify an additional field in the already verbose SPDX output that might hold a hash to a CVE database entry.” As you correctly pointed out, security and compliance teams (and export or development teams) often operate separately inside organizations. However, I would equally stress that SPDX and OpenChain are two different things. OpenChain has had a wider scope from inception. More specifically, SPDX is a standard format for communicating the components, licenses and copyrights associated with software packages. Meanwhile, OpenChain’s mission is to establish requirements to achieve effective management of free/open source software (FOSS) for software supply chain participants.

In OpenChain we are always trying to describe the minimal process required to accomplish a goal around Open Source. In the first instance, we have created a specification describing the minimal process required for what is necessary for due diligence around compliance. Any extensions to OpenChain (or experimental modules that might take a later life of their own) would follow a similar pattern. When talking about security, the idea would not to be to attempt to describe a Software Development Security Domain (ref: http://resources.infosecinstitute.com/cissp-2015-update-software-development-security/) but rather to talk about the type of minimal process required to address security vulnerabilities around Open Source Software (ref:
https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html).

By the same thinking, any extensions to address Export Compliance focused on cryptography or ISO 26262 would not be intended to replace or compete with existing standards, but rather to describe the minimal set of processes we would expect to see around companies deploying Open Source software in these contexts. Anyone adhering to existing standards and best practices would essentially already surpass the minimal requirements laid out. As always, the real goal is to make sure that even the smallest stakeholder in Open Source can introduce or complex with the type of best practices that the largest and most experienced entities have access to, and in the process we gradually transform the global supply chain.

In conclusion, the question is really whether we explore processes beyond compliance. The consensus at our face-to-face was that such further development should not be part of the core specification, but may be worthwhile as extensions. This is not a firm decision that OpenChain should go beyond license compliance. We may come to consensus that OpenChain as a process specification should remain compliance-only and we would cease work on any extensions after a period of experimentation or - as Jonas referenced - such experimental modules may take on a life of their own as another process specification for minimal adherence to requirements for accomplishing other goals around Open Source.

I believe we are all on the same page:
(1) Let’s not confuse compliance with other things
(2) Let’s keep the OpenChain specification clear and focused
(3) But let’s keep an open mind regarding other ways we can make a difference around Open Source in the supply chain

Regards

Shane


Mark Gisi
 

Hi Jonas,

I do believe this makes sense in principle, but it may lead to confusion around the
OpenChain mark if this becomes wide spread and used for many different areas.
You make a very important point which is worth highlighting. The OpenChain mark is one of the greatest assets of the OpenChain project which needs to be managed carefully. We must take the meaning, role, scope of the mark into consideration when discussing extensions. "OpenChain Conformance", first and foremost, should covey that an organization maintains a thoughtful, disciplined and trusted license compliance program. Full stop. There was some discussion (although brief) that a given extension could potentially have its own specification or an *optional* section of the spec where an additional mark (or a mark belong to a family of OpenChain marks) could be used to convey that additional area of trust. Regardless, this is a topic that deserves much more discussion. Thanks for calling it out.

- Mark

-----Original Message-----
From: Jonas Oberg [mailto:jonas@...]
Sent: Tuesday, October 18, 2016 12:13 AM
To: Gisi, Mark
Cc: Jeremiah Foster; Williams, Kelly; openchain@...
Subject: Re: [OpenChain] OpenChain meeting today

Hi Mark, others,

by way of introduction first: for those of you who do not know me, I'm the executive director for the FSFE, but for my participation on this list, I'm speaking for Morus AB, a small consulting firm in Sweden which help companies in their understanding of FOSS.

Without committing to any one new extension, the idea is to set up a
framework where we could experiment (pilot) new types of program
requirements where one wants to establish trust around handling lots
of open source with respect to a given extension type (e.g., security,
export, …)
I do believe this makes sense in principle, but it may lead to confusion around the OpenChain mark if this becomes wide spread and used for many different areas.

Especially security does seem like a useful area to experiment with this on though, and I'd be interested in this. Whether such an experiment then leads to an extension of OpenChain or a certification in itself is probably a later question, and both are certainly possible.


--
Jonas Öberg, Styrelseordförande
Morus konsult AB | jonas@...
E-mail is the fastest way to my attention