# Open Source Program Policy: [Organisation name]

> Policy for how [Organisation name] uses, distributes and contributes to open source software: program scope and roles, licence categories and approval, the inbound component process and software bill of materials, security assurance for open source components, compliance artefacts for outbound distribution, contributions to external projects with sign-off, releasing company projects, handling external inquiries, conformance records and review. Structure aligned with ISO/IEC 5230:2020 (OpenChain Specification, open source licence compliance; confirmed by ISO in July 2026) and ISO/IEC 18974:2023 (OpenChain security assurance specification). Replace every `[bracketed]` value and every row marked *Example*. Worked examples use Corvid Commerce, a fictional SaaS company that runs an online checkout platform and ships an on-premises payment gateway appliance. This is a documentation format, not legal advice: licence interpretation needs a qualified professional.

<!--
Guidance: How to use this template
- Decide the program scope first (section 1.2). A company that only runs software as a service has different distribution triggers from one that ships appliances, mobile apps or SDKs.
- Fill the licence category table (section 4) with counsel before anything else; most later rules point to it.
- Use the clause mapping (section 13) as a self-check against the two OpenChain standards. Conformance claims need every requirement covered with evidence, not only this document.
- Keep boundaries: the detailed dependency update and pinning rules live in Dependency Management Policy (`dev/dependency-management-policy`); SBOM formats and VEX live in SBOM and VEX Policy (`security/sbom-vex-policy`); a single licence decision is recorded in Software Licence Review (`compliance/software-licence-review`); governance of a project you publish lives in Governance (`dev/governance`).
-->

## Document control

<!-- Guidance: The owner is usually the head of the open source program office (OSPO) or, without an OSPO, the engineering leader who owns supply chain policy. Legal must approve. -->

| Field | Value |
|---|---|
| Document ID | [OSP-POL-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@ospo-lead] |
| Approvers/reviewers | [@general-counsel], [@ciso], [@engineering-director], [@product-security-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal; a summary may be published] |
| Standards referenced | ISO/IEC 5230:2020; ISO/IEC 18974:2023 |
| Conformance claim | [*Example:* Self-certified conformance to ISO/IEC 5230 and ISO/IEC 18974, registered YYYY-MM-DD] |
| Next review | YYYY-MM-DD (at least every 12 months, and before conformance renewal) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| General counsel | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Engineering director | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; program covers the gateway appliance and mobile SDK |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added security assurance section for ISO/IEC 18974 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Policy statements](#2-policy-statements)
3. [Roles, competence and awareness](#3-roles-competence-and-awareness)
4. [Licence categories](#4-licence-categories)
5. [Inbound use and software bill of materials](#5-inbound-use-and-software-bill-of-materials)
6. [Security assurance for open source components](#6-security-assurance-for-open-source-components)
7. [Outbound distribution and compliance artefacts](#7-outbound-distribution-and-compliance-artefacts)
8. [Contributing to external projects](#8-contributing-to-external-projects)
9. [Releasing company projects as open source](#9-releasing-company-projects-as-open-source)
10. [External inquiries](#10-external-inquiries)
11. [Exceptions](#11-exceptions)
12. [Conformance, records and review](#12-conformance-records-and-review)
13. [Clause mapping](#13-clause-mapping)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Questions: which products are distributed to customers (binaries, firmware, apps, containers, SDKs), and which only run as a service? Which subsidiaries and suppliers are covered? Pitfall: a scope that says "all software", which no team can evidence. -->

### 1.1 Purpose

This policy makes sure that [Organisation] meets the obligations of every open source licence in the software it supplies, manages known vulnerabilities in the open source it depends on, and takes part in open source communities in a way that protects the company and respects the projects. It defines who decides, which licences are acceptable for which use, and which records prove that the process works.

### 1.2 Program scope

| Product or activity | Distributed to third parties? | In scope | Notes |
|---|---|---|---|
| *Example:* Checkout platform (SaaS) | No, hosted only | Yes | Network copyleft licences matter here (section 4) |
| *Example:* Payment gateway appliance firmware | Yes, shipped to merchants | Yes | Full compliance artefacts required (section 7) |
| *Example:* Mobile payments SDK | Yes, published to package registries | Yes | Notices bundled in the package |
| *Example:* Internal tools and scripts | No | Yes, inbound rules only | |
| *Example:* Contributions to external projects | Not applicable | Yes | Section 8 |
| [Product] | [Yes / No] | [Yes / No] | [Notes] |

## 2. Policy statements

<!-- Guidance: Short, numbered, testable statements. Each one should point to the section that explains how it is met. -->

| ID | Statement | Section |
|---|---|---|
| OSP-POL-001 | Every open source component in an in-scope product MUST be recorded in that product's software bill of materials (SBOM) with its version and identified licence. | 5 |
| OSP-POL-002 | Components MUST be used only under licences in an approved category for the intended use, or with a recorded approval. | 4, 5 |
| OSP-POL-003 | Known vulnerabilities in open source components MUST be identified, triaged and tracked to closure under the vulnerability process. | 6 |
| OSP-POL-004 | Every distribution of supplied software MUST be accompanied by the compliance artefacts its licences require. | 7 |
| OSP-POL-005 | Employees MUST follow section 8 before contributing to an external project on company time or with company resources. | 8 |
| OSP-POL-006 | Company code MUST be released as open source only after approval under section 9. | 9 |
| OSP-POL-007 | External inquiries about licence compliance or open source security MUST be answered through the published contact within [*Example:* 10 working days]. | 10 |
| OSP-POL-008 | Program participants MUST complete the training in section 3.3 before taking up their role. | 3 |
| OSP-POL-009 | The program MUST be reviewed, and conformance evidence refreshed, at least every 12 months. | 12 |

## 3. Roles, competence and awareness

<!-- Guidance: OpenChain expects documented roles, the competence each role needs, evidence that people have it, and awareness of the policy among participants. A role can be a part-time duty, but it must be named and resourced. -->

### 3.1 Roles and responsibilities

| Role | Responsibilities | Competence required |
|---|---|---|
| OSPO lead (program manager) | Owns this policy; runs the review board; reports to leadership; maintains conformance evidence | Open source licensing basics, process management |
| Open source review board | Decides on licence approvals, outbound releases and exceptions | Mixed: legal, security, engineering |
| Legal counsel | Interprets licences; approves categories, notices and contribution agreements | Software licensing law |
| Product security lead | Owns vulnerability response for open source components; maintains the security assurance process | Vulnerability management, SBOM tooling |
| Engineering teams | Record components, request approvals, keep SBOMs current, produce compliance artefacts in the build | Policy training; build tooling |
| Release managers | Check that compliance artefacts are complete before each distribution | Release checklist |
| Contributors | Follow section 8 when contributing externally | Policy training; DCO or CLA rules |

### 3.2 Resourcing

Record the time and budget each role has. [*Example:* Corvid Commerce funds 0.5 FTE for the OSPO lead, 2 hours a week of counsel time, a software composition analysis (SCA) tool licence, and a monthly review board meeting.] Name a deputy for each role so that approvals do not stop during absences.

### 3.3 Training and awareness

| Audience | Content | When | Evidence |
|---|---|---|---|
| All engineers | This policy, licence categories, how to request approval, how to report a concern | On joining, then every 12 months | Learning system record |
| Release managers | Compliance artefacts and the release checklist | Before first release | Record |
| Review board members | Licence interpretation, security assurance duties | On appointment, then yearly | Record |
| Contributors | Section 8, sign-off rules | Before first external contribution | Record |

## 4. Licence categories

<!-- Guidance: Agree the categories with counsel and keep the table short. Use SPDX licence identifiers. The same licence can be fine for internal use and unacceptable in a distributed product, so the table has one column per use. Pitfall: treating "no licence" as permissive; code without a licence grants no rights. -->

| Category | Examples (SPDX IDs) | Internal use | SaaS (hosted) | Distributed product |
|---|---|---|---|---|
| A. Permissive | MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC, Zlib | Allowed | Allowed | Allowed with notices |
| B. Weak copyleft | LGPL-2.1-only, LGPL-3.0-only, MPL-2.0, EPL-2.0 | Allowed | Allowed | Review board approval; keep modified files separable |
| C. Strong copyleft | GPL-2.0-only, GPL-3.0-only | Allowed | Allowed with review | Not allowed in proprietary components without counsel approval |
| D. Network copyleft | AGPL-3.0-only | Review | Not allowed without counsel approval | Not allowed without counsel approval |
| E. Source-available and non-open-source licences | *Example:* BUSL-1.1, SSPL-1.0, Elastic-2.0 | Review | Counsel approval | Counsel approval |
| F. No licence or unknown | No licence file, unclear headers | Not allowed | Not allowed | Not allowed |
| G. Public domain dedications | CC0-1.0, Unlicense | Allowed | Allowed | Allowed; check jurisdiction notes with counsel |

Licence obligations for each approved licence (attribution, notice files, source offer, change notices, patent clauses) are recorded once in the licence obligation register maintained by counsel, so that engineers do not interpret licences themselves.

## 5. Inbound use and software bill of materials

<!-- Guidance: Describe how a component gets into a product and how the SBOM stays accurate. Automate what you can: an SCA tool in CI finds components that people forget to declare. -->

### 5.1 Approval flow

```mermaid
flowchart TD
    A["Engineer adds a component"] --> B["CI scan identifies component, version and licence"]
    B --> C{"Licence category allowed for this use?"}
    C -- Yes --> D["Recorded in SBOM automatically"]
    C -- No or unknown --> E["Request to review board"]
    E --> F{"Approved?"}
    F -- Yes --> G["Approval ID recorded with the component"]
    G --> D
    F -- No --> H["Component removed or replaced"]
    D --> I["Security checks under section 6"]
```

An approved request records the component, version, licence, intended use, obligations and approver. Approvals are tied to a use: moving an approved component from an internal tool into a distributed product needs a new check.

### 5.2 SBOM rules

| Rule | Detail |
|---|---|
| Format | [*Example:* SPDX 2.3 or CycloneDX 1.6 JSON], following the SBOM and VEX Policy (`security/sbom-vex-policy`) |
| Generation | Produced in the build for every release of supplied software; stored with the release |
| Content | Component name, version, supplier, identified licence, package URL, dependency relationship |
| Retention | [*Example:* For the supported life of the product plus 3 years] |
| Accuracy check | Release manager compares the SBOM with the release checklist; SCA tool fails the build on undeclared components |

## 6. Security assurance for open source components

<!-- Guidance: This section answers ISO/IEC 18974. It covers known vulnerabilities in the open source you ship, not your whole application security program. Link to the vulnerability management process rather than repeating it. -->

| Step | What happens | Owner |
|---|---|---|
| Identify threats | Each supplied product has a threat model that names the structural and technical threats its open source components bring, refreshed at each major release | Product security with the owning team |
| Detect | Each SBOM is checked against public vulnerability sources (for example the CVE list, the National Vulnerability Database, the GitHub Advisory Database and OSV) daily and at each release | Product security |
| Assess | Each finding is triaged for exploitability in our product, with a VEX status where relevant | Product security with the owning team |
| Fix | Remediation targets follow the Vulnerability Management Policy (`security/vulnerability-management-policy`) | Owning team |
| Communicate | Customers of supplied software are informed through security advisories (`security/security-advisory`) | Product security |
| Test before release | Security testing (for example SCA, static analysis and dependency fuzzing where relevant) runs on every release candidate, and open risks are confirmed as fixed, mitigated or accepted before release | Owning team, release manager |
| Verify | Closed findings are verified in the next SBOM scan | Product security |
| Share | Vulnerability and risk information is shared with third parties, such as upstream projects or customers under contract, where appropriate (for example as VEX documents) | Product security |
| Learn | Repeated issues in one component trigger a review of whether to keep it | Review board |

Record the standard practice for each step as written procedures, with the people and tools assigned. [*Example:* Corvid Commerce runs its SCA tool on every pull request and nightly on release SBOMs; critical findings in the gateway firmware open a PSIRT case within one working day.]

## 7. Outbound distribution and compliance artefacts

<!-- Guidance: Distribution triggers obligations: shipping firmware, publishing an SDK, handing a container image to a customer. Hosting a service usually does not, except under network copyleft licences. Confirm the triggers with counsel. -->

| Artefact | When needed | How produced | Where delivered |
|---|---|---|---|
| Notices file (licence texts and attributions) | Every distribution | Generated from the SBOM in the build | Inside the product and on the documentation site |
| Source code for copyleft components | When a licence requires it | Source archive built from the same tag | Download portal or written offer, as counsel decides |
| Written offer for source | When source is not shipped alongside | Standard text approved by counsel | Product documentation |
| Change notices | When a licence requires marking modified files | Commit history and file headers | Source archive |
| SBOM | On customer request or contract | Release SBOM | Customer portal |

Compliance artefacts for each release are archived for [*Example:* at least 3 years after the last distribution of that release].

## 8. Contributing to external projects

<!-- Guidance: Most contributions are small fixes. Make them easy; reserve review for cases with real risk (new projects, patents, confidential information, large features). -->

### 8.1 Contribution tiers

| Tier | Examples | Approval |
|---|---|---|
| T1 Small fix | Bug fixes, documentation, tests to projects already used by the company | None beyond this policy; follow the project's rules |
| T2 Feature or new project | New features, contributions to a project not used by the company | Manager plus OSPO lead |
| T3 Sensitive | Code touching company patents, security fixes before disclosure, anything derived from confidential code | Review board and counsel |

### 8.2 Sign-off and agreements

- Where a project uses the Developer Certificate of Origin (DCO 1.1, developercertificate.org), contributors add a `Signed-off-by:` line with `git commit -s` using their own name and company email, after confirming the certification applies.
- Where a project needs a Contributor Licence Agreement (CLA), counsel reviews it once; corporate CLAs are signed by [authorised signatory] and individual contributors are added to the approved list.
- Contributions never include company confidential information, customer data or secrets.
- Security fixes follow coordinated disclosure with the project's security policy before any public pull request.

## 9. Releasing company projects as open source

<!-- Guidance: A release is a long-term commitment. Ask who will maintain the project and answer issues in two years. Pitfall: releasing a code dump with no owner, which damages reputation more than not releasing. -->

| Check | Evidence |
|---|---|
| Business reason and named maintainers | Release proposal approved by the review board |
| Licence chosen from the outbound list | [*Example:* Apache-2.0 by default; MIT for small utilities] |
| Code free of secrets, internal hostnames and third-party code with incompatible licences | Scan reports |
| Trademark and naming cleared | Counsel note |
| Community files present | README (`dev/readme`), CONTRIBUTING (`dev/contributing`), Code of Conduct (`dev/code-of-conduct`), Security Policy (`dev/security-policy`), Governance (`dev/governance`) |
| Security baseline | OSS Project Security Baseline (`security/oss-project-security-baseline`) |

## 10. External inquiries

<!-- Guidance: OpenChain expects a public way for third parties to ask about licence compliance. Publish it and make sure someone watches it. -->

Publish [*Example:* `opensource@corvid.example`] on the product documentation site and in notices files. Inquiries are logged, acknowledged within [*Example:* 5 working days] and answered within [*Example:* 10 working days], or given a date. Security reports go to the channel in the Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`).

| Inquiry ID | Date received | Topic | Owner | Status | Closed |
|---|---|---|---|---|---|
| INQ-001 *(Example)* | YYYY-MM-DD | Request for source of a GPL component in gateway firmware 4.2 | [@ospo-lead] | Source archive sent | YYYY-MM-DD |
| [INQ-NNN] | YYYY-MM-DD | [Topic] | [@owner] | [Status] | YYYY-MM-DD |

## 11. Exceptions

<!-- Guidance: Exceptions are time-limited and have compensating controls. A permanent exception is a sign that the licence category table is wrong. -->

| Exception ID | Policy statement | Reason | Compensating controls | Approved by | Expires |
|---|---|---|---|---|---|
| OSP-EXC-001 *(Example)* | OSP-POL-002 | Category C library needed in an internal test harness that is never distributed | Build rule blocks it from release artefacts | Review board | YYYY-MM-DD |
| [OSP-EXC-NNN] | [ID] | [Reason] | [Controls] | [@approver] | YYYY-MM-DD |

## 12. Conformance, records and review

<!-- Guidance: Both OpenChain standards ask for evidence that every requirement is met and for that evidence to stay current. The published 2020 and 2023 editions give conformance an 18-month life; the OpenChain community has proposed shortening this to 12 months in a future edition, so this template reviews every 12 months. -->

| Record | Retention | Location |
|---|---|---|
| This policy and its approvals | Current and two prior versions | Policy portal |
| Training records | [*Example:* 3 years] | Learning system |
| SBOMs and compliance artefacts per release | Section 5.2 and section 7 | Release archive |
| Licence approvals and exceptions | Life of the component in the product | Review board register |
| Vulnerability triage records | [*Example:* 3 years] | Vulnerability tracker |
| Inquiry log | [*Example:* 3 years] | OSPO register |
| Conformance self-assessment | Until the next one | OSPO register |

Review the program every 12 months: check each row of the clause mapping (section 13), sample three releases for complete artefacts, and report results to [leadership]. Register or renew the conformance claim through the OpenChain project's process if you publish one.

## 13. Clause mapping

<!-- Guidance: Clause numbers and headings follow the public OpenChain editions; the wording in the "How this policy meets it" column is original. Read the official text before claiming conformance. -->

### 13.1 ISO/IEC 5230:2020 (licence compliance)

| Clause | Heading | How this policy meets it |
|---|---|---|
| 3.1.1 | Policy | This document; section 2 statements |
| 3.1.2 | Competence | Section 3.1 competence column; section 3.3 records |
| 3.1.3 | Awareness | Section 3.3 training |
| 3.1.4 | Program scope | Section 1.2 |
| 3.1.5 | License obligations | Section 4 and the licence obligation register |
| 3.2.1 | Access | Section 10 published inquiry contact |
| 3.2.2 | Effectively resourced | Section 3.2 |
| 3.3.1 | Bill of materials | Section 5.2 |
| 3.3.2 | License compliance | Sections 4 and 5.1 |
| 3.4.1 | Compliance artifacts | Section 7 |
| 3.5.1 | Contributions | Section 8 |
| 3.6.1 | Conformance | Section 12 self-assessment |
| 3.6.2 | Duration | Section 12 review cycle |

### 13.2 ISO/IEC 18974:2023 (security assurance)

| Clause | Heading | How this policy meets it |
|---|---|---|
| 4.1.1 | Policy | This document; OSP-POL-003 |
| 4.1.2 | Competence | Section 3.1 (product security lead) |
| 4.1.3 | Awareness | Section 3.3 |
| 4.1.4 | Program scope | Section 1.2 |
| 4.1.5 | Standard practice implementation | Section 6 procedures (threat identification, detection, follow-up, customer communication, post-release monitoring, pre-release testing, risk verification, sharing) |
| 4.2.1 | Access | Section 10 and the vulnerability disclosure channel |
| 4.2.2 | Effectively resourced | Section 3.2 |
| 4.3.1 | Software bill of materials | Section 5.2 |
| 4.3.2 | Security assurance | Section 6 |
| 4.4.1 | Completeness | Section 12 self-assessment |
| 4.4.2 | Duration | Section 12 review cycle |

## 14. Glossary and references

<!-- Guidance: Define the terms the way this policy uses them, and keep the references current. -->

### 14.1 Glossary

| Term | Meaning in this policy |
|---|---|
| Supplied software | Software the company distributes to third parties in any form |
| Compliance artefacts | Notices, licence texts, source code and other materials a licence requires with a distribution |
| Identified licence | The licence determined for a component after review, recorded with an SPDX identifier |
| SBOM | Software bill of materials: an inventory of components and their relationships |
| OSPO | Open source program office: the function that runs this program |
| DCO | Developer Certificate of Origin, a per-commit statement of the right to contribute |
| CLA | Contributor Licence Agreement, a contract granting rights in contributions to a project |
| VEX | Vulnerability Exploitability eXchange: a statement of whether a known vulnerability affects a product |

### 14.2 References

| Reference | Edition | Notes |
|---|---|---|
| ISO/IEC 5230:2020, Information technology, OpenChain Specification | Published 15 December 2020; confirmed 30 July 2026 | Official text: ISO/IEC JTC 1, purchase or licensed access: https://www.iso.org/standard/81039.html. The OpenChain project also publishes the same specification text (version 2.1) under CC BY 4.0 at https://github.com/OpenChain-Project/License-Compliance-Specification |
| ISO/IEC 18974:2023, Information technology, OpenChain security assurance specification | Published 14 December 2023 (ISO open data) | Official text: ISO/IEC JTC 1, purchase or licensed access: https://www.iso.org/standard/86450.html. OpenChain publishes a functionally identical version under CC BY 4.0 at https://github.com/OpenChain-Project/Security-Assurance-Specification |
| OpenChain Project, openchainproject.org | Current | Self-certification checklists and conformance registration |
| Developer Certificate of Origin, developercertificate.org | Version 1.1 | Contribution sign-off (section 8.2) |
| SPDX License List, spdx.org/licenses | Current | Licence identifiers (section 4) |
| Related templates | Current | `dev/dependency-management-policy`, `security/sbom-vex-policy`, `security/supply-chain-security`, `compliance/software-licence-review`, `dev/governance`, `dev/contributing` |

## Standard and licence note

Structure aligned with ISO/IEC 5230:2020 (OpenChain Specification) and ISO/IEC 18974:2023 (OpenChain security assurance specification). Clause numbers and short headings are cited for mapping only; the policy wording, roles, categories, tables and examples are original and do not reproduce the standards. Official text: ISO/IEC JTC 1, purchase or licensed access: https://www.iso.org/standard/81039.html and https://www.iso.org/standard/86450.html; the OpenChain project publishes equivalent specification texts under CC BY 4.0. A revised edition of the licence compliance specification (OpenChain 3.0, proposed as a new ISO/IEC 5230 edition) was in draft when this template was written; check the current editions before claiming conformance. The licence categories are illustrative and must be set with counsel. Corvid Commerce is fictional. This is a documentation format, not legal advice; check the current official texts and a qualified professional. Template licence: MIT.