Open Source Compliance Program¶

Introduction¶

The Hop3 Programme's Open Source Compliance Program is designed to align with ISO/IEC 5230, the international standard for open source license compliance. Adopting the standard makes the programme's software development and distribution processes transparent. This program provides policies and procedures that guide contributors, developers, and stakeholders in adhering to open source licensing requirements.

Objectives¶

The primary objectives of the Hop3 Programme Open Source Compliance Program are:

1. Compliance: To fulfill all obligations under applicable open source licenses, minimizing legal and reputational risks.
2. Transparency: To document and communicate the use of open source software components within the Hop3 Programme.
3. Education: To provide training and resources to contributors, ensuring they understand their responsibilities related to open source software.
4. Continuous Improvement: To regularly evaluate and improve compliance practices as open source standards evolve.

Scope¶

This program applies to:

• Distributed Software: All software distributed externally, including releases containing open source components.
• Third-Party Open Source Components: Any open source libraries or tools integrated into the Hop3 Programme.
• Contributions to External Projects: Contributions made to other open source projects under the Hop3 Programme name or on behalf of its organization.

The program excludes internal tools and experimental software not intended for external distribution, unless explicitly stated otherwise.

This document consolidates the relevant policies, procedures, and responsibilities into a single reference point.

Program Foundation¶

Five components make up the program’s foundation: the Open Source Policy, communication and awareness, roles and responsibilities, scope and limits, and license review.

Open Source Policy¶

The Hop3 Programme operates under an Open Source Policy that governs the project's use, distribution, and contribution of open source components. The policy ensures compliance with legal requirements and protects the project's integrity and reputation.

The key elements of the Open Source Policy include:

License Compliance¶

• Establishes strict guidelines for selecting open source components based on compatibility with project objectives and legal requirements.
• Mandates review and approval of licenses associated with open source software to ensure compliance with obligations such as attribution, source code availability, and redistribution terms.
• Maintains a record of open source licenses used, including their obligations and any changes over time.

Contributions¶

• Defines clear rules for contributing to external open source projects, ensuring that all contributions are reviewed and approved by designated personnel.
• Requires contributors to follow the community guidelines and licensing requirements of the target open source projects.
• Encourages collaboration with upstream communities to increase the impact of contributions and avoid duplicated or rejected work.

Transparency¶

• Documents all open source software used in the project, including dependencies, versions, and associated licenses.
• Commits to providing necessary compliance artifacts (e.g., Software Bill of Materials, attribution files) with all distributed products, in accordance with the terms of the respective licenses.
• Promotes transparency by making the Hop3 Programme's own contributions and licensing information publicly available where feasible.

Security and Risk Management¶

• Evaluates third-party open source components for security, stability, and ongoing maintenance status.
• Integrates automated vulnerability scanning and license risk detection into the development workflow.
• Establishes a process for reviewing and remediating non-compliance or security vulnerabilities in open source dependencies.

Training and Awareness¶

• Provides ongoing training for team members on the principles and practices of open source compliance, including the legal and operational implications of using open source software.
• Ensures all team members and contributors understand the policy’s requirements and know how to access relevant documentation and resources.

Review and Update¶

• Reviews the Open Source Policy periodically to keep it aligned with legal requirements, industry standards, and project needs.
• Updates the policy as necessary and communicates changes to all stakeholders promptly.

Communication and Awareness¶

The Hop3 Programme communicates its Open Source Policy through training, documentation, and awareness campaigns so that team members, contributors, and stakeholders understand and follow it.

Training Sessions¶

• Conduct regular workshops, tutorials, and webinars tailored to different audiences, such as developers, administrators, and project managers.
  • Developer-focused training includes hands-on sessions on open source license compliance, integrating open source components, and contributing to external projects.
  • Administrative training covers record-keeping, compliance documentation, and license risk assessment.
  • Advanced topics are addressed for specialized roles, such as legal compliance teams or open source community managers.
• New team members undergo an onboarding program that introduces the Open Source Policy and its practical application.
• Provide certification opportunities or badges for team members who complete the full training in open source compliance.

Documentation Access¶

• Maintain an internal repository for policy documents, guidelines, and best practices, ensuring they are easily accessible to all team members.
  • This includes FAQs, quick-reference guides, and detailed workflows for integrating open source components into projects.
• Make selected compliance-related resources publicly available on the project’s website, such as:
  • Guidelines for contributors.
  • Licensing information for external stakeholders.
  • Steps to fulfill license obligations.
• Use modern documentation tools (e.g., wikis, searchable databases) to keep content organized and searchable.

Periodic Updates¶

• Establish a process for routine reviews of the Open Source Policy and related procedures, ensuring they remain up-to-date with evolving legal, industry, and project requirements.
• Communicate changes effectively through email bulletins, team meetings, and the internal documentation repository.
• Summarize each update so stakeholders can see what changed and what it requires of them.
• Provide examples or case studies during updates to illustrate the practical application of policy changes.

Engagement Tools¶

• Use interactive tools such as quizzes or simulations to reinforce understanding of open source compliance requirements.
• Facilitate open discussions through team meetings or online forums, where team members can share insights, raise concerns, and propose improvements to the Open Source Policy.
• Encourage feedback loops by allowing team members to provide suggestions for improving policy communication and compliance practices.

Awareness Campaigns¶

• Launch periodic awareness campaigns highlighting key aspects of the Open Source Policy, such as:
  • Importance of license compliance.
  • Success stories of open source contributions.
  • Common pitfalls and how to avoid them.
• Use visual aids like infographics, flowcharts, and videos to simplify complex compliance concepts and workflows.

Roles and Responsibilities¶

The compliance program defines the following key roles:

Key Roles¶

• Compliance Officer
  • Responsible for overseeing the implementation, maintenance, and continuous improvement of the compliance program.
  • Ensures that compliance policies are enforced and integrated into all relevant workflows.
  • Acts as the primary point of contact for compliance inquiries, audits, and reporting.
• Legal Advisor
  • Advises on open source licensing and regulatory requirements.
  • Reviews and approves licenses for new open source components and contributions.
  • Helps resolve compliance issues, such as license conflicts or non-conformance cases.
• Technical Leads
  • Ensure their teams adhere to open source compliance policies during software development and integration.
  • Coordinate open source component reviews and maintain accurate records of component usage.
  • Collaborate with the Compliance Officer to implement approved tools and workflows for compliance.
• Contributors
  • Follow the Open Source Policy when integrating third-party components into the Hop3 Programme or contributing to external projects.
  • Document and communicate any licensing requirements or changes associated with their work.
  • Participate in training sessions and remain updated on the project’s compliance policies.

Competency and Preparation¶

The Hop3 Programme maintains a competency matrix that defines and assesses the skills required for each role. The matrix includes:

• Competency Requirements:
  • Knowledge of relevant open source licenses (e.g., GPL, MIT, Apache).
  • Understanding of compliance workflows, such as creating Software Bill of Materials (SBOMs) or responding to inquiries.
  • Familiarity with tools for tracking and auditing open source usage.
• Competency Assessment:
  • Periodic evaluations to ensure all program participants possess the required skills and knowledge.
  • Tailored training programs to address skill gaps identified during assessments.
• Documentation
  • A record will be kept demonstrating that each participant has the required competence.
  • A record will be kept demonstrating that each participant has received documented awareness training.

Awareness and Accountability¶

• Each role is accountable for compliance within its area of responsibility.
• Documentation of roles and responsibilities is maintained in an accessible format, ensuring clarity for all stakeholders.
• Regular performance reviews identify gaps in compliance adherence and feed improvements back into the program.

Scope and Limits¶

The compliance program operates within a written scope statement that is reviewed regularly and updated as the project evolves. The scope and its limits are accessible to all stakeholders.

Inclusion Criteria¶

The program encompasses all software components that meet the following criteria:

• Externally Distributed Software:
  • Components included in releases of the Hop3 Programme platform.
  • Standalone applications or tools distributed alongside the Hop3 Programme.
  • Open source contributions made by the Hop3 Programme team to external projects.
• Open Source Dependencies:
  • Third-party open source libraries or frameworks integrated into the Hop3 Programme.
  • Software that triggers obligations under open source licenses (e.g., GPL, LGPL, AGPL).
• Compliance Artifacts:
  • Accompanying materials, such as Software Bills of Materials (SBOMs), license notices, and source code, required for compliance with identified licenses.

Exclusion Criteria¶

Certain categories of software are excluded from the program unless explicitly stated otherwise:

• Internal Tools:
  • Tools or scripts developed solely for internal use and not distributed externally.
• Experimental Software:
  • Prototypes or experimental code that is not yet included in public releases.
• Third-Party Software Outside Scope:
  • Proprietary software or third-party components distributed under non-open source licenses that do not interact with open source components in ways that trigger compliance obligations.

Program Boundaries¶

The scope statement also defines the limits of the compliance program:

• Geographic Boundaries: Applies to software distributed globally, taking into account regional licensing and regulatory requirements.
• Lifecycle Coverage: Covers components from development through distribution, including updates, but does not extend to end-user modifications beyond the Hop3 Programme’s distribution obligations.

Accessibility of the Scope Statement¶

The written scope statement is:

• Maintained in an accessible repository, such as the Hop3 Programme internal documentation site and public compliance documentation.
• Reviewed annually or in response to material project changes to ensure continued relevance and accuracy.
• Communicated to all team members and contributors during onboarding and regular compliance training sessions.

Reviewing License Obligations¶

The Hop3 Programme follows a defined procedure to review the obligations, restrictions, and rights of every open source license that applies to software it uses or distributes.

License Identification¶

The process begins with identifying the licenses associated with every open source component used or distributed by the Hop3 Programme. This includes:

• Component Inventory: Maintaining an up-to-date list of all open source components and their versions.
• License Mapping: Documenting the license type for each component (e.g., MIT, GPL, Apache 2.0).
• Verification: Cross-referencing license information with reliable sources, such as the Nixpkgs repository or the SPDX License List, to ensure accuracy.

Obligation Assessment¶

Once licenses are identified, their specific requirements are analyzed to understand the obligations and restrictions they impose:

• Distribution Requirements: Determining obligations for providing source code, license notices, or additional documentation.
• Compatibility Checks: Ensuring that the integration of different components complies with license compatibility requirements (e.g., avoiding conflicts between permissive and copyleft licenses).
• Attribution Obligations: Identifying and implementing proper attribution where required by licenses such as BSD, Apache 2.0, or MPL.
• Redistribution Conditions: Understanding requirements for derivative works or modifications, particularly for strong copyleft licenses like GPL and AGPL.

Documentation and Record-Keeping¶

Detailed records are maintained at every stage of the license review process:

• License Reviews: Documenting the analysis of each license, including key obligations, risks, and mitigation actions.
• Compliance Records: Archiving relevant artifacts, such as SBOMs, license texts, and notices, to demonstrate compliance with distribution obligations.
• Audit Trail: Ensuring that all license reviews and decisions are logged and available for internal or external audits.

Automated Support Tools¶

Automated tools support the review process:

• Dependency Scanners: Tools such as FOSSology or OpenChain-conformant solutions to identify and analyze licenses in source code and binaries.
• SBOM Generators: Systems like Genealogos for creating and maintaining a Software Bill of Materials (SBOM) that includes license information.

Ongoing License Monitoring¶

To ensure continued compliance, the Hop3 Programme regularly revisits and updates its license reviews:

• Updates and Changes: Monitoring updates to components for license changes or new obligations.
• Emerging Licenses: Staying informed about new or revised open source licenses that may impact the project.

Relevant Tasks Defined and Supported¶

External Compliance Inquiries¶

The Hop3 Programme addresses external open source compliance inquiries transparently through a designated Compliance Officer, the primary contact for external stakeholders, publicly identified on the project's website.

Procedure¶

A structured process is in place to manage external compliance inquiries:

• Logging: All inquiries are recorded in a centralized tracking system.
• Assignment: Each inquiry is assigned to the appropriate personnel, such as the Compliance Officer, Legal Advisor, or Technical Lead, based on its nature and complexity.
• Acknowledgment: Acknowledgment of receipt is sent to the inquirer promptly, along with an estimated timeline for resolution.

Resolution¶

The Hop3 Programme resolves compliance concerns through a consistent procedure:

• Evaluation: The inquiry is reviewed to determine its validity, scope, and potential implications for the project.
• Action Plan: A resolution plan is developed, detailing the steps required to address the issue, whether it involves updating compliance artifacts, modifying documentation, or addressing component usage.
• Execution: The plan is implemented, and any required changes are communicated to relevant stakeholders.

Response and Archiving¶

A documented response is provided to the inquirer, outlining:

• The actions taken to address the issue.
• Any relevant supporting materials, such as updated compliance artifacts or process improvements.
• Opportunities for follow-up or further clarification.

All inquiries, responses, and resolutions are archived in the tracking system to:

• Maintain a detailed audit trail.
• Ensure compliance with the Open Source Policy.
• Identify recurring issues and improve processes proactively.

Internal Responsibilities¶

The Hop3 Programme supports open source compliance internally with defined roles, responsibilities, and resources.

Staffing and Funding¶

• Each role in the compliance program is staffed to meet its obligations. The Compliance Officer, Legal Advisor, Technical Leads, and other team members have defined duties and allocated time to perform them.
• Funding is allocated to ensure access to necessary tools, training, and legal or technical resources, supporting ongoing compliance and addressing emerging requirements.

Legal Expertise¶

• A Legal Advisor with expertise in open source licensing and compliance participates in the program. This individual:
  • Advises on complex licensing issues.
  • Reviews software components for compatibility and compliance with licensing terms.
  • Helps draft policies, contracts, and other legal documents related to open source use and distribution.
  • Assesses risks and recommends mitigation strategies to prevent non-compliance.

Compliance Tasks¶

• All team members engaged in open source development and operations are assigned specific compliance-related tasks, such as:
  • Component Vetting: Reviewing and approving the use of open source components in line with the Open Source Policy.
  • License Review: Identifying, analyzing, and documenting license obligations for each open source component.
  • Compliance Artifacts: Creating and maintaining artifacts such as SBOMs (Software Bill of Materials), attributions, and license texts required for software distribution.
  • Issue Resolution: Collaborating with the Compliance Officer and Legal Advisor to address non-compliance cases or external inquiries.

Support and Tools¶

• Team members are equipped with tools and resources to facilitate compliance tasks, such as:
  • License scanners for detecting and analyzing open source components.
  • Tracking systems for managing compliance artifacts and inquiries.
  • Access to a centralized knowledge base containing policies, procedures, and best practices.

Handling Non-Compliance¶

The Hop3 Programme follows a defined procedure for non-compliance with open source license obligations, from identification through remediation and documentation.

Identification¶

• Audits and Testing: Regular internal audits and automated compliance tools are used to identify potential non-compliance in software components, documentation, or distribution practices.
• Issue Reporting: Team members are encouraged to report suspected non-compliance through a designated reporting mechanism.

Remediation¶

• Analysis and Action Plan: Upon identifying a non-compliance issue, the Compliance Officer, in collaboration with the Legal Advisor and relevant Technical Leads, analyzes the problem and formulates an action plan.
  • Common remediation actions include:
    • Revising or completing missing documentation, such as license attributions or compliance artifacts.
    • Updating software components to align with license requirements.
    • Replacing or removing non-compliant components from the codebase.
  • For complex cases, external legal or technical expertise may be consulted to ensure an accurate resolution.
• Implementation: The agreed remediation actions are implemented by the responsible team members under the supervision of the Compliance Officer to ensure adherence to the Open Source Policy.

Documentation¶

• Detailed Records: Each non-compliance case is fully documented, including:
  • The nature of the issue and how it was identified.
  • The analysis performed and the resolution process.
  • The specific actions taken and their outcomes.
• Audit Support: These records are archived systematically for internal reviews, external audits, and certification processes.
• Preventive Measures: Insights from non-compliance cases feed into policy updates, training, and tools to prevent recurrence.

Open Source Content Review and Approval¶

Tracking and Archiving¶

The Hop3 Programme tracks and archives information about every open source component it uses.

Component Records¶

• Metadata Documentation: Each open source component is documented with detailed metadata, including:
  • Name and version of the component.
  • Origin (e.g., source repository or distribution channel).
  • License type and specific obligations.
  • Purpose and scope of usage within the Hop3 projects.
  • Any modifications made to the component.
• Centralized Records: All metadata is stored in a centralized compliance management system, ensuring easy access for team members, auditors, and external stakeholders.

Archival Process¶

• Central Repository: A secure, centralized repository is used to archive all records related to open source components. This repository ensures long-term accessibility and serves as the single source of truth for compliance documentation.
• Retention Policy: Records are retained for the software’s lifecycle and as long as the applicable licenses require, covering obligations such as source code availability and attribution.
• Version History: All updates to component records are logged, providing a complete version history to track changes and maintain an audit trail.

License Use Cases¶

The compliance program covers the scenarios in which open source licenses impose obligations.

Binary Distribution¶

• License Inclusion: All binary distributions include the appropriate license files, notices, and disclaimers as required by the licenses governing the distributed components.
• Attribution Statements: Clear attribution is provided in documentation, UI, or other relevant outputs to credit the original authors and contributors.

Source Distribution¶

• Availability of Source Code: For licenses that mandate source code distribution (e.g., GPL), the Hop3 Programme makes source code available alongside binaries or via a published URL.
• Version Matching: Source code distributed matches the binaries provided, version for version.

Modified Components¶

• Documentation of Changes: Modifications to open source components are documented, including the changes and their impact on functionality.
• Compliance with Derivative Work Obligations: Where licenses impose obligations on derivative works (e.g., copyleft licenses), the programme meets them so that redistribution complies with license terms.

Attribution¶

• Required Notices: All required license notices, copyright statements, and disclaimers are included in distributions and documentation.
• Centralized Attribution File: The Hop3 Programme maintains a centralized attribution file or directory within its software distributions, consolidating all required acknowledgments.

Integration with Other Software¶

• Compatibility Assessment: Before integrating any open source component, the programme assesses compatibility with the licenses already in use and with its own licensing practices.
• Mitigation Strategies: When potential incompatibilities are identified, mitigation strategies are employed, such as:
  • Choosing alternative components with compatible licenses.
  • Isolating components through clear interfaces to limit the scope of certain license obligations.
  • Seeking legal advice to understand the implications and potential solutions for complex licensing scenarios.

Compliance Artifact Creation and Delivery¶

Compliance Artifacts¶

The Hop3 Programme creates, distributes, and archives Compliance Artifacts to meet its open source license obligations.

Creation¶

• Content Accuracy: Compliance Artifacts include all necessary license files, copyright notices, attribution statements, and any additional obligations specified by the licenses governing included open source components.
• Automated Generation: Tools are used to automatically generate compliance documentation during the software build process, reducing manual errors and ensuring consistency across releases.
• Component-Specific Details: Each artifact includes detailed information about individual components, such as the license type, version, and usage within the software.

Distribution¶

• Bundled Delivery: Compliance Artifacts are distributed alongside the software to ensure users receive the necessary licensing information at the point of acquisition.
• Online Availability: For larger or complex distributions, Compliance Artifacts are hosted online, with links or references included in the software documentation to ensure accessibility.

Archival¶

• Retention Policy: Compliance Artifacts are archived in a centralized repository for as long as the associated software is distributed, ensuring long-term compliance and traceability.
• Version Control: Historical Compliance Artifacts are maintained for each software version to provide a clear audit trail and to facilitate legal and technical reviews when necessary.

Open Source Community Engagement¶

Contribution Policy¶

The Hop3 Programme encourages participation in the open source community within its organizational policies and legal obligations. The contribution policy defines how staff and contributors engage with external projects.

Approval Workflow¶

• Pre-Submission Review: The Compliance Officer or a designated approver reviews all proposed contributions to ensure alignment with the Hop3 Programme’s goals and adherence to licensing and legal requirements.
• Change Documentation: Contributions must include proper documentation of changes, including details of the purpose, modifications made, and associated license information.

Staff Awareness¶

• Training Programs: Regular workshops and tutorials educate team members on the contribution policy, licensing requirements, and best practices for interacting with open source projects.
• Accessible Documentation: Contributors have accessible documentation covering the steps for submitting contributions and handling conflicts.

Community Support and Participation¶

The Hop3 Programme engages with the open source community as a contributor and partner.

• Participation in Projects: Team members are encouraged to participate in upstream projects by reporting bugs, submitting patches, and sharing feedback.
• Community Representation: The Hop3 Programme designates representatives to attend and present at community events, conferences, and workshops to present contributions and exchange knowledge.
• Collaborative Development: The Hop3 Programme prioritizes partnerships with other organizations and contributors to co-develop features, fix issues, and address shared challenges.

Code of Conduct¶

The Hop3 Programme commits to a positive and inclusive community environment.

• Guidelines for Interaction: All interactions, whether internal or with external communities, adhere to a defined code of conduct promoting respect, inclusivity, and collaboration.
• Enforcement Mechanism: A documented procedure is in place to address violations of the code of conduct, ensuring a fair and transparent resolution process.

Conformance Review¶

The Hop3 Programme conducts regular reviews of its Open Source Compliance Program to maintain alignment with the ISO/IEC 5230 standard. These reviews occur at least once every 18 months and cover the program's policies, procedures, and documentation.

Review Scope¶

• Policy Updates: Evaluates the relevance and effectiveness of the Open Source Policy and updates it as necessary to reflect evolving best practices or changes in licensing requirements.
• Procedures Audit: Assesses the documented procedures for compliance tasks, ensuring they remain accurate and actionable.
• Role Effectiveness: Reviews the roles and responsibilities within the compliance program to ensure adequate staffing, funding, and expertise.

Documentation and Transparency¶

• Archived Records: All review findings, updates, and resolutions are documented and archived in the centralized compliance repository.
• Audit Readiness: Documentation from conformance reviews is organized to facilitate external audits or assessments, providing a clear and traceable record of compliance activities.

Continuous Improvement¶

• Stakeholder Feedback: Incorporates feedback from staff, contributors, and external stakeholders to identify areas for improvement.
• Actionable Outcomes: Develops and implements action plans based on review findings to enhance the program’s efficiency and effectiveness.

Annex: Self-Assessment¶

The following are the answers to the OpenChain ISO/IEC 5230 Self-Certification Questionnaire for the Hop3 Programme's Open Source Compliance Program. Each answer names the section of this document that satisfies the requirement.

The responses are based on a review of the programme's compliance documentation.

Section 1: Program Foundation

1. Documented Policy: YES. Section 2.1: Open Source Policy clearly establishes a comprehensive policy.
2. Communication Procedure: YES. Section 2.2: Communication and Awareness outlines procedures for communicating the policy to all staff.
3. Identified Roles and Responsibilities: YES. Section 2.3: Roles and Responsibilities defines key roles and their responsibilities.
4. Identified Competencies: YES. Section 2.3: Competency and Preparation outlines the required competencies for each role.
5. Documented Competence: YES. Section 2.3: Competency and Preparation states that a record of competence will be maintained for each participant.
6. Documented Awareness: YES. Section 2.3: Competency and Preparation states that a record will be kept demonstrating that each participant has received documented awareness training. Section 2.2: Training Sessions and Awareness Campaigns ensure that program participants are aware of the policy, objectives, contributions, and implications of non-compliance.
7. Process for Determining Scope: YES. Section 2.4: Scope and Limits defines the process for determining the program's scope.
8. Written Scope Statement: YES. Section 2.4: Accessibility of the Scope Statement ensures the scope is clearly defined in writing and accessible.
9. Procedure to Review License Obligations: YES. Section 2.5: Reviewing License Obligations details the procedure for reviewing and documenting license obligations.

Section 2: Relevant Tasks Defined and Supported

1. Assigned Responsibility for Inquiries: YES. Section 3.1: External Compliance Inquiries assigns the Compliance Officer responsibility for handling external inquiries.
2. Publicly Identified Contact: YES. Section 3.1: Transparency and Responsiveness states that the contact will be publicly identified.
3. Procedure for Inquiries: YES. Section 3.1: Procedure and Resolution detail the procedure for receiving and responding to inquiries.
4. Documented Support for Roles: YES. Section 2.3: Roles and Responsibilities and Section 3.2: Compliance Tasks document the persons, group, or function supporting the program roles.
5. Properly Staffed and Funded: YES. Section 3.2: Staffing and Funding ensures that roles are properly staffed and adequately funded.
6. Identified Legal Expertise: YES. Section 3.2: Legal Expertise identifies the role of the Legal Advisor.
7. Procedure for Internal Responsibilities: YES. Section 3.2: Compliance Tasks outlines the procedure for assigning internal responsibilities.
8. Procedure for Non-Compliance: YES. Section 3.3: Handling Non-Compliance details the procedure for handling non-compliance cases.

Section 3: Open Source Content Review and Approval

1. Procedure for Tracking Components: YES. Section 4.1: Tracking and Archiving defines the procedure for identifying, tracking, and archiving information about open source components.
2. Component Records: YES. Section 4.1: Component Records ensures that component records demonstrate the procedure was followed.
3. Procedure for License Use Cases: YES. Section 4.2: License Use Cases details the procedures for handling common open source license use cases.

Section 4: Compliance Artifact Creation and Delivery

1. Procedure for Distributing Artifacts: YES. Section 5.1: Creation and Distribution outlines the procedure for distributing compliance artifacts.
2. Procedure for Archiving Artifacts: YES. Section 5.1: Archival defines the procedure for archiving compliance artifacts.
3. Artifacts Archived Appropriately: YES. Section 5.1: Retention Policy ensures that artifacts are archived for the appropriate duration.

Section 5: Understanding Open Source Community Engagements

1. Contribution Policy: YES. Section 6.1: Contribution Policy establishes a policy for open source contributions.
2. Procedure for Contributions: YES. Section 6.1: Approval Workflow details the procedure for governing contributions.
3. Procedure for Staff Awareness: YES. Section 6.1: Staff Awareness outlines the procedure for making staff aware of the contribution policy.

Section 6: Adherence to the Specification Requirements

1. Documentation of Program Meeting Requirements: YES. Section 7: Conformance Review and the rest of this document demonstrate that the program meets the requirements of the specification. The Annex: Self-Assessment maps each section to the questionnaire.
2. Documentation of Conformance Review: YES. Section 7: Conformance Review and Continuous Improvement ensures that conformance is reviewed within the last 18 months and documented.