Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)


 

Thanks for the great feedback Kate and Mark (on this list) and loads of other people (on our call).

In broad strokes:
(1) we decided to make it *very* clear this was not about variants of OpenChain ISO 5230 but rather about where companies can go next after adoption
(2) we decided to pull back from “quality grading” by the project and instead providing case studies and examples to help inspire companies

Check out the latest (and dramatically overhauled) edit here:
https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc

On Aug 23, 2021, at 23:06, Mark Gisi <mark.gisi@windriver.com> wrote:

One of the core guiding principles for the OpenChain Specification is to focus on the what and why of compliance (and avoid the how and when). This is highlighted in the introduction of the spec. That is avoid being prescriptive.

It was always understood that the OpenChain Project would foster the creation of various materials around best practices to educate how other companies achieve conformance. That is - to describe the prescriptive ways of others. This has not been done with any formal structure yet within the project. The proposed levels approach is the first attempt to do this which I commend. What I disagree with is mixing the specification to tightly with prescriptive ways because it undermines a core principle and purpose of the specification.

I suggest we create a complimentary best practice program/guide that encourages companies to consider various prescriptive levels. That is, have Best Practice Levels (bronze, silver, gold, …) but DON’T confuse it with the spec (which is: about what and why, practice neutral, non-prescriptive, …). For instance, have a program with its own logo (for example - see attached)

best,

Mark Gisi
Director, Open Source Program Office
Empowering Customers to Prosper using Open Source
(510) 749-2016





-----Original Message-----
From: specification@lists.openchainproject.org <specification@lists.openchainproject.org> On Behalf Of Shane Coughlan
Sent: Monday, August 23, 2021 1:43 AM
To: OpenChain Main <main@lists.openchainproject.org>
Cc: OpenChain Japan <japan-wg@lists.openchainproject.org>; OpenChain Korea <korea-wg@lists.openchainproject.org>; OpenChain Germany <germany-wg@lists.openchainproject.org>; OpenChain India <india-wg@lists.openchainproject.org>; OpenChain UK <uk-wg@lists.openchainproject.org>; OpenChain Partners <partners@lists.openchainproject.org>; OpenChain Automotive <openchain-automotive-work-group@groups.io>; OpenChain Tooling <oss-based-compliance-tooling@groups.io>; OpenChain Specification <specification@lists.openchainproject.org>
Subject: [specification] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

[Please note: This e-mail is from an EXTERNAL e-mail address]

Dear all

During a recent OpenChain Japan Planning meeting we discussed the challenge of “next steps” in OpenChain ISO 5230 conformance. Our initial goal of adoption in the supply chain is well underway. Our basic concept of “raising all the boats” is working. But now it is time to talk in more detail about “raising the boats to where?”

From its launch in October 2016 until today, the OpenChain Project has been based on the concept of continual improvement (or Kaizen). We can now provide a “map” to help guide companies in this process, and to help customer companies judge the sophistication of suppliers who have adopted OpenChain ISO 5230.

Attached is a slide-deck exploring how this can be done. We will be discussing this in the OpenChain bi-weekly global work team meeting today (Monday 23rd of August) at 14:00 UTC. All welcome. No registration.
https://zoom.us/j/4377592799

You can add comments to this document online:
https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc

Regards

Shane












<ocbp-logo.jpg>


Steve Kilbane
 

Hi Shane,

As a comment on the revised slides, slide 10 doesn't work for me, since it shows a cycle, but you wouldn't go from your intended end-point (audit done) back to "just" OpenChain compliance without SBOM or automation.

As noted on the call, these aren't linear journeys, and an organisation could collect these plot tokens by wandering the map in whichever order they choose. They may add external audit first, then automation, then use that automation to produce their SBOMs.

I did like the idea of identifying them as best practices rather than "levels", because they can be adopted in any order. I did wonder whether it made sense to have a receiver award the SBOM badge to the supplier, but that might be problematic with respect to confidential business arrangements.

It would be nice if there were an SBOM badge that could be awarded to open source projects that are producing suitable output - uses SPDX Ids, includes an SBOM - but that's probably more down to the SPDX project than the OpenChain project.

steve

-----Original Message-----
From: main@lists.openchainproject.org <main@lists.openchainproject.org> On Behalf Of Shane Coughlan
Sent: 24 August 2021 08:00
To: OpenChain Main <main@lists.openchainproject.org>
Cc: OpenChain Specification <specification@lists.openchainproject.org>; OpenChain Japan <japan-wg@lists.openchainproject.org>; OpenChain Korea <korea-wg@lists.openchainproject.org>; OpenChain Germany <germany-wg@lists.openchainproject.org>; OpenChain UK <uk-wg@lists.openchainproject.org>; OpenChain Partners <partners@lists.openchainproject.org>; OpenChain Automotive <openchain-automotive-work-group@groups.io>; OpenChain Tooling <oss-based-compliance-tooling@groups.io>; OpenChain India <india-wg@lists.openchainproject.org>
Subject: Re: [openchain] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

[External]

Thanks for the great feedback Kate and Mark (on this list) and loads of other people (on our call).

In broad strokes:
(1) we decided to make it *very* clear this was not about variants of OpenChain ISO 5230 but rather about where companies can go next after adoption
(2) we decided to pull back from “quality grading” by the project and instead providing case studies and examples to help inspire companies

Check out the latest (and dramatically overhauled) edit here:
https://urldefense.com/v3/__https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc__;!!A3Ni8CS0y2Y!rSyuQmZ37tkXPfAEMCXKiRLUbYiVBKpseV5yI3tiH0QCwRW-ScqwcILPLBoN9cDiU-x-$

On Aug 23, 2021, at 23:06, Mark Gisi <mark.gisi@windriver.com> wrote:

One of the core guiding principles for the OpenChain Specification is to focus on the what and why of compliance (and avoid the how and when). This is highlighted in the introduction of the spec. That is avoid being prescriptive.

It was always understood that the OpenChain Project would foster the creation of various materials around best practices to educate how other companies achieve conformance. That is - to describe the prescriptive ways of others. This has not been done with any formal structure yet within the project. The proposed levels approach is the first attempt to do this which I commend. What I disagree with is mixing the specification to tightly with prescriptive ways because it undermines a core principle and purpose of the specification.

I suggest we create a complimentary best practice program/guide that encourages companies to consider various prescriptive levels. That is, have Best Practice Levels (bronze, silver, gold, …) but DON’T confuse it with the spec (which is: about what and why, practice neutral, non-prescriptive, …). For instance, have a program with its own logo (for example - see attached)

best,

Mark Gisi
Director, Open Source Program Office
Empowering Customers to Prosper using Open Source
(510) 749-2016





-----Original Message-----
From: specification@lists.openchainproject.org <specification@lists.openchainproject.org> On Behalf Of Shane Coughlan
Sent: Monday, August 23, 2021 1:43 AM
To: OpenChain Main <main@lists.openchainproject.org>
Cc: OpenChain Japan <japan-wg@lists.openchainproject.org>; OpenChain Korea <korea-wg@lists.openchainproject.org>; OpenChain Germany <germany-wg@lists.openchainproject.org>; OpenChain India <india-wg@lists.openchainproject.org>; OpenChain UK <uk-wg@lists.openchainproject.org>; OpenChain Partners <partners@lists.openchainproject.org>; OpenChain Automotive <openchain-automotive-work-group@groups.io>; OpenChain Tooling <oss-based-compliance-tooling@groups.io>; OpenChain Specification <specification@lists.openchainproject.org>
Subject: [specification] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

[Please note: This e-mail is from an EXTERNAL e-mail address]

Dear all

During a recent OpenChain Japan Planning meeting we discussed the challenge of “next steps” in OpenChain ISO 5230 conformance. Our initial goal of adoption in the supply chain is well underway. Our basic concept of “raising all the boats” is working. But now it is time to talk in more detail about “raising the boats to where?”

From its launch in October 2016 until today, the OpenChain Project has been based on the concept of continual improvement (or Kaizen). We can now provide a “map” to help guide companies in this process, and to help customer companies judge the sophistication of suppliers who have adopted OpenChain ISO 5230.

Attached is a slide-deck exploring how this can be done. We will be discussing this in the OpenChain bi-weekly global work team meeting today (Monday 23rd of August) at 14:00 UTC. All welcome. No registration.
https://urldefense.com/v3/__https://zoom.us/j/4377592799__;!!A3Ni8CS0y2Y!rSyuQmZ37tkXPfAEMCXKiRLUbYiVBKpseV5yI3tiH0QCwRW-ScqwcILPLBoN9QooyMCh$

You can add comments to this document online:
https://urldefense.com/v3/__https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc__;!!A3Ni8CS0y2Y!rSyuQmZ37tkXPfAEMCXKiRLUbYiVBKpseV5yI3tiH0QCwRW-ScqwcILPLBoN9cDiU-x-$

Regards

Shane












<ocbp-logo.jpg>


Matija Šuklje
 

Die 24. 08. 21 et hora 09:00 Shane Coughlan scripsit:
In broad strokes:
(1) we decided to make it *very* clear this was not about variants of
OpenChain ISO 5230 but rather about where companies can go next after
adoption
(2) we decided to pull back from “quality grading” by the project
and instead providing case studies and examples to help inspire companies
This sounds like a sane approach to me.

Check out the latest (and dramatically overhauled) edit here:
https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc
After opening the slide deck today, I was wondering what the complaints were
against :)

The slides look OK to me at the time of this writing.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@gabbler.org
sip: matija_suklje@ippi.fr


 

Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

Shane

On Aug 24, 2021, at 16:35, Steve Kilbane <stephen.kilbane@...> wrote:

Hi Shane,

As a comment on the revised slides, slide 10 doesn't work for me, since it shows a cycle, but you wouldn't go from your intended end-point (audit done) back to "just" OpenChain compliance without SBOM or automation.

As noted on the call, these aren't linear journeys, and an organisation could collect these plot tokens by wandering the map in whichever order they choose. They may add external audit first, then automation, then use that automation to produce their SBOMs.

I did like the idea of identifying them as best practices rather than "levels", because they can be adopted in any order. I did wonder whether it made sense to have a receiver award the SBOM badge to the supplier, but that might be problematic with respect to confidential business arrangements.

It would be nice if there were an SBOM badge that could be awarded to open source projects that are producing suitable output - uses SPDX Ids, includes an SBOM - but that's probably more down to the SPDX project than the OpenChain project.

steve


Jari Koivisto
 

Hi All,

I think that this new slide 10 is better now. It might add unnecessary complexity, but maybe each of the 4 arrows could have a small loop arrow on top depicting the nature of iterative work involved at each state, e.g. a company may try several types of automation to create the artefacts. 

   Jari


---
Jari Koivisto
E-mail: jari.p.koivisto@...
Mobile: +41 78 7479791
Skype: jari.p.koivisto
LinkedIn: http://www.linkedin.com/in/jarikoivisto



On Wed, 25 Aug 2021 at 07:16, Shane Coughlan <scoughlan@...> wrote:
Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

Shane

On Aug 24, 2021, at 16:35, Steve Kilbane <stephen.kilbane@...> wrote:

Hi Shane,

As a comment on the revised slides, slide 10 doesn't work for me, since it shows a cycle, but you wouldn't go from your intended end-point (audit done) back to "just" OpenChain compliance without SBOM or automation.

As noted on the call, these aren't linear journeys, and an organisation could collect these plot tokens by wandering the map in whichever order they choose. They may add external audit first, then automation, then use that automation to produce their SBOMs.

I did like the idea of identifying them as best practices rather than "levels", because they can be adopted in any order. I did wonder whether it made sense to have a receiver award the SBOM badge to the supplier, but that might be problematic with respect to confidential business arrangements.

It would be nice if there were an SBOM badge that could be awarded to open source projects that are producing suitable output - uses SPDX Ids, includes an SBOM - but that's probably more down to the SPDX project than the OpenChain project.

steve


Jacob Wilson
 

I agree with Steve’s sentiment of wandering tokens, in my opinion levels of assurance with progressive technology independent criteria are required.

Borrowing from other ISO standards, I propose these "levels" outline a 1) goal 2) business case 3) metric. Goal criteria should increment as assurance or level of trust is achieved, while the case and metric move as the technology and supplier landscape change around the business.

 

In the below table I outline one view of this concept:

  • Let’s say for example SBoM incorporates distributed ledger technology as discussed in other conversation threads. First the organization would build the business case around adapting SBoM technology to include blockchain, then they would establish a viable metric to measure this business justification. Ultimately the goal would remain intact because it was forward thinking and progressive in level of assurance.
  • Now let’s say that an organization is considering the move from internal assessment of OpenChain ISO 5230 to an external 3rd party assessment. They may revise their business case from “Prevent uncertainty through alignment with OpenChain ISO 5230” to “Prevent bias and uncertainty through independent confirmation of OpenChain ISO 5230 compliance”. The Metric remains intact to facilitate the audit process and the goal of dedicating assurance resources remains intact as well.

 

These are a couple of ways we can move along the field while keeping the goal posts intact. Of course I’m always open to feedback, and I realize this doesn’t prevent an organization from collecting artifacts of conformance (silver) before establishing a management framework (bronze). But we can see the crawl, walk, run analogy in the progression in levels of assurance (goals).. Perhaps platinum level is hiring Toni Kroos for 3rd party assessment.

 

 

 

Jacob Wilson

Senior Security Consultant
M: 773-372-8868 | jacob.wilson@...

Synopsys Software Integrity Group (SIG)

http://www.synopsys.com/software

 

From: main@... <main@...> On Behalf Of Jari Koivisto
Sent: Wednesday, August 25, 2021 4:36 AM
To: OpenChain Main <main@...>
Subject: Re: [openchain] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

Hi All,

 

I think that this new slide 10 is better now. It might add unnecessary complexity, but maybe each of the 4 arrows could have a small loop arrow on top depicting the nature of iterative work involved at each state, e.g. a company may try several types of automation to create the artefacts. 

 

   Jari

 


---
Jari Koivisto
E-mail: jari.p.koivisto@...
Mobile: +41 78 7479791
Skype: jari.p.koivisto
LinkedIn: http://www.linkedin.com/in/jarikoivisto

 

 

On Wed, 25 Aug 2021 at 07:16, Shane Coughlan <scoughlan@...> wrote:

Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

 

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

 

Shane



On Aug 24, 2021, at 16:35, Steve Kilbane <stephen.kilbane@...> wrote:

Hi Shane,

As a comment on the revised slides, slide 10 doesn't work for me, since it shows a cycle, but you wouldn't go from your intended end-point (audit done) back to "just" OpenChain compliance without SBOM or automation.

As noted on the call, these aren't linear journeys, and an organisation could collect these plot tokens by wandering the map in whichever order they choose. They may add external audit first, then automation, then use that automation to produce their SBOMs.

I did like the idea of identifying them as best practices rather than "levels", because they can be adopted in any order. I did wonder whether it made sense to have a receiver award the SBOM badge to the supplier, but that might be problematic with respect to confidential business arrangements.

It would be nice if there were an SBOM badge that could be awarded to open source projects that are producing suitable output - uses SPDX Ids, includes an SBOM - but that's probably more down to the SPDX project than the OpenChain project.

steve


Christopher Wood
 

Hello all
This is a great discussion.  I do like Jacob's suggestion with some simple notation that indicates that the "levels" or whatever you call them are cumulative going from the base (Level 1 up through Level 4).  I also believe that formal adoption of each level's requirements will become necessary for any "vendor or supplier" due to market demands and agree with Shane that they should probably not be dictated by the OpenChain Project.  To show that the additive features of the Chart 10 could be added to an inverted stack of the levels. (Level 1 is foundational to the concept and building on Level 1 gives you advanced capabilities as a 4th column.



On Wednesday, August 25, 2021, 10:52:57 AM CDT, Jacob Wilson via lists.openchainproject.org <jacob.wilson=synopsys.com@...> wrote:


I agree with Steve’s sentiment of wandering tokens, in my opinion levels of assurance with progressive technology independent criteria are required.

Borrowing from other ISO standards, I propose these "levels" outline a 1) goal 2) business case 3) metric. Goal criteria should increment as assurance or level of trust is achieved, while the case and metric move as the technology and supplier landscape change around the business.

 

In the below table I outline one view of this concept:

  • Let’s say for example SBoM incorporates distributed ledger technology as discussed in other conversation threads. First the organization would build the business case around adapting SBoM technology to include blockchain, then they would establish a viable metric to measure this business justification. Ultimately the goal would remain intact because it was forward thinking and progressive in level of assurance.
  • Now let’s say that an organization is considering the move from internal assessment of OpenChain ISO 5230 to an external 3rd party assessment. They may revise their business case from “Prevent uncertainty through alignment with OpenChain ISO 5230” to “Prevent bias and uncertainty through independent confirmation of OpenChain ISO 5230 compliance”. The Metric remains intact to facilitate the audit process and the goal of dedicating assurance resources remains intact as well.

 

These are a couple of ways we can move along the field while keeping the goal posts intact. Of course I’m always open to feedback, and I realize this doesn’t prevent an organization from collecting artifacts of conformance (silver) before establishing a management framework (bronze). But we can see the crawl, walk, run analogy in the progression in levels of assurance (goals).. Perhaps platinum level is hiring Toni Kroos for 3rd party assessment.

 

 

 

Jacob Wilson

Senior Security Consultant
M: 773-372-8868 | jacob.wilson@...

Synopsys Software Integrity Group (SIG)

http://www.synopsys.com/software

 

From: main@... <main@...> On Behalf Of Jari Koivisto
Sent: Wednesday, August 25, 2021 4:36 AM
To: OpenChain Main <main@...>
Subject: Re: [openchain] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

Hi All,

 

I think that this new slide 10 is better now. It might add unnecessary complexity, but maybe each of the 4 arrows could have a small loop arrow on top depicting the nature of iterative work involved at each state, e.g. a company may try several types of automation to create the artefacts. 

 

   Jari

 


---
Jari Koivisto
E-mail: jari.p.koivisto@...
Mobile: +41 78 7479791
Skype: jari.p.koivisto
LinkedIn: http://www.linkedin.com/in/jarikoivisto

 

 

On Wed, 25 Aug 2021 at 07:16, Shane Coughlan <scoughlan@...> wrote:

Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

 

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

 

Shane



On Aug 24, 2021, at 16:35, Steve Kilbane <stephen.kilbane@...> wrote:

Hi Shane,

As a comment on the revised slides, slide 10 doesn't work for me, since it shows a cycle, but you wouldn't go from your intended end-point (audit done) back to "just" OpenChain compliance without SBOM or automation.

As noted on the call, these aren't linear journeys, and an organisation could collect these plot tokens by wandering the map in whichever order they choose. They may add external audit first, then automation, then use that automation to produce their SBOMs.

I did like the idea of identifying them as best practices rather than "levels", because they can be adopted in any order. I did wonder whether it made sense to have a receiver award the SBOM badge to the supplier, but that might be problematic with respect to confidential business arrangements.

It would be nice if there were an SBOM badge that could be awarded to open source projects that are producing suitable output - uses SPDX Ids, includes an SBOM - but that's probably more down to the SPDX project than the OpenChain project.

steve


 

All, context slides at link:
https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc

Jari, I think it’s a good idea, but I also fear it might add a little too much complexity at this time. How about we see how the slides are understood in Asia etc., seeing if any confusion exists, before action?

On Aug 25, 2021, at 17:35, Jari Koivisto <jari.p.koivisto@iki.fi> wrote:

Hi All,

I think that this new slide 10 is better now. It might add unnecessary complexity, but maybe each of the 4 arrows could have a small loop arrow on top depicting the nature of iterative work involved at each state, e.g. a company may try several types of automation to create the artefacts.

Jari


 

All, context slides at link:

During our last call we had some strong push-back in terms of the project itself defining levels of competence. However, we may have an elegant way forward.

If the project defines the context (continual improvement), we can leave the specific implementation to the market with a natural dynamic addressing the “are people just making stuff up?”

For fields like defense, automotive and aerospace, some companies are likely to prefer third-party certification rather than self-certification in the context of procurement. This creates a market opportunity for companies like PwC or Hitachi Solutions to consider the product they offer. Currently it runs along the lines of “OpenChain certified and occasionally audited as per the standard”, but with our signaling for evolution, it makes sense for PwC and Hitachi Solutions to diversify and offered stepped products. This is to their benefit (more product) and to the community benefit (third-party grading if desired). 

While not being intrusive, the project and broader community can signal through official examples and case studies that provide a mental model for where grading may land. For example, this is slide 10 of the current deck:

The most important feedback we received is that no one should feel undervalued for having reached OpenChain ISO 5230 conformance. Adoption of the standard itself is transformative for the ecosystem, and we do not want to dilute that. That said, it is useful to offer inspiration when the question of “what next?” is raised.

On Aug 26, 2021, at 0:52, Jacob Wilson via lists.openchainproject.org <Jacob.Wilson=synopsys.com@...> wrote:

I agree with Steve’s sentiment of wandering tokens, in my opinion levels of assurance with progressive technology independent criteria are required.
Borrowing from other ISO standards, I propose these "levels" outline a 1) goal 2) business case 3) metric. Goal criteria should increment as assurance or level of trust is achieved, while the case and metric move as the technology and supplier landscape change around the business.
 
In the below table I outline one view of this concept:
• Let’s say for example SBoM incorporates distributed ledger technology as discussed in other conversation threads. First the organization would build the business case around adapting SBoM technology to include blockchain, then they would establish a viable metric to measure this business justification. Ultimately the goal would remain intact because it was forward thinking and progressive in level of assurance.
• Now let’s say that an organization is considering the move from internal assessment of OpenChain ISO 5230 to an external 3rd party assessment. They may revise their business case from “Prevent uncertainty through alignment with OpenChain ISO 5230” to “Prevent bias and uncertainty through independent confirmation of OpenChain ISO 5230 compliance”. The Metric remains intact to facilitate the audit process and the goal of dedicating assurance resources remains intact as well.
 
These are a couple of ways we can move along the field while keeping the goal posts intact. Of course I’m always open to feedback, and I realize this doesn’t prevent an organization from collecting artifacts of conformance (silver) before establishing a management framework (bronze). But we can see the crawl, walk, run analogy in the progression in levels of assurance (goals).. Perhaps platinum level is hiring Toni Kroos for 3rd party assessment.


 

It does appear this mental model can provide an avenue forward.

Speculation: if the market(s) dictate various concepts of evolution, we will probably see differentiation by sector regarding preferred evolution paths. For example, what aerospace and defense sees as natural may be alien to automotive, despite neither sector being better or worse in where they land. This applies with perhaps greater contrast when we consider sectors like consumer electronics or consumables. When a cigarette company (for example) thinks about continual evolution of their compliance program, where they land will probably be significantly different to where a global phone-maker lands.

This is no bad thing. It provides plenty space for user-company groupings or third-party certifiers to model grading for open source license compliance programs. And it does not undermine the fact that OpenChain ISO 5230 defines the key requirements of a quality open source compliance program.

On Aug 26, 2021, at 6:22, Christopher Wood <cvw01@...> wrote:

Hello all
This is a great discussion.  I do like Jacob's suggestion with some simple notation that indicates that the "levels" or whatever you call them are cumulative going from the base (Level 1 up through Level 4).  I also believe that formal adoption of each level's requirements will become necessary for any "vendor or supplier" due to market demands and agree with Shane that they should probably not be dictated by the OpenChain Project.  To show that the additive features of the Chart 10 could be added to an inverted stack of the levels. (Level 1 is foundational to the concept and building on Level 1 gives you advanced capabilities as a 4th column.