ABCDEFGHIJKLMNOPQRSTUVWXYZAAAB
1
Capability model - 10,000m View
2
ISO 5230:2020
3
O/C referenceOC TextCatMM1MM2MM2.5MM3MM4MM5
4
InitialRepeatableDefinedDefined/ImplementedManagedOptimising
5
3RequirementsH
6
3.1Program foundationH
7
3.1.1PolicyH
8
3.1.1.0A written open source policy exists that governs open source license compliance of the supplied software. The policy must be internally communicated.RQ
9
3.1.1.1A documented open source policy.VMThe policy consists of a set of requirements, which is uncoordinated, and may exist as an ad-hoc list of management memos, emails, and meeting minutesThe policy consists of a consistent set of documents, but they are uncoordinated and not implemented in an official policy documentThere is an official policy of policy document which contains a policy which fulfils the basic requirements of OpenChainThere is an official policy of policy document which contains a policy which fulfils the basic requirements of OpenChain, and the policy is in operation.As MM3, but the policy is in operation, and is regularly managed, managed, monitored and reviewed to check that it is effectiveAs MM4, but metrics are set for effectiveness, and those metrics are used to improve the policy over time, and also to ensure that any identified issues are responded to, addressed in the policy (if necessary). The benchmarks can be used to compare the effectiveness of the policy with previous iterations, and also across different dev teams.
10
3.1.1.2A documented procedure that makes program participants aware of the existence of the open source policy (e.g., via training, internal wiki, or other practical communication method).VMSee also 3.1.3 (awareness)Staff are told about the existence of open source requirements from time to time, but not in any formal way.Staff are told about open source requirements, and are required to inform themselves of those requirements from time to time.Staff are told about the official policy document using an official channel from time to time. As MM2.5, but steps are taken to ensure the staff have read the documentationAs MM3, but the staff awareness of the policy is monitored and steps are taken to address any deficiencies in staff awareness.As MM4, but metrics are set for effectiveness, and those metrics are used to improve the process of staff awareness, and also to ensure that any identified issues are responded to, by adapting the awareness modes (if necessary). The benchmarks can be used to compare the effectiveness of awareness with previous iterations, and also across different dev teams.
11
3.1.1.RTo ensure steps are taken to create, record and make program participants aware of the existence of an open source policy. Although no requirements are provided here on what should be included in the policy, other sections may impose requirements on the policy.RT
12
3.1.2CompetenceH
13
3.1.2.0The organization shall:
• Identify the roles and the corresponding responsibilities of those roles that affects the performance and effectiveness of the program;
• Determine the necessary competence of program participants fulfilling each role
• Ensure that program participants are competent on the basis of appropriate education, training, and/or experience;
• Where applicable, take actions to acquire the necessary competence; and
• Retain appropriate documented information as evidence of competence.		RQ
14
3.1.2.1A documented list of roles with corresponding responsibilities for the different participants in the program.VMStaff are allocated Open Source compliance roles on an ad-hoc basisThere is a high-level list of roles, and staff are allocated to those roles on an ad-hoc basisThe list of roles is defined, and staff are allocated to each role taking into account the necessary competenciesThe list of roles is defined, and staff taken the allocated rolesAs MM3, but the list of roles and staff allocations are actively managed, although there is no formal set of metrics to assess this.As MM4, but there is a formal set of metrics which identifies whether those responsibilities are being fulfilled
15
3.1.2.2A document that identifies the competencies for each role.VMThere is no formal correspondence between roles and competencies.There is a broad understanding of what skills are associated with each individual, but not necessariy in relation to each roleThere is a list of the necessary roles and the competencies required by each roleAs MM2.5As MM3, but the list of roles and competencies is reviewed from time to time on an ad-hoc basis, and to react to changes in personnel/structureAs MM4, but the set of roles and competenties is pro-actively managed prior to implementating any relevant changes in personnel/structure
16
TX
17
3.1.2.3Documented evidence of assessed competence for each program participant.VMThere is no formal record, but the staff would have asked if they thought they were able to do the taskThere is a process to assess the competence of staff against requirements, even if that assessment has not yet been carried out
18
3.1.2.RTo ensure that the program participants have obtained a sufficient level of competence for their respective roles and responsibilities.RT
19
3.1.3AwarenessH
20
3.1.3.0The organization shall ensure that the program participants are aware of:
• The open source policy;
• Relevant open source objectives;
• Their contribution to the effectiveness of the program; and
• The implications of not following the program’s requirements.		RQ
21
3.1.3.1Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, one’s contribution within the program, and implications of program non-conformance.VM
22
3.1.3.RTo ensure the program participants have obtained a sufficient level of awareness for their respective roles and responsibilities within the program.RT
23
3.1.4Program scopeH
24
3.1.4.0Different programs may be governed by different levels of scope. For example, a program could govern a single product line, an entire department or an entire organization. The scope designation needs to be declared for each program.RQ
25
3.1.4.1A written statement that clearly defines the scope and limits of the program.VM
26
3.1.4.RTo provide the flexibility to construct a program that best fits the scope of an organization’s needs. Some organizations could choose to maintain a program for a specific product line while others could implement a program to govern the supplied software of the entire organization.RT
27
3.1.5License obligationsH
28
3.1.5.0A process exists for reviewing the identified licenses to determine the obligations, restrictions and rights granted by each license.RQ
29
3.1.5.1A documented procedure to review and document the obligations, restrictions and rights granted by each identified license.VM
30
3.1.5.RTo ensure a process exists for reviewing and identifying the license obligations for each identified license for the various use cases an organization may encounter (as defined in requirement 3.3.2)RT
31
3.2Relevant tasks defined and supportedH
32
3.2.1AccessH
33
3.2.1.0Maintain a process to effectively respond to external open source inquiries. Publicly identify a means by which a third party can make an open source compliance inquiry.RQ
34
3.2.1.1Publicly visible method that allows any third party to make an open source license compliance inquiry (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).VM
35
3.2.1.2An internal documented procedure for responding to third party open source license compliance inquiries.VM
36
3.2.1.RTo ensure there is a reasonable way for third parties to contact the organization with regard to open source compliance inquiries and that the organization is prepared to effectively respond.RT
37
3.2.2Effectively resourcedH
38
3.2.2.0Identify and Resource Program Task(s):
• Assign accountability to ensure the successful execution of program tasks.
• Program tasks are sufficiently resourced:
• Time to perform the tasks have been allocated; and
• Adequate funding has been allocated.
• A process exists for reviewing and updating the policy and supporting tasks;
• Legal expertise pertaining to open source license compliance is accessible to those who may need such guidance; and
• A process exists for the resolution of open source license compliance issues.		RQ
39
3.2.2.1Document with name of persons, group or function in program role(s) identified.VM
40
3.2.2.2The identified program roles have been properly staffed and adequate funding provided.VM
41
3.2.2.3Identification of legal expertise available to address open source license compliance matters which could be internal or external.VM
42
3.2.2.4A documented procedure that assigns internal responsibilities for open source compliance.VM
43
3.2.2.5A documented procedure for handling the review and remediation of non-compliant cases.VM
44
3.2.2.RTo ensure: i) program responsibilities are effectively supported and resourced and ii) policies and supporting processes are regularly updated to accommodate changes in open source compliance best practices.RT
45
3.3Open source content review and approvalH
46
3.3.1Bill of materialsH
47
3.3.1.0A process exists for creating and managing a bill of materials that includes each open source component (and its identified licenses) from which the supplied software is comprised.RQ
48
3.3.1.1A documented procedure for identifying, tracking, reviewing, approving, and archiving information about the collection of open source components from which the supplied software is comprised.VMThe procedure may not be replicable but outputs a list of foss components with corresponding licences (which may be incomplete with unverified data). There are no metrics to assess output or procedural quality.The procedure is replicable and outputs a list of foss components with corresponding licences (which may be incomplete with unverified data).The procedure is replicable and outputs a list of foss components with corresponding licences. The outputted list undergoes sanity checking for completeness and correctness, with errors fixed manually.The procedure is replicable and mostly automated, it outputs a list of foss components with corresponding licences. The outputted list undergoes sanity checking for completeness and correctness with errors fixed manually. The list is signed off and stored.The procedure is replicable and mostly automated, it outputs a list of foss components with corresponding licences. The outputted list undergoes sanity checking for completeness and correctness with errors fixed manually. The list is signed off by sufficiently trained and responsible staff and stored.The procedure is replicable and mostly automated, it outputs a list of foss components with corresponding licences. The outputted list undergoes comprehensive review with errors fixed by providing upstream contributions. The list is signed off by sufficiently trained and responsible staff and stored in an appropriately secure and backed-up database.
49
3.3.1.2Open source component records for the supplied software that demonstrates the documented procedure was properly followed.VM"Records" consist of a list of components and corresponding licences in some text-based format."Records" consist of a list of components, corresponding licences, and some other metadata (such as version numbers), in a structured format."Records" consist of a list of components, corresponding licences, and some other metadata (such as version numbers), in a structured format used across product/project lines."Records" consist of a list of components, corresponding licences, and some other metadata (such as version numbers), in a structured, machine-readable format used across product/project lines."Records" consist of a list of components, corresponding licences, and some other metadata (such as version numbers), in a structured machine-readable format used across product/project lines. The records are signed and dated."Records" consist of a list of components, corresponding licences, and all other metadata required by an industry standard SBOM format. The records are signed and dated by suitably trained and responsible staff.
50
3.3.1.RTo ensure a process exists for creating and managing an open source component bill of materials used to construct the supplied software. A bill of materials is needed to support the systematic review and approval of each component’s license terms to understand the obligations and restrictions as it applies to the distribution of the supplied software.RT
51
3.3.2License complianceH
52
3.3.2.0The program must be capable of managing common open source license use cases encountered by program participants for supplied software, which may include the following use cases (note that the list is neither exhaustive, nor may all of the use cases apply):
• Distributed in binary form;
• Distributed in source form;
• Integrated with other open source such that it triggers additional licensing obligations;
• Contains modified open source;
• Contains open source or other software under an incompatible license interacting with other components within the supplied software; and/or
• Contains open source with attribution requirements.		RQ
53
3.3.2.1A documented procedure for handling the common open source license use cases for the open source components of the supplied software.VM
54
3.3.2.RTo ensure the program is sufficiently robust to handle an organization’s common open source license use cases. That a procedure exists to support this activity and that the procedure is followed.RT
55
3.4Compliance artifact creation and deliveryH
56
3.4.1Compliance artifactsH
57
3.4.1.0A process exists for creating the set of compliance artifacts for the supplied software.RQ
58
3.4.1.1A documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.VM
59
3.4.1.2A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time (determined by domain, legal jurisdiction and/or customer contracts) since the last offer of the supplied software; or as required by the identified licenses (whichever is longer). Records exist that demonstrate the procedure has been properly followed.VM
60
3.4.1.RTo ensure reasonable commercial efforts have been instituted in the preparation of the compliance artifacts that accompany the supplied software, as required by the identified licenses.RT
61
3.5Understand open Source community engagementH
62
3.5.1ContributionsH
63
3.5.1.0If an organization considers contributions to open source projects, then:
• a written policy exists that governs contributions to open source projects;
• the policy must be internally communicated; and
• a process exists that implements the policy		RQ
64
3.5.1.1A documented open source contribution policyVM
65
3.5.1.2A documented procedure that governs open source contributionsVM
66
3.5.1.3A documented procedure that makes all program participants aware of the existence of the Open Source contribution policy (e.g., via training, internal wiki, or other practical communication method)VM
67
3.5.1.RWhen an organization permits open source contributions, the intent is that the organization has given reasonable consideration to developing and implementing a contribution policy. The open source contribution policy can be made a part of the overall open source policy or be its own separate policy.RT
68
3.6Adherence to the Specification RequirementsH
69
3.6.1ConformanceH
70
3.6.1.0In order for a program to be deemed OpenChain conformant, the organization must affirm that the program satisfies the requirements presented in the specification.RQ
71
3.6.1.1A document affirming the program specified in requirement §3.1.4 satisfies all the requirements of this specification.VM
72
3.6.1.RTo ensure that if an organization declares that it has a program that is OpenChain conforming, that such program has met all the requirements of this specification. The mere meeting of a subset of these requirements would not be considered sufficient.RT
73
3.6.2DurationH
74
3.6.2.0A program that is OpenChain conformant with version 2.1 of the specification will last 18 months from the date conformance validation was obtained. The conformance validation registration procedure can be found on the OpenChain project’s website.RQ
75
3.6.2.1A document affirming the program meets all the requirements of this version of the specification (version 2.1), within the past 18 months of obtaining conformance validationVM
76
3.6.2.RIt is important for a program to remain current with the specification if an organization wants to assert conformance over time. This requirement ensures that the program’s supporting processes and controls do not erode if an organization continues to assert program conformance over time.RT
77
TX
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100