Skip to main content

FAQ

Version 4

Need Immediate Help?



Topics

General Questions
OpenChain ISO/IEC 5230:2020 Questions
OpenChain Security Assurance Specification Questions
Self-Certification Questions
Specification Development Questions
Specification Translation Questions

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 our Security Assurance Reference Specification. 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 Security Assurance 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 Questions

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 Security Assurance Specification Questions

This is the FAQ for the OpenChain Security Assurance Specification 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 the OpenChain Security Assurance Specification?

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 Security Assurance Specification?

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 the OpenChain Security Assurance Specification to be conformant?

Yes. OpenChain Security Assurance Specification 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 Security Assurance Specification requirements to be considered conforming.

Can software packages be OpenChain Security Assurance Specification conformant?

No. OpenChain Security Assurance Specification 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 Security Assurance Specification 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 Security Assurance Specification conformant program. Many companies start with one part of one group covering one product, and build out from there.

Does the OpenChain Security Assurance Specification serve as a best practice guide?

No. OpenChain Security Assurance Specification 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 Security Assurance Specification itself.

How was the OpenChain Security Assurance Specification developed?

The OpenChain Project developed OpenChain Security Assurance Specification via our specification mailing list and calls. The process was (and is) open to everyone. The initial draft of the OpenChain Security Assurance Specification (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 the OpenChain Security Assurance Specification describe how to comply with specific security requirements?

No. OpenChain Security Assurance Specification 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 the OpenChain OpenChain Security Assurance Specification 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 the OpenChain Security Assurance Specification conformance guarantee security assurance?

No, but it significantly increases the probability that security assurance issues will arise for software prepared under an OpenChain Security Assurance Specification conformant program.

Do resources exist to assist my organization in achieving OpenChain Security Assurance Specification 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 Security Assurance Specification 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 Self-Certification Questions

OpenChain ISO/IEC 5230:2020 and the OpenChain Security Assurance Specification 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. 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 resources are designed to help an organization assess if it meets the requirements of the standard with simple questions or checklists. Organizations of any size use self-certification as a way of improving their compliance approach and advertising that fact to their supply chain.

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

How do I get started?

You can use our self-certification questionnaire or checklist. You can access the questionnaire at the following link:
https://github.com/OpenChain-Project/Reference-Material/blob/master/Self-Certification/Questionnaire/ISO5230-2020/en/

You can access the checklist at the following link:
https://github.com/OpenChain-Project/Reference-Material/blob/master/Self-Certification/Checklist/ISO5230-2020/en/

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.

We also have legacy support

We have a legacy self-certification web app. This has been used as the primary way to record conformance progress online since 2017. However, it is depreciated as we transition to document formats more easily ingested into organizations for self-certification. It can be here:
https://certification.openchainproject.org/

If I use the web app, can I change my submission?

You will see an unsubmit button at the bottom of the page after signing in to the Online Self-Certification site. Clicking this button will cancel your previous OpenChain Self-Certification submission. You can then re-submit the conformance check. The site is here:
https://certification.openchainproject.org/

If I use the web app, what response time should I expect to a submittal request?

If all information is correct, the submittal will automatically be approved by the system. Any omissions or incorrect answers will be reported by the user.

Specification Development Questions

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

Our community development process is to:

  1. Hold a community kickoff meeting and revisit the OpenChain Project specification development guiding principles.
  2. Accept and discuss feedback from anyone who wants to participate either at the monthly community meetings or on the specification mailing list.
  3. Record feedback through License Compliance GitHub Issues or Security Assurance GitHub Issues.
  4. Publish modifications and additions in a draft document contained in either our License Compliance GitHub Repository or Security Assurance GitHub Repository.
  5. Open a Public Comments Period six weeks before our target completion date. This runs for 30 days 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.
  6. Open a Freeze Period two weeks before our target completion date to allow a 14 day review of any changes made during the Public Comments Period.
  7. If a consensus expresses concerns over any changes made during the Public Comments period we would
    • i) make changes to accommodate those concerns followed by
    • ii) an additional 14 day Public Comments period; followed by
    • iii) 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.
  8. In the event we do not have consensus on the final version – we would repeat the following cycle until we have consensus:
    • i) accommodate changes to address majority concerns;
    • ii) 14 day Public Comments period; followed by
    • iii) a 14 day Freeze period cycle.
  9. 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.

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

  • There is one official translation for each language.
  • All translations are based on the English version.
  • 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

  1. Propose a translation on the monthly calls, specification mailing list or other official channel like our WeChat group.
  2. Get a copy of the English version of our specification to facilitate the translation:
  3. Add the proposed translations as a Pull Request to the License Compliance GitHub Repository or Security Assurance GitHub Repository.
  4. The translation license should be the same as the English original
  5. 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.”
  6. The translation will be accepted (or flagged for further review) via GitHub.
  7. It will then be announced on the main mailing list and the specification mailing list.