OpenChain Legal
Work Group
2024-01-17
Anti-Trust Policy Notice
● Linux Foundation meetings involve participation by industry competitors, and it is the intention
of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust
and competition laws. It is therefore extremely important that attendees adhere to meeting
agendas, and be aware of, and not participate in, any activities that are prohibited under
applicable US state, federal or foreign antitrust and competition laws.
● Examples of types of actions that are prohibited at Linux Foundation meetings and in
connection with Linux Foundation activities are described in the Linux Foundation Antitrust
Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about
these matters, please contact your company counsel, or if you are a member of the Linux
Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP,
which provides legal counsel to the Linux Foundation.
Agenda
1. Meeting Overview
2. Maturity Model Presentation by Andrew Katz of Orcro
3. Any Other Business
4. End of Meeting
Meeting Overview
This meeting will provide an overview of maturity models related to assessing
competence around open source management.
It has a particular focus on a maturity model from Orcro based on ISO/IEC
5230:2020.
We will also discuss how OpenChain Project can improve reference material in
this area.
Maturity Models – Andrew Katz
Open Chain Maturity Model
Roadmap
Capability Maturity Model – What is a CMM?
A framework for determining the degree of capability,
adaptability and resilience of a business function within
an organisation, with the aim of optimising continuous
improvement.
Maturity Model – High Level Approach
Indicative levels of maturity
• INITIAL: Minimal knowledge of open source compliance practice and procedure
• REPEATABLE: Some steps towards compliance. Some systems in place, but
application ad hoc
• DEFINED/IMPLEMENTED: Policies, practice and procedure in place, but not
necessarily in operation
• MANAGED: Policies etc. in place, and in operation, and improved as considered
necessary
• OPTIMISING: Policies etc. in place, in operation, and actively managed using
appropriate metrics and a process of continuous improvement.
Maturity Model – High Level Approach
59%
38%
64%
50%
5
4
3
2
1
Measured
Maturity
Score
Target
Systems
Information
People &
Organisation
Process
Optimising
Managed
Defined / Implemented
Repeatable
Initial
The capabilities of the organisation that have
been developed to manage open source
software development will be considered
against the requirements of the OpenChain
Specification v2.1, ISO/IEC 5230:2020.
They will be categorised into four types of
capability; people and organisational, process,
information, and systems.
Maturity will be assessed against five levels of
completeness as shown.
The target level will be specific to each
organisation and can be set according to their
ambition and view of business risk and
priorities for delivery.
The gap between target level and measured
level presents defines opportunities for
improvement and is easily converted to
implementation plans,
OpenChain Provides a Potential Framework
1. The Specification (ISO 5230:2020) contains the set of characteristics that a quality
Open Source development function possess within an organisation.
2. Each OpenChain requirement can be mapped against a business function, and a
degree of maturity can be assigned to each business function.
3. We propose a hierarchy. Top level requirements will be applicable across all
organisations.
4. Second level requirements can be tailored to the method of implementation chosen
by the organisation.
5. It’s compatible with existing best practice in capability maturity modelling across the
whole range of an organisation’s business functions, not just software development
(or open source software development).
ISO Requirements and Processes
Governance Strategy and Oversight
1
3.1.1 Policy
Appoint policy author, owner, exec sponsor
Publish policy
Review policy
Distribute policy
Track awareness of policy
Review performance against policy
objectives
Enablement and Performance Management
3.1.4 Program scope
Define programme scope
Review appropriateness of programme
scope
Define risks to be managed
Define benefits to be achieved
3.1.2 Competence
Identify roles and responsibilities
Determine competence required
Determine training need
Assess competence achieved
3.2.2 Effectively
resourced
Review programme resourcing and funding
Track progress against policy objectives
Analyse progress against policy objectives
3.5.1 Contributions
Develop policy for contributions (in and outbound)
Review and maintain policy
Track progress against policy
Review performance (risks and benefits)
3.1.3 Awareness
Communicate open source and
contribution policy
Track awareness of policies
Communicate implications of non-
compliance
Track non-compliance events
Track awareness of contribution policy
Open Chain Delivery
3.6.1 Conformance,
3.6.2 Duration
Review OpenChain
conformance (18 month)
Manage 3rd party
certification
3.1.5 License
Obligations
Identify licenses in
use
Document license
obligations
3.3.2 License
Compliance
review license compliance
across distribution modes
Produce contributions
guidelines for contributors
3.3.1 Bill of
Materials
Produce SBOM
Review and approve SBOM
Maintain version and distribution
history
Licence analysis
Produce records of process followed
3.4.1 Compliance
Artifacts
Generate artefacts
Distribute artifacts
Record artifacts
3.2.1 Access
Respond to compliance inquiries
Track nature of response to inquiries
Review performance of inquiry responses
Example assessment
3.3.1 Bill of Materials
People and Organisation Capability Processes Capabiliity
Attributes P&O Maturity
Questions
Process Attributes Process Maturity
Questions
Key role holders
Development Team
Leader
Associated roles
DevOps Specialist
Does a role exist for
generating (or
maintaining the system
which generates)
SBOMs?
Are role/responsibility
holders suitably
trained?
Do role/responsibility
holders have the
necessary
competencies?
Key processes
Produce SBOM
Review and approve
SBOM
Maintain version and
distribution history
Produce records of
process followed
Does a process exist
(automated or not) for
generating SBOMs?
Does a process exist for
reviewing and approving
SBOMs?
As part of any process
involving SBOMs, are
suitable records kept?
Information Capability Systems Capability
Information
Attributes
Information maturity
question
Systems Attributes Systems Maturity
Questions
Key Information
Component
manifests
Correct SBOMs
SBOM records &
metadata
Are component manifests
made available for
compliance purposes?
Are SBOMs generated?
Do SBOMs contain
sufficient correct data for
licence compliance?*
Are SBOMs generated in a
way which facilitates other
risk management or
operational processes (e.g.
security/vulnerability or
export control)
Are standards (e.g. SPDX,
CycloneDX) used to
generate SBOMs
Are the standards used to
generate SBOMs consistent
across the organisation?
Key systems
Compliance
toolchain*
Emerging good
practice
Metadata repository
(such as SW360)
Does the compliance
toolchain have
functionality for
generating SBOMs?
Where issues are
identified (e.g., a failing
test) is it possible to
remedy the issue in-situ?
Is compliance metadata
stored in a suitable system
such as SW360?
Full Profile Assessment
Rapid view of gaps and priorities
Deeper analysis possible by each
of the four capability lenses.
Supports optimisation of open
chain programme
Any Other Business?
Close of Meeting

OpenChain Legal Work Group - 2024-01-17

  • 1.
  • 2.
    Anti-Trust Policy Notice ●Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. ● Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.
  • 3.
    Agenda 1. Meeting Overview 2.Maturity Model Presentation by Andrew Katz of Orcro 3. Any Other Business 4. End of Meeting
  • 4.
    Meeting Overview This meetingwill provide an overview of maturity models related to assessing competence around open source management. It has a particular focus on a maturity model from Orcro based on ISO/IEC 5230:2020. We will also discuss how OpenChain Project can improve reference material in this area.
  • 5.
  • 6.
    Open Chain MaturityModel Roadmap
  • 7.
    Capability Maturity Model– What is a CMM? A framework for determining the degree of capability, adaptability and resilience of a business function within an organisation, with the aim of optimising continuous improvement.
  • 8.
    Maturity Model –High Level Approach Indicative levels of maturity • INITIAL: Minimal knowledge of open source compliance practice and procedure • REPEATABLE: Some steps towards compliance. Some systems in place, but application ad hoc • DEFINED/IMPLEMENTED: Policies, practice and procedure in place, but not necessarily in operation • MANAGED: Policies etc. in place, and in operation, and improved as considered necessary • OPTIMISING: Policies etc. in place, in operation, and actively managed using appropriate metrics and a process of continuous improvement.
  • 9.
    Maturity Model –High Level Approach 59% 38% 64% 50% 5 4 3 2 1 Measured Maturity Score Target Systems Information People & Organisation Process Optimising Managed Defined / Implemented Repeatable Initial The capabilities of the organisation that have been developed to manage open source software development will be considered against the requirements of the OpenChain Specification v2.1, ISO/IEC 5230:2020. They will be categorised into four types of capability; people and organisational, process, information, and systems. Maturity will be assessed against five levels of completeness as shown. The target level will be specific to each organisation and can be set according to their ambition and view of business risk and priorities for delivery. The gap between target level and measured level presents defines opportunities for improvement and is easily converted to implementation plans,
  • 10.
    OpenChain Provides aPotential Framework 1. The Specification (ISO 5230:2020) contains the set of characteristics that a quality Open Source development function possess within an organisation. 2. Each OpenChain requirement can be mapped against a business function, and a degree of maturity can be assigned to each business function. 3. We propose a hierarchy. Top level requirements will be applicable across all organisations. 4. Second level requirements can be tailored to the method of implementation chosen by the organisation. 5. It’s compatible with existing best practice in capability maturity modelling across the whole range of an organisation’s business functions, not just software development (or open source software development).
  • 11.
    ISO Requirements andProcesses Governance Strategy and Oversight 1 3.1.1 Policy Appoint policy author, owner, exec sponsor Publish policy Review policy Distribute policy Track awareness of policy Review performance against policy objectives Enablement and Performance Management 3.1.4 Program scope Define programme scope Review appropriateness of programme scope Define risks to be managed Define benefits to be achieved 3.1.2 Competence Identify roles and responsibilities Determine competence required Determine training need Assess competence achieved 3.2.2 Effectively resourced Review programme resourcing and funding Track progress against policy objectives Analyse progress against policy objectives 3.5.1 Contributions Develop policy for contributions (in and outbound) Review and maintain policy Track progress against policy Review performance (risks and benefits) 3.1.3 Awareness Communicate open source and contribution policy Track awareness of policies Communicate implications of non- compliance Track non-compliance events Track awareness of contribution policy Open Chain Delivery 3.6.1 Conformance, 3.6.2 Duration Review OpenChain conformance (18 month) Manage 3rd party certification 3.1.5 License Obligations Identify licenses in use Document license obligations 3.3.2 License Compliance review license compliance across distribution modes Produce contributions guidelines for contributors 3.3.1 Bill of Materials Produce SBOM Review and approve SBOM Maintain version and distribution history Licence analysis Produce records of process followed 3.4.1 Compliance Artifacts Generate artefacts Distribute artifacts Record artifacts 3.2.1 Access Respond to compliance inquiries Track nature of response to inquiries Review performance of inquiry responses
  • 12.
    Example assessment 3.3.1 Billof Materials People and Organisation Capability Processes Capabiliity Attributes P&O Maturity Questions Process Attributes Process Maturity Questions Key role holders Development Team Leader Associated roles DevOps Specialist Does a role exist for generating (or maintaining the system which generates) SBOMs? Are role/responsibility holders suitably trained? Do role/responsibility holders have the necessary competencies? Key processes Produce SBOM Review and approve SBOM Maintain version and distribution history Produce records of process followed Does a process exist (automated or not) for generating SBOMs? Does a process exist for reviewing and approving SBOMs? As part of any process involving SBOMs, are suitable records kept? Information Capability Systems Capability Information Attributes Information maturity question Systems Attributes Systems Maturity Questions Key Information Component manifests Correct SBOMs SBOM records & metadata Are component manifests made available for compliance purposes? Are SBOMs generated? Do SBOMs contain sufficient correct data for licence compliance?* Are SBOMs generated in a way which facilitates other risk management or operational processes (e.g. security/vulnerability or export control) Are standards (e.g. SPDX, CycloneDX) used to generate SBOMs Are the standards used to generate SBOMs consistent across the organisation? Key systems Compliance toolchain* Emerging good practice Metadata repository (such as SW360) Does the compliance toolchain have functionality for generating SBOMs? Where issues are identified (e.g., a failing test) is it possible to remedy the issue in-situ? Is compliance metadata stored in a suitable system such as SW360?
  • 13.
    Full Profile Assessment Rapidview of gaps and priorities Deeper analysis possible by each of the four capability lenses. Supports optimisation of open chain programme
  • 14.
  • 15.