OpenChain Legal Work Group - 2024-01-17

1. OpenChain Legal
Work Group
2024-01-17

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

5. Maturity Models – Andrew Katz

6. Open Chain Maturity Model
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 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).

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

12. 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?

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

14. Any Other Business?

15. Close of Meeting