Version 8 – November 2024
Need Immediate Help?
What Do You Want To Know?
General Questions
OpenChain ISO/IEC 5230:2020
OpenChain ISO/IEC 18974:2023
Self-Certification Questions
Specification Development Questions
Specification Translation Questions
Process for forming new Study Groups
Process for forming new Work Groups
Process for winding down Study Groups or Work Groups
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.
Specification Development Questions
Our vision is a supply chain where open source is delivered with trusted and consistent process management information. Our mission is to make that happen.
The OpenChain Project has an extensive global community of over 1,000 companies collaborating to make the supply chain quicker, more effective and more efficient. As part of this we make specifications that can turn into standards.
Making a new specification is a process with a lot of moving pieces. We scope development as outlined below. Prior to the process below kicking in, ideas around new specifications can be shared via our mailing list if they are tagged as proposals, with the recommendation that they are kept in a coherent thread, and ideally also recorded in GitHub.
We have four guiding principles:
- Build trust around the open source supply chain.
- Remember that less is more:
— Define the key requirements of a quality 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
Our community development process is to:
- Hold a community kickoff meeting and revisit the OpenChain Project specification development guiding principles.
- Accept and discuss feedback from anyone who wants to participate either at the Monthly Community Calls or on the specification mailing list or the relevant GitHub Repository.
- Record feedback through GitHub issues and their comments for the relevant specification. The current practice is usually to have a GitHub Repository dedicated to each specification under development. We do not accept Pull Requests due to requirements to keep copyright ownership limited and allow easy transfer to international standards organizations.
- Publish modifications and additions in a draft document contained in relevant GitHub Repository.
- Open a Public Comments Period nine months before our target completion date. This runs for 6 months and only accepts minor updates such as typos or grammar corrections that do not change the requirements of the content. We do not accept any material changes during this period. All other feedback and recommendations are queue for consideration during the next version release cycle.
- Open a Freeze Period three months before our target completion date to allow a 3 month review of any changes made during the Public Comments Period.
- If a consensus expresses concerns over any changes made during the Public Comments period we would
- make changes to accommodate those concerns followed by
- an additional 14 day Public Comments period; followed by
- another 14 day Freeze period. Anyone with significant reservations on the final draft should state their position/concerns via the spec mailing list. The changes will be accepted once we achieve consensus for the final draft.
- In the event we do not have consensus on the final version – we would repeat the following cycle until we have consensus:
- accommodate changes to address majority concerns;
- 14 day Public Comments period; followed by
- a 14 day Freeze period cycle.
- Send the completed draft specification to the OpenChain Steering Committee for formal review and a vote on whether to accept the community recommendations for an updated or new specification.
- In principle, we target updates to our ISO standards once every five years
Please Note: the final decision on content and release of OpenChain Project specifications lies with the OpenChain Steering Committee.
Specification Translation Questions
We encourage translations of our specifications. However, we want these translations to follow a process to help ensure accuracy.
Policy
- All translations are based on the English version, which is are official, normative versions of the OpenChain specifications.
- There is one official translation for each language.
- Every translation has one maintainer selected by the OpenChain Project.
- Translations should be reviewed wherever possible by two or more people to ensure integrity, accuracy and completeness.
- Translations are made under the terms of the license of the material being translated.
- Translation version numbers must correspond to the official English version it is based on.
Translation Checklist
- Propose a translation on the monthly calls, specification mailing list or other official channel like our WeChat group.
- Get a copy of the English version of our specification to facilitate the translation:
OpenChain ISO/IEC 5230:2020 in MarkDown
OpenChain Security Assurance Specification in MarkDown - Add the proposed translations as an Issue to the License Compliance GitHub Repository or Security Assurance GitHub Repository.
- The translation license should be the same as the English original
- The translation should also include the following disclaimer:
- “This is a translation from the original specification in English. In the event there is confusion between this translation and the English version, The English text shall take precedence.”
- The translation will be accepted (or flagged for further review) via GitHub.
- It will then be announced on the main mailing list and the specification mailing list.
Process for forming new Study Groups
Note based on previous board discussion: It is suggested that new study groups remain relatively easy to form, to ensure new ideas can be examined and relevance to market easily maintained.
- A proposal should be drafted that explains the rationale behind the new group to the governing board [written statement]
- The proposal should also explain how the activity supports the mission of the OpenChain Project [written statement]
- Submit to board via GM
- Board permission granted against a certain time period [one week via email to the board] with or without questions, and formally ratified at the [next board meeting]
Process for forming new Work Groups
Note based on previous board discussion: It is suggested that Work Groups have a higher barrier to entry than previously, to ensure they are working on solutions that conclusively support our project charter.
- In principle, new Work Groups should be formed from existing Study Groups
- A Work Group should be designed to take the conversation outcome of a Study Group, and implement a solution based on that outcome
- A proposal should be drafted that explains the rationale behind the new group to the governing board [written statement]
- The proposal should also explain how the activity supports the Project Charter of the OpenChain Project [written statement]
- This would be submitted to the OpenChain Governing Board via the board mailing list
- Board permission granted against a certain time period [two weeks] with or without questions, and formally ratified at the [next board meeting]
Process for winding down Study Groups or Work Groups
- In principle, all Study Groups and Work Groups may find a natural conclusion, either when their mission is complete, or when it is determined that their work is best carried out elsewhere
- If such a situation is identified, the relevant chair or GM should explain the rationale [written statement]
- This would be submitted to the OpenChain Governing Board via the board mailing list
- Board permission granted against a certain time period [one week via email to the board] with or without questions, and formally ratified at the [next board meeting]
