OpenChain ISO/IEC 5230: Open Source License Compliance Programs

Open source license compliance means meeting the obligations that come with the open source components in your software, such as providing license texts, attribution notices or, for some licenses, the corresponding source code. ISO/IEC 5230, known as the OpenChain Specification, is the international standard that defines what a quality program for doing this looks like. It is maintained by the OpenChain Project at the Linux Foundation and became an ISO standard in December 2020.

Its companion, ISO/IEC 18974, covers open source security assurance, focusing on known vulnerabilities. Large companies in automotive, telecoms and electronics increasingly ask suppliers to conform to these standards, and updated versions were approved in 2025 for release in 2026. This guide explains the requirements, conformance options, typical license obligations, tooling and how a software company can build a practical program.

What is ISO/IEC 5230?

ISO/IEC 5230:2020 is OpenChain Specification version 2.1, published as an international standard. It identifies the key requirements of a quality open source license compliance program. It is deliberately short and focused on what must be in place, not how to do it, so organisations of any size can apply it using their own processes and tools. It applies to organisations that use open source in software they distribute, supply or deploy.

The standard emerged from collaboration among companies that wanted a common way to trust the open source compliance of their suppliers. Instead of each customer auditing each supplier differently, suppliers can show conformance to one standard.

Why open source license compliance matters

Open source licenses grant broad rights but come with conditions. Permissive licenses, such as MIT, BSD and Apache 2.0, typically require keeping copyright and license notices, and Apache 2.0 includes notice and patent terms. Copyleft licenses, such as the GPL family, may require providing corresponding source code under the same license when distributing binaries, and the AGPL extends obligations to software offered over a network. Failing to meet obligations can lead to legal disputes, injunctions, forced disclosure of code, product recalls in hardware contexts, and loss of customer trust. A program makes sure obligations are identified and met consistently.

Typical obligations by license family

License family	Examples	Typical obligations when distributing
Permissive	MIT, BSD, ISC	Keep copyright and license notices with the software.
Permissive with patent terms	Apache 2.0	Keep notices, include the license and any NOTICE file, state significant changes.
Weak copyleft	LGPL, MPL, EPL	Provide source of the licensed component and your modifications to it; conditions on how it is linked or combined.
Strong copyleft	GPL v2, GPL v3	Provide complete corresponding source code of derivative works under the same license; GPL v3 adds installation information for some consumer devices.
Network copyleft	AGPL v3	Offer source code to users interacting with modified software over a network.

This is a simplified overview, not legal advice. Exact obligations depend on the license text, how the component is used and how the software is distributed, so a program should include legal review for unclear cases.

Distribution scenarios

• SaaS: running software on your servers is usually not distribution under most licenses, but the AGPL can still require offering source, and any software you ship to customers, such as agents, SDKs or browser code, is distributed.
• Mobile apps: apps are distributed, so notices must be included, typically in an "open source licenses" screen.
• Firmware and devices: embedded Linux and other copyleft components often require providing source code and build scripts, and GPL v3 may require installation information.
• On-premises and desktop software: installers must include notices and any required source code or offers.
• Custom software for clients: delivering code to a client is distribution, so the client should receive an SBOM and notices.

Is it mandatory or voluntary?

Voluntary. License obligations themselves are legally binding, but how you manage them is up to you. ISO/IEC 5230 becomes effectively required when customers include OpenChain conformance in supplier requirements, which is increasingly common in automotive and telecom supply chains.

The requirements of ISO/IEC 5230

Area	What is required
Program foundation	A written open source policy communicated to staff; identified roles and responsibilities with competence and awareness; a defined program scope; and a process to review and record license obligations.
Relevant tasks	A way for external parties to contact the organisation about open source compliance, and adequate resources and staffing for program tasks.
Open source content review and approval	A process to create and manage a bill of materials of open source components in supplied software, and a process to handle license use cases.
Compliance artifacts	A process to create and deliver required compliance artifacts, such as notices, license texts and source code, and to archive them for a reasonable period.
Understanding open source community engagements	A policy governing contributions to open source projects, with a process to implement it.
Adherence to the specification	Confirmation that the program meets all requirements, and that conformance is maintained, with periodic review.

Conformance options

• Self-certification: the organisation answers the OpenChain online questionnaire; if it can answer yes to every requirement, it can declare conformance. The organisation is responsible for the accuracy of its claims. This is free and widely used.
• Independent assessment: an external party reviews the program and confirms conformance.
• Third-party certification: an accredited or recognised certification provider audits the program and issues a certificate.

Customers may specify which option they accept. Self-certification is often enough for initial supplier qualification; higher-risk relationships may require independent assessment or certification.

ISO/IEC 18974: open source security assurance

ISO/IEC 18974:2023 defines the key requirements of a quality open source security assurance program. It mirrors the structure of ISO/IEC 5230 but focuses on identifying known vulnerabilities in open source components in supplied software, tracking them, assessing risk and applying remediation, with defined roles, policy and processes. It complements ISO/IEC 5230 and fits well with SBOM practices. Organisations often implement both together.

Planned updates

In June 2025, the OpenChain Steering Committee approved proposed updates to both the license compliance and security assurance specifications. According to OpenChain, the updated versions were planned for release in 2026, would receive new ISO numbers, and would supersede the current standards, while the existing standards remain a usable option for supply chains. Check the OpenChain Project for the publication status before planning a conformance cycle.

How to build a program, step by step

1. Write an open source policy covering use, approval, distribution obligations and contributions.
2. Assign roles: a program manager, legal support, engineering contacts, and a public contact point for compliance enquiries.
3. Train staff on the policy and common license obligations.
4. Inventory components automatically using software composition analysis and generate an SBOM for each release.
5. Review licenses against policy, with an approval path for licenses needing legal review.
6. Produce compliance artifacts: third-party notices, license texts, and source code offers or packages where required.
7. Archive artifacts per release.
8. Add security assurance: monitor components for known vulnerabilities and remediate per ISO/IEC 18974.
9. Self-certify and review the program periodically.

Contributing to open source

ISO/IEC 5230 also expects a policy on contributions to open source projects. Developers often fix bugs or add features upstream, which benefits everyone but can raise questions about intellectual property, confidential information and employer approval. A contribution policy typically explains which contributions need approval, how to handle contributor license agreements, which accounts and email addresses to use, and how to avoid disclosing confidential code. Clear rules encourage healthy contribution while protecting the organisation and its clients.

Supplier requirements down the chain

Most organisations receive software from suppliers as well as delivering it to customers. A complete program asks suppliers for SBOMs, license information and their conformance status, and checks incoming deliveries before redistribution. OpenChain's supply chain focus is exactly this: when every link conforms, compliance information flows reliably from the original component authors to the final product.

Documentation you will need

• Open source policy and contribution policy.
• Role assignments and training records.
• Program scope definition.
• SBOMs or component lists per release.
• License review and approval records.
• Compliance artifacts and archives.
• Vulnerability tracking records.
• Conformance declaration or certificate.

Tools and technologies

• Software composition analysis tools to detect components and licenses.
• SBOM formats such as SPDX, itself an ISO/IEC standard (5962), and CycloneDX.
• License identifiers from the SPDX license list.
• Notice generators that build third-party notice files from SBOMs.
• Vulnerability databases and scanners for open source components.
• CI integration so checks run on every build.

Handling source code requests

ISO/IEC 5230 requires a way for third parties to contact the organisation about open source compliance. In practice, this means publishing a contact address, logging requests, responding within a reasonable time, and being able to provide the correct source code for the specific version the requester received. That last point is the hardest: if source packages and build scripts are not archived per release, reconstructing them later can be difficult. Archiving compliance artifacts at release time avoids this problem.

Open source in AI models and data

Licensing questions now extend beyond code. AI models and datasets are released under a variety of licenses, some open source and some with use restrictions, and model weights may come with conditions that differ from the code used to run them. Organisations building AI features should include models and datasets in their inventories, record their licenses and terms of use, and review them with the same discipline as code dependencies.

Benefits and limitations

• Benefits: fewer legal and reputational risks, faster customer due diligence, a common language with supply chain partners, and better visibility of components for security.
• Limitations: self-certification relies on honesty; conformance shows a program exists, not that every release is perfect; and the standards are being updated, so programs will need light revision.

Timeline and cost considerations

A small or mid-sized software company can set up a conformant program in a few weeks to a few months, mostly by writing a policy, assigning roles, and automating component scanning and notice generation. Self-certification is free. Costs come from tooling, legal review time and any external assessment or certification.

Common mistakes

• No inventory of open source, especially transitive dependencies and copied code.
• Missing notices in mobile apps, firmware and installers.
• Ignoring AGPL obligations for software offered as a service.
• Developers contributing code without a contribution policy.
• Treating license scanning as a one-off rather than per release.
• No public contact point for compliance requests.

Best practices

• Integrate license and vulnerability checks into pull requests and builds.
• Maintain an allow list, a review list and a deny list of licenses.
• Generate and archive SBOMs and notices for every release.
• Give customers SBOMs and notices with deliveries.
• Track open source in container base images and build tools too.

We include dependency inventories, license checks, SBOMs and third-party notices in the software we deliver through our custom software development and web application development services.

How it relates to other frameworks

Framework	Relationship
SBOM	The component inventory that both OpenChain standards rely on.
SLSA	Build integrity, complementing license and vulnerability management.
NIST SSDF	Secure development practices including third-party component management.
Cyber Resilience Act	EU law requiring manufacturers to identify components and handle vulnerabilities.
ISO/IEC 27001	Management system into which an open source program can integrate.

Real-world example

An Indian embedded software company supplying infotainment modules to a European tier-one automotive supplier is asked to confirm ISO/IEC 5230 conformance. It writes an open source policy, names a compliance manager and an engineering lead, trains its developers, adds composition analysis to its CI pipeline, generates an SPDX SBOM and notice file for each firmware release, provides GPL source packages on request, archives artifacts for each release, and self-certifies to both ISO/IEC 5230 and ISO/IEC 18974. The customer accepts the self-certification and asks for SBOMs with each delivery.

Next steps

1. Write an open source policy.
2. Assign roles and a contact point.
3. Automate component and license scanning.
4. Generate SBOMs and notices per release.
5. Self-certify and track the 2026 updates.

Frequently asked questions

What is ISO/IEC 5230?

The international standard, also called the OpenChain Specification, defining the key requirements of an open source license compliance program.

What is ISO/IEC 18974?

The companion standard for open source security assurance, focused on managing known vulnerabilities in open source components.

Can I self-certify to OpenChain?

Yes. The OpenChain Project offers online self-certification; the organisation is responsible for the accuracy of its claims.

Is OpenChain conformance mandatory?

No, but customers in automotive, telecoms and electronics increasingly require it from their software suppliers.

Does ISO 5230 tell me which tools to use?

No. It defines what a program must achieve, not which tools or processes to use.

What are compliance artifacts?

Materials required by licenses, such as notices, license texts, attribution and corresponding source code.

Are new versions coming?

Updates were approved in 2025 for release in 2026 with new ISO numbers; existing standards remain usable.

Do SaaS companies need license compliance?

Yes, especially for AGPL components and any software distributed to customers, such as agents, apps or SDKs.

What is the difference between permissive and copyleft licenses?

Permissive licenses mainly require notices; copyleft licenses may require sharing source code of derivative works when distributed.

How does an SBOM help?

It lists components and licenses so obligations and vulnerabilities can be identified and managed.

Do I need a lawyer to comply?

Not for routine cases with clear licenses and policies, but legal review is advisable for unusual licenses, copyleft combinations and contribution agreements.

How often should conformance be reviewed?

Periodically, and whenever the program or standard changes; OpenChain expects conformance to be maintained over time.