ISO/IEC 5230:2020

Information technology — OpenChain Specification

This document specifies the key requirements of a quality open source license compliance program in order to provide a benchmark that builds trust between organizations exchanging software solutions comprised of open source software.

Titre manque

General Information

• Status: Published
• Publication Date: 14-Dec-2020
• ICS: 35.020 - Information technology (IT) in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9060 - Close of review
• Completion Date: 04-Jun-2031

Overview

ISO/IEC 5230:2020 - the OpenChain Specification - defines the key requirements for a quality open source license compliance program. Published by ISO/IEC and adopted from the OpenChain initiative, the standard provides a practical benchmark to build trust between organizations that exchange software solutions containing open source components. It focuses on the “what” and “why” of compliance programs (policy, roles, artifacts) rather than prescribing specific tools or processes, enabling flexible implementation across different sizes and industries.

Key topics and technical requirements

• Program foundation
  • A documented open source policy that is internally communicated.
  • Defined program scope (single product line to enterprise-wide).
  • Competence and awareness requirements: roles, responsibilities, training records and evidence of assessed competence.
• License obligations
  • A process to review identified open source licenses to determine obligations, restrictions and rights.
  • Verification materials (records) to demonstrate compliance activities.
• Relevant tasks and resourcing
  • Publicly accessible contact method for external open source inquiries.
  • Assigned accountability, allocated time and funding, and access to legal expertise for compliance decisions.
• Open source content review
  • Procedures for creating and managing an open source bill of materials (BoM) listing components and identified licenses.
  • Records showing identification, tracking, approval and archiving of component data.
• Compliance artifacts
  • Delivery of outputs such as attribution notices, source code, license copies, written offers and SPDX documents as part of the compliance artifact collection.
• Conformance
  • The specification defines verification materials required to demonstrate that a program is OpenChain conformant.

Keywords naturally integrated: ISO/IEC 5230, OpenChain Specification, open source license compliance, bill of materials, compliance artifacts, SPDX, open source policy.

Applications and who uses it

• Software development organizations seeking a repeatable, auditable approach to open source compliance.
• Legal, IP and compliance teams responsible for license risk management.
• Release engineers, product managers and DevOps teams producing distributed software (binary or source).
• Suppliers, distributors and integrators who need to build trust with customers by delivering consistent compliance artifacts.
• Companies engaging with open source communities and contributors who need defined processes for contributions and interactions.

Related standards and references

• SPDX (Software Package Data Exchange) - widely used format for exchanging BoM and license metadata; commonly used alongside ISO/IEC 5230.
• ISO/IEC JTC 1 adoption - ISO/IEC 5230 was adopted under the JTC 1 PAS procedure and originated from the Joint Development Foundation / OpenChain initiative.

ISO/IEC 5230 helps organizations standardize open source governance, reduce license risk, and streamline the delivery of compliance artifacts across the software supply chain.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 5230
First edition
2020-12
Information technology — OpenChain
Specification
Reference number
©
ISO/IEC 2020
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved

Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Terms and definitions . 1
3 Requirements . 2
3.1 Program foundation . 2
3.1.1 Policy . 2
3.1.2 Competence . 2
3.1.3 Awareness . 3
3.1.4 Program scope . 3
3.1.5 License obligations . 4
3.2 Relevant tasks defined and supported . 4
3.2.1 Access . 4
3.2.2 Effectively resourced . 4
3.3 Open source content review and approval . 5
3.3.1 Bill of materials . 5
3.3.2 License compliance . 6
3.4 Compliance artifact creation and delivery . 6
3.4.1 Compliance artifacts . 6
3.5 Understanding open source community engagements . 7
3.5.1 Contributions . 7
3.6 Adherence to the specification requirements . 7
3.6.1 Conformance . 7
3.6.2 Duration . 7
Annex A (informative) Language translations of this specification . 9

© ISO/IEC 2020 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see http://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html.
This document was prepared by the Joint Development Foundation (as OpenChain Specification) and
drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv © ISO/IEC 2020 – All rights reserved

Introduction
This document defines the key requirements of a quality open source license compliance program. The
objective is to provide a benchmark that builds trust between organizations exchanging software
solutions comprised of open source software. Specification conformance provides assurance that a
program has been designed to produce the required compliance artifacts (i.e., legal notices, source code
and so forth) for each software solution. This document focuses on the “what” and “why” aspects of a
program rather than the “how” and “when”. This ensures flexibility for different organizations of different
sizes in different markets to choose specific policy and process content that fits their size, goals and scope.
For instance, an OpenChain conformant program may address a single product line or the entire
organization.
This introduction provides the context for all potential users. Clause 2 defines key terms used throughout
this document. Clause 3 defines the requirements that a program must satisfy to achieve conformance. A
requirement consists of one or more verification materials (i.e., records) that must be produced to satisfy
the requirement. Verification materials are not required to be made public, though an organization may
choose to provide them to others, potentially under a Non-Disclosure Agreement (NDA).
This document was developed as an open initiative with feedback received from more than
200 contributors. Insight into its historical development can be obtained by reviewing the Specification
mailing list and Frequently Asked Questions (FAQs).

© ISO/IEC 2020 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 5230:2020(E)

Information technology — OpenChain Specification
1 Scope
This document specifies the key requirements of a quality open source license compliance program in
order to provide a benchmark that builds trust between organizations exchanging software solutions
comprised of open source software.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
compliance artifacts
a collection of artifacts that represent the output of a compliance program and accompany the supplied
software
Note: The collection may include (but is not limited to) one or more of the following: attribution notices,
source code, build and install scripts, copy of licenses, copyright notices, modification notifications,
written offers, open source component bill of materials, and SPDX documents.
2.2
identified licenses
a set of open source software licenses identified as a result of following an appropriate method of
identifying open source components from which the supplied software is comprised
2.3
OpenChain conformant
a program that satisfies all the requirements of this document
2.4
open source
software subject to one or more licenses that meet the Open Source Definition published by the Open
Source Initiative (see opensource.org/osd) or the Free Software Definition published by the Free
Software Foundation (see gnu.org/philosophy/free-sw.html) or similar license
2.5
program
the set of policies, processes and personnel that comprise an organization’s open source license
compliance activities
2.6
program participants
any organization employee or contractor that defines, contributes to or has responsibility for preparing
supplied software
Note: Depending on the organization, that may include (but is not limited to) software developers, release
engineers, quality engineers, product marketing and product management.
© ISO/IEC 2020 – All rights reserved 1

2.7
SPDX
the format standard created by the Linux Foundation’s SPDX (Software Package Data Exchange) Working
Group for exchanging bill of materials for a given software package, including associated license and
copyright information (see spdx.org)
2.8
supplied software
software that an organization distributes to third parties (e.g., other organizations or individuals)
2.9
verification materials
materials that demonstrate that a given requirement of the specification is satisfied
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3 Requirements
3.1 Program foundation
3.1.1 Policy
A written open source policy shall exist that governs open source license compliance of the supplied
software. The policy shall be internally communicated.
Verification material(s):
3.1.1.1 A documented open source policy.
3.1.1.2 A documented procedure that makes program participants aware of the existence of the
open source policy (e.g., via training, int
...