Split Official Self-Cert Questionnaire and Checklists with new repo order

Author: shanecoughlan

Self-Certification-Questionnaire/Official/2.1/en/OpenChain Self-Certification Checklist 2022-10-05.md renamed to Self-Certification/Checklist/Official/2.1/en/OpenChain Self-Certification Checklist 2022-10-05.md

@@ -0,0 +1,111 @@
+![](./media/image1.png "OpenChain logo")
+
+# OpenChain ISO/IEC 5230 Self-Certification Checklist
+## The Simple Way To Check Conformance
+
+Revision 1\
+2022-10-05
+
+# Introduction
+
+OpenChain ISO/IEC 5230:2020 is the International Standard for open source license compliance. It is simple, effective and suitable for companies of all sizes in all markets. This standard is openly developed by a vibrant user community and freely available to all. It is supported by extensive reference material and official service provider partners.
+
+You can adopt OpenChain ISO/IEC 5230:2020 by self-certification in your own time or working with a service provider for independent assessment or third-party certification. Our recommended path is self-certification and we provide this questionnaire to support this with a series of "yes" or "no" questions.
+
+We have a lot of resources to support you if you need assistance. You can join our mailing lists, our webinars, our group calls and our regional work groups to discuss challenges with your peers and in your native language. You can get started here:
+
+[[https://www.openchainproject.org/community]{.underline}](https://www.openchainproject.org/community)
+
+Finally, if you want direct support from the project you can email
+[[[email protected]]{.underline}](mailto:[email protected])
+with questions. We provide support for free. The OpenChain Project is funded by our Platinum Members and is designed to help support the global supply chain transition to more effective and efficient open source license compliance.
+
+# The Self-Certification Checklist
+
+## Section 1: Program foundation
+
+- [ ] We have a policy governing the open source license compliance of Supplied Software.
+
+- [ ] We have a documented procedure to communicate the existence of the open source policy to all Software Staff.
+
+- [ ] We have identified the roles and responsibilities that affect the performance and effectiveness of the Program.
+
+- [ ] We have identified and documented the competencies required for each role.
+
+- [ ] We have documented the assessed competence for each Program participant.
+
+- [ ] We have documented the awareness of our Program participants on the following topics:
+
+- - [ ] The open source policy and where to find it;
+
+- - [ ] Relevant open source objectives;
+
+- - [ ] Contributions expected to ensure the effectiveness of the Program;
+
+- - [ ] The implications of failing to follow the Program requirements.
+
+- [ ] We have a process for determining the scope of our Program.
+
+- [ ] We have a written statement clearly defining the scope and limits of the Program.
+
+- [ ] We have a documented procedure to review and document open source license obligations, restrictions and rights.
+
+## Section 2: Relevant tasks defined and supported
+
+- [ ] We assigned individual(s) responsibility for receiving external open source compliance inquiries.
+
+- [ ] The external open source compliance contact is publicly identified (e.g. via an email address or the Linux Foundation Open Compliance Directory).
+
+- [ ] We have a documented procedure for receiving and responding to open source compliance inquiries.
+
+- [ ] We have documented the persons, group or function supporting the Program role(s) identified.
+
+- [ ] We have ensured identified Program roles been properly staffed and adequately funded.
+
+- [ ] Legal expertise to address internal and external open source compliance has been identified.
+
+- [ ] We have a documented procedure assigning internal responsibilities for open source compliance.
+
+- [ ] We have a documented procedure for handling review and remediation of non-compliant cases.
+
+## Section 3: Open source content review and approval
+
+- [ ] We have a documented procedure for identifying, tracking and archiving information about the open source components in a Supplied Software release.
+
+- [ ] We have open source component records for the Supplied Software which demonstrate the documented procedure was properly followed.
+
+- [ ] We have a documented procedure that covers these common open source license use cases for open source components in the Supplied Software:
+
+- - [ ] Distribution in binary form;
+
+- - [ ] Distribution in source form;
+
+- - [ ] Integration with other open source that may trigger additional obligations;
+
+- - [ ] Containing modified open source;
+
+- - [ ] Containing open source or other software under incompatible licenses for interaction with other components in the Supplied Software;
+
+- - [ ] Containing open source with attribution requirements.
+
+## Section 4: Compliance artifact creation and delivery
+
+- [ ] We have a documented procedure describing the process for ensuring the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses.
+
+- [ ] We have a documented procedure for archiving copies of Compliance Artifacts for the Supplied Software.
+
+- [ ] We archive the Compliance Artifacts at least as long as the Supplied Software is offered and as required by the Identified Licenses.
+
+## Section 5: Understanding open source community engagements
+
+- [ ] We have a policy for contribution to open source projects on behalf of the organization.
+
+- [ ] We have a documented procedure governing open source contributions.
+
+- [ ] We have a documented procedure for making all Software Staff aware of the open source contribution policy.
+
+## Section 6: Adherence to the specification requirements
+
+- [ ] We have documentation confirming that your Program meets all the requirements of this specification.
+
+- [ ] We have documentation confirming that your Program conformance was reviewed within the last 18 months.