Version 9 – May 2025
Need Immediate Help?
What Do You Want To Know?
General Questions
OpenChain ISO/IEC 5230:2020
OpenChain ISO/IEC 18974:2023
Self-Certification Questions
Cyber Resilience Act (CRA)
NTIA Minimum Elements For a Software Bill of Materials (SBOM)
OpenSSF Open Source Project Security Baseline
The Processes We Use
General Questions
The OpenChain Project is global community of organizations collaborating to create trust in the open source supply chain.
We do this through ISO/IEC 5230:2020, the International Standard for open source license compliance, and OpenChain ISO/IEC 18974:2023, the industry standard for open source security assurance. We also have education, training and certification resources freely available to all parties.
Most importantly, our community acts as a support network where knowledge is shared to reduce friction and increase efficiency across all aspects of open source process management.
Where Can I Find A Formal Description Of The OpenChain Project?
The formal description and structure of the OpenChain Project is contained in the Project Charter. You can find this on GitHub:
https://github.com/OpenChain-Project/Project-Charter-And-Agreements/tree/master/Project-Charter
What Does The OpenChain Project Cover?
The OpenChain Project is focused on building trust in the open source supply chain. Our primary emphasis is on issues related to license, security and other types of compliance. We are working towards a world where open source is predictable, understandable and optimized for internal and external supply chains of any type.
Our global community also works on topics like open source training, open source policy, open source program offices (OSPOs) and more. Everything we do is open to everyone, and it is all freely available.
Who Conforms To The OpenChain Standards?
We maintain a list of organizations decide to publicly announce OpenChain Conformant Programs through our website:
https://www.openchainproject.org/community-of-conformance
However, because our specifications are supply chain standards, they focus on the relationship between customers and suppliers, so most organizations adopt our work without public announcement. For example, a Bitkom survey sponsored by PwC in 2021 indicated that 20% of German companies with more than 2,000 employees are currently using OpenChain ISO/IEC 5230, the international standard for open source license compliance.
The primary way you find out if an organization is OpenChain ISO/IEC 5230 or OpenChain ISO/IEC 18974 conformant is by discussing this in sales communications or procurement negotiations. You can also ask their OSPO (if present) about their conformance status.
How Is The OpenChain Project Organized?
The OpenChain Project has global and local work groups that anyone can be part of. Some examples are the:
Specification Work Group, which identifies and publishes a set of core requirements a quality open source compliance program should satisfy.
Education Work Group, which provides reference material to help organization meet our specification requirements.
You can find a full list of our work groups and other activities on our community page:
https://www.openchainproject.org/community
There are three committees for member companies:
- Governing Board – Manage policies or rules and procedures for the Project, fund raising, budgeting and so forth.
- Steering Committee – Development, management and updating of the OpenChain Compliance Specification.
- Outreach Committee – Designing, developing and executing efforts to build an OpenChain compliance ecosystem throughout relevant supply chains in collaboration with the Governing Board.
Can I Participate In The OpenChain Project?
Yes, of course. Everyone from any company, organization or government is welcome to participate. We also welcome individuals interested in the topics we cover. There is no registration or membership required. Get started here:
https://www.openchainproject.org/community
Can My Company Become An OpenChain Member?
There is no membership requirement to attend our meetings, to join our calls and webinars, or to help edit our standard and reference material. There is currently one membership level for the OpenChain Project: Platinum Membership. This is available to user companies (not vendors) and it provides a seat and a vote on our governing board and our steering committee. To learn more contact the General Manager at scoughlan@linuxfoundation.org.
There is also a partner program for vendor companies to engage with OpenChain. You can learn more here:
https://www.openchainproject.org/partners
How Is The OpenChain Project Related To Other Linux Foundation Process Projects?
The OpenChain Project has various sister standards covering adjacent topics in the area of open source process management. For example, the SDPX Project maintains SPDX ISO/IEC 5962, the International Standard for Software Bill of Materials (SBOM). The Open Source Security Foundation (OpenSSF) has extensive investment in security-related practices and management. The TODO Group has a focus on Open Source Program Offices (OSPOs). The Automated Compliance Tooling Project (ACT Project) supports open source tooling for automation related to management and compliance topics.
We work with all of these projects to help companies find the best solution for their market requirements. The OpenChain Project has perhaps the highest level optic – how to get started with key processes for open source management – and then you can use our sister projects to build out your processes and continually improve your approach.
How Are The OpenChain Standards Related To The OpenSSF Best Practices Badge?
The OpenChain Project and the OpenSSF Best Practices Badge are both Linux Foundation initiatives to identify criteria around open source process quality. The OpenChain Project focuses on the software supply chain. In contrast, the OpenSSF Best Practices Badge focuses on well-run open source projects themselves. These are complimentary initiatives, and both can be used to optimize open source from upstream to deployment and support.
OpenChain ISO/IEC 5230:2020
This is the FAQ for the OpenChain ISO/IEC 5230:2020 specification. We recommend that all contributors to our specification development process take a while to review this section of our FAQ.
We work based on four principles:
- Build trust around the open source supply chain.
- Remember that less is more:
— Define the key requirements of a quality compliance program
— Do this by solving real pain points in the supply chain - Keep our specifications limited to what and why (avoid the how and when)
— Embrace different implementations to solve challenges
— Avoid mandating specific process content - Be open to all to participate and contribute
What is the objective of OpenChain ISO/IEC 5230:2020?
It is designed to identify the key requirements of a quality open source license compliance program. This means it provides a level of trust about what organizations are doing as they ingest, internally develop and distribute open source software.
Where can I find the current version of OpenChain ISO/IEC 5230:2020?
You can find it on the OpenChain Project conformance page:
https://www.openchainproject.org/get-started/conformance
Does an open source program need to satisfy all the requirements of OpenChain ISO/IEC 5230:2020 to be considered conformant?
Yes. OpenChain ISO/IEC 5230:2020 defines the key requirements of a quality open source license compliance program. To make sure there are no gaps that would lead to poor quality output, a program must satisfy all the OpenChain ISO/IEC 5230:2020 requirements to be considered conforming.
Can software packages be OpenChain ISO/IEC 5230:2020 conformant?
No. OpenChain ISO/IEC 5230:2020 defines a quality open source license compliance program. The program is conformant. The software packages go through the program and therefore benefit from it. The question to ask suppliers is whether the software they supply was prepared under an OpenChain conforming program.
Does all the software in an organization need to be covered by an OpenChain ISO/IEC 5230:2020 conformant program?
No. Organizations are often made from different groups or departments with different programs and release procedures. One example is that engineering may be very different from professional services). An organization decides how much of the total entity to cover with its OpenChain ISO/IEC 5230:2020 conformant program. Many companies start with one part of one group covering one product, and build out from there.
Does the specification serve as a best practice guide?
No. OpenChain ISO/IEC 5230:2020 defines a quality open source license compliance program. It focuses on the “what and why” aspects of a program and not the how or when. A best practices guide must explain how and when to ensure it supports implementation activities. We publish reference material like Playbooks covering these topics, but they are separate to OpenChain ISO/IEC 5230:2020 itself.
How was OpenChain ISO/IEC 5230:2020 developed?
The OpenChain Project developed OpenChain ISO/IEC 5230:2020 via our specification mailing list and calls. The process was (and is) open to everyone. The initial draft of OpenChain ISO/IEC 5230:2020 (then called OpenChain 1.0) was created in the 2015-2016 period and released in late 2016. Since then the OpenChain Project has continually reviewed and maintained the standard in an open, collaborative manner that mirrors how open source software is created.
Does OpenChain ISO/IEC 5230:2020 describe how to comply with the most popular open source licenses?
No. OpenChain ISO/IEC 5230:2020 defines a quality open source license compliance program. It is not designed to identify, breakdown and interpret individual open source licenses. Because open source licenses are legal documents, they will also vary in their interpretation and application across different legal jurisdictions. Local organizations like OSADL (Germany) have worked on license obligation lists relevant for their markets.
Does OpenChain ISO/IEC 5230:2020 provide legal guidance?
No. The specification does not provide legal guidance because that can only come from a legal expert assigned to advise an organization. OpenChain ISO/IEC 5230:2020 does require an organization to designate a legal expert to do this as part of the conformance process. OpenChain ISO/IEC 5230:2020 also requires that a process exists to ensure the appropriate attention is given to license obligation analysis and and fulfillment.
Does OpenChain ISO/IEC 5230:2020 conformance guarantee license compliance?
No, but it significantly increases the probability that license compliance will be achieved for software prepared under an OpenChain ISO/IEC 5230:2020 conformant program.
Do resources exist to assist my organization in achieving OpenChain ISO/IEC 5230:2020 conformance?
Yes. You will find a substantial amount of resources, including self-certification checklists, on the OpenChain website:
https://www.openchainproject.org
What license is OpenChain ISO/IEC 5230:2020 released under?
The version we host on our website (currently called OpenChain 2.1) is licensed under the Creative Commons Attribution License 4.0 (CC-BY-4.0). A copy of the license can be obtained here:
https://creativecommons.org/licenses/by/4.0/legalcode
OpenChain ISO/IEC 18974:2023
This is the FAQ for OpenChain ISO/IEC 18974. We recommend that all contributors to our specification development process take a while to review this section of our FAQ.
We work based on four principles:
- Build trust around the open source supply chain.
- Remember that less is more:
— Define the key requirements of a quality compliance program
— Do this by solving real pain points in the supply chain - Keep our specifications limited to what and why (avoid the how and when)
— Embrace different implementations to solve challenges
— Avoid mandating specific process content - Be open to all to participate and contribute
What is the objective of OpenChain ISO/IEC 18974?
It is designed to identify the key requirements of a quality open source security assurance program. This means it provides a level of trust about what organizations are doing as they ingest, internally develop and distribute open source software.
Where can I find the current version of OpenChain ISO/IEC 18974?
You can find it on the OpenChain Project conformance page:
https://www.openchainproject.org/get-started/conformance
Does an open source program need to satisfy all the requirements of OpenChain ISO/IEC 18974 to be conformant?
Yes. OpenChain ISO/IEC 18974 defines the key requirements of a quality open source security assurance program. To make sure there are no gaps that would lead to poor quality output, a program must satisfy all the OpenChain ISO/IEC 18974 requirements to be considered conforming.
Can software packages be OpenChain ISO/IEC 18974 conformant?
No. OpenChain ISO/IEC 18974 defines a quality open source security assurance program. The program is conformant. The software packages go through the program and therefore benefit from it. The question to ask suppliers is whether the software they supply was prepared under an OpenChain ISO/IEC 18974 conforming program.
Does all the software in an organization need to be covered by an OpenChain ISO/IEC 18974 conformant program?
No. Organizations are often made from different groups or departments with different programs and release procedures. One example is that engineering may be very different from professional services). An organization decides how much of the total entity to cover with its OpenChain ISO/IEC 18974 conformant program. Many companies start with one part of one group covering one product, and build out from there.
Does OpenChain ISO/IEC 18974 serve as a best practice guide?
No. OpenChain ISO/IEC 18974 defines a quality open source security assurance program. It focuses on the “what and why” aspects of a program and not the how or when. A best practices guide must explain how and when to ensure it supports implementation activities. We publish reference material like Playbooks covering these topics, but they are separate to OpenChain ISO/IEC 18974 itself.
How was OpenChain ISO/IEC 18974 developed?
The OpenChain Project developed OpenChain ISO/IEC 18974 via our specification mailing list and calls. The process was (and is) open to everyone. The initial draft of the OpenChain ISO/IEC 18974 (then called the OpenChain Security Assurance Reference Guide) was created in the 2021 period. It was restructured as the OpenChain Security Assurance Reference Specification in Q1 2022 and released as the OpenChain Security Assurance Specification in Q4 2022. Since then the OpenChain Project has continually reviewed and maintained the standard in an open, collaborative manner that mirrors how open source software is created.
Does OpenChain ISO/IEC 18974 describe how to comply with specific security requirements?
No. OpenChain ISO/IEC 18974 defines a quality open source security assurance program. It is not designed to identify, breakdown and interpret individual security requirements. The specifics of each requirement and obligation must be determined by each company for their respective market space and legal jurisdiction.
Does OpenChain ISO/IEC 18974 provide legal guidance?
No. The specification does not provide legal guidance because that can only come from a legal expert assigned to advise an organization.
Does OpenChain ISO/IEC 18974 conformance guarantee security assurance?
No, but it significantly increases the probability that security assurance issues will arise for software prepared under an OpenChain ISO/IEC 18974 conformant program.
Do resources exist to assist my organization in achieving OpenChain ISO/IEC 18974 conformance?
Yes. You will find a substantial amount of resources, including self-certification checklists, on the OpenChain website:
https://www.openchainproject.org
What license is OpenChain ISO/IEC 18974 released under?
The version we host on our website is licensed under the Creative Commons Attribution License 4.0 (CC-BY-4.0). A copy of the license can be obtained here:
https://creativecommons.org/licenses/by/4.0/legalcode
OpenChain Self-Certification Questions
OpenChain ISO/IEC 5230:2020 and OpenChain ISO/IEC 18974 are designed to build trust around open source as clear and impartial standards. The approach is “less is more” and focus on what and why rather than how and when.
Our resources around self-certification are equally focused. They help organizations quickly understand practical application of the standards.
What is the objective of OpenChain Self-Certification?
OpenChain self-certification is designed to help an organization assess if it meets the requirements of the standard with simple questions or checklists. Organizations of any size can use self-certification as a way of improving their compliance approach and advertising that fact to their supply chain.
How do I scope Self-Certification for my organization?
There are three basic approaches to getting started with OpenChain Self-Certification.
- A pilot project
- A narrowly-scoped program
- A widely-scoped program
Pilot Project
A pilot program is a very narrowly-scoped OpenChain conformant program, often used as a “test case” before applying the program to parts of the product production process. An example would be to run an OpenChain conformant program on a virtual product inside an Open Source Program Office (OSPO), with different OSPO members charged with roles or responsibilities contained in the relevant OpenChain standard.
The type of questions a pilot program is designed to answer include:
- Is our implementation approach covering all the requirements of the relevant standard?
- Do our planned actions and responses match both our internal production processes and the relevant standard?
- Can we begin to expand this pilot towards production teams?
Narrowly-Scoped Program
A narrowly-scoped program covers some aspects of a company production process related to internal or externally deployed software products. This is the most common type of OpenChain conformant program, with the “narrow scope” often starting very small and expanding over time.
An example would be to run an OpenChain conformant program on a team that covers a single codebase inside a company. This would be the narrowest production program.
Another example would be to run an OpenChain conformant program on several codebases or entire products inside the company. This is where most companies operate OpenChain conformant programs.
The type of questions a narrowly-scoped program is designed to answer include:
- Does this cover key open source code?
- Does this contain our IPR risk effectively?
- Does this match or surpass what our customer companies are asking for?
Widely-Scoped Program
A widely-scoped program is the same as a narrowly-scoped program, but generally covers the entire legal entity of the company. This is a rare choice (most companies have plenty of product lines that do not include open source), but some companies choose to create such programs. It does create a badge of distinction in terms of the effort the company places on open source compliance and other matters.
How do I complete the Self-Certification process?
You can use our self-certification questionnaire or checklist. You can access both via this page:
https://www.openchainproject.org/get-started
What if I don’t agree with a submission made by another organization?
Contact the OpenChain Project with the name of the organization you are concerned about and the reason you disagree with their submission. We will get back to you to discuss the matter further. It should be noted that disagreements about conformance are exceptionally rare (we did not encounter one directly yet), but it is important to have a way to make sure the market is using our standards in a fair and balanced manner. You will find our contact details at the link below:
https://www.openchainproject.org/about
Please let us know when you are conformant
Once you complete the process, please let us know so that we can add you to our Community of Conformance on the OpenChain Project website. This is not mandatory but it provides an advantage to you (more of your peers know that you have the key requirements of a quality open source compliance program in place), and it provides an advantage to us because we have more insight into market adoption. You can let us know about your conformance by contacting our helpdesk.
Cyber Resilience Act (CRA):
From the European Commission’s website:
The Cyber Resilience Act (CRA) aims to safeguard consumers and businesses buying software or hardware products with a digital component. […] The Cyber Resilience Act introduces mandatory cybersecurity requirements for manufacturers and retailers, governing the planning, design, development, and maintenance of such products. These obligations must be met at every stage of the value chain. The act also requires manufacturers to provide care during the lifecycle of their products.
The OpenChain Project is actively working to support the open source community in addressing the challenges and opportunities presented by the CRA in the context of a more trusted supply chain. Our existing standards are inherently supportive of the known and likely requirements to emerge from the CRA regulatory environment.
OpenChain ISO/IEC 5230 (license compliance) and OpenChain ISO/IEC 18974 (security assurance) both ask for the creation and archiving of information, helping to ensure organizations can track, review, and adjust processes as needed.
We also work in collaboration with our colleagues over at the Open Source Security Foundation (OpenSSF) around their Global Cyber Policy Working Group. Based on outcomes from this working group, and other relevant activities around the CRA, the OpenChain Project will evolve our support of the open source supply chain.
OpenSSF Global Cyber Policy Working Group
Cybersecurity is a matter of global interest and concern. Stakeholders from across the ecosystem and the globe are impacted by the deluge of cybersecurity incidents and vulnerability exploits. The Global Cyber Policy Working Group seeks to assemble subject matter experts from many disciplines to collaboratively discuss legislation, regulation, and cybersecurity frameworks and standards that can help stakeholders of all background meet their compliance obligations. […] This group will begin with a focus on the EU’s CRA legislation, but in the future can expand into other related topics.
GitHub: https://github.com/ossf/wg-globalcyberpolicy
Mailing List: https://lists.openssf.org/g/openssf-wg-globalcyberpolicy
NTIA Minimum Elements For a Software Bill of Materials (SBOM):
From the NTIA website:
The Executive Order (14028) on Improving the Nation’s Cybersecurity directs the Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the “minimum elements” for a Software Bill of Materials (SBOM). This report builds on the work of NTIA’s SBOM multistakeholder process, as well as the responses to a request for comments issued in June, 2021, and extensive consultation with other Federal experts.
The outcome of this activity is ‘The Minimum Elements For a Software Bill of Materials (SBOM)
Pursuant to Executive Order 14028 on Improving the Nation’s Cybersecurity.’
How OpenChain Supports The NTIA Minimum Elements For a Software Bill of Materials
OpenChain ISO/IEC 5230 for open source license compliance and ISO/IEC 18974 for security assurance both require the use of a Software Bill of Materials (SBOM) when managing software. OpenChain is fully compatible with and supportive of Executive Order 14028.
We have also developed other guides, reference material or solutions to assist in this area. Three key items are:
- The OpenChain Telco SBOM Guide – a guide to quality in SBOMs for the supply chain
- The OpenChain Telco SBOM Guide Validator – a tool to help automate reviewing SBOM quality
- The OpenChain SBOM Study Group – a group focused on how SBOM-related management in the supply chain can be improved
Note:
It should be noted that the OpenChain ISO standards do not define an SBOM format. The NTIA Minimum Elements cite three formats that may be used to meet their requirements. “These specifications have been developed through open processes, with international participation. In addition to being machine readable, these data formats are also human-readable, better supporting trouble-shooting and innovation. More importantly, these standards have been deemed interoperable for the core data fields and use common data syntax representations.“
The data formats cited by NTIA are:
- Software Package Data eXchange (SPDX)
- CycloneDX
- Software Identification (SWID) tags
The OpenChain Telco SBOM Guide uses the SPDX format. The OpenChain SBOM Study Group is exploring how cross-industry / cross-market guides may be developed in the future.
OpenSSF Open Source Project Security Baseline:
The OpenSSF Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to its maturity level.
OpenChain ISO/IEC 18974 supports several aspects of the OSPS Baseline, and is included in the Compliance Crosswalk Matrix to map against the OSPS Baseline.
The Processes We Use:
The OpenChain Project has formal processes for developing and translating standards, and we have processes for opening and closing work groups or study groups. You can find these formal processes outlined on the dedicated processes page.
