The OpenChain Project was present at the Linux Foundation Legal Summit in October, and there was a presentation by Matthew Crawford of Arm, a member of the OpenChain Governing Board. He covered current project activities, with a special focus on the new AI System Bill of Materials Compliance Guide and the emerging Cross-Industry SBOM Quality Guide.
First Meeting, Big Discussion:
The OpenChain Meridian 22 Work Group met with Ciaran O’Riordan of Eclipse Foundation as a special guest. The core topic was EU regulation and how it impacts countries along the Meridian 22 area. This was a lot of ground to cover, and provided a great example of the type of in-depth discussion OpenChain communities can engage in.
Watch the Meeting:
Read the Slides:
Be Part of Future Meetings:
We will arrange future meetings and hold online discussions via the official mailing list, and everyone is invited to join: https://lists.openchainproject.org/g/meridian22-wg
We Discussed:
- OpenChain Project News
- Specification Work Group – CRA, other regulations and our standards
- Education Work Group – Update on Status and Community Work Items
- Any Other Business?
A reminder for those in North America – while this edition of the monthly call happens in the darkest hours of the night for you, we also have a monthly North America / Europe call that works better for Western time zones. Check out the schedule for this and all our other meetings here:
https://openchainproject.org/participate
Watch the Recording:
Check out the Meeting Slides:
Coming Next:
- Expect a new edit cycle for the specifications, and for enhancement of OpenChain training material
Join Our Work:
Everyone is welcome to be part of the Specification Work Group. You can join their mailing list here:
https://lists.openchainproject.org/g/specification/
You can find and be part of all OpenChain calls through our participation page here:
https://openchainproject.org/participate
“OSPO Now is delighted to announce our acceptance as an official OpenChain partner,” says Raphael Sonabend-Friend, Co-Founder, OSPO Now. “This recognition underscores our commitment to helping organisations build, manage, and mature their open source programs with confidence. Through our services, OSPO Now enables teams to outsource Open Source Program Office (OSPO) requirements, from community engagement to compliance management. Partnering with OpenChain further validates the expertise of our team in guiding organizations along their open source compliance journey, ensuring they can adopt and develop open-source software in a safe, secure, and responsible way.”
“An extensive community of service providers is key to enabling choice across the market,” says Shane Coughlan, OpenChain General Manager. “One reason we are delighted to work with OSPO Now is to enable such choice. Another is that the emergence of OSPOs has provided a pivotal opportunity for companies to improve their process management around open source, and direct expertise in this domain is a vital part of ensuring health.”
About OSPO Now
OSPO Now’s mission is to empower organizations through the strategic use of open source, fostering sustainability and maximising impact. Through training, working groups, hands-on development, and consulting, OSPO Now supports the creation, consumption, and deployment of open source software, as well as the wider practice of open science.
OSPO Now’s mission is to empower organizations through the strategic use of open source, fostering sustainability and maximising impact. Through training, working groups, hands-on development, and consulting, OSPO Now supports the creation, consumption, and deployment of open source software, as well as the wider practice of open science.
Learn more: osponow.com
About This Webinar:
A special panel on Containers and Compliance from the OpenChain Project hosted by Chris Wood, Chair of Specification. This panel will feature Caren Kresse, Heather Meeker, Mary Hardy and Till Jaeger.
More Details:
Join Chris and a panel of experts for an informal chat exploring the key challenges in achieving comprehensive license compliance within containerised environments. This discussion will cover three critical areas:
(1) Package Manager Transparency: The current products of several key package managers do not contain sufficient information to achieve true license compliance as many only reveal the top-level license. More often than not they fail to provide the necessary information (source code and SBOMs) for a comprehensive license assessment. Increased transparency and standardization in this area are crucial.
(2) Another cause lies with the design limitations of License Scanners: While license scanners are improving, many still lack the capability to deeply analyze binaries, resulting in incomplete and therefore inaccurate license compliance reports. The development of more robust and sophisticated scanning technologies is essential to address this gap.
(3) A need for improved developer awareness of container license and copyright information to help the community to achieve a comprehensive container license compliance process is necessary to achieve a shift in developer practices. A greater understanding of open source licensing and the importance of proper metadata Management is essential, as we are already doing through the OpenChain education and specifications work groups.
As always, we focused on the question of “how do we use SBOMs in production, large-scale and complex supply chains?”
This Meeting Discussed:
- The content and release date of the Guide to SBOM Quality
- Any Other Business
Watch the Meeting:
Learn More About This Study Group:
Our SBOM Study Group brings all our various SBOM-related activities together and helps answer the question of “how do we use SBOMs in production, large-scale and complex supply chains?” Our original kick-off call has all the details.
Get Involved:
Everyone is welcome to be part of this study group! OpenChain has free, open access to all its work groups and study groups. Just turn up, and listen in, and contribute comments, ideas and suggestions.
✉️ We have a dedicated mailing list: https://lists.openchainproject.org/g/sbom
💻 We have a dedicated GitHub Repo: https://github.com/OpenChain-Project/SBOM-sg
Attend Future Meetings:
You can find and get the dial-in details for all future meetings from our participate page here: https://www.openchainproject.org/participate
We had a straightforward agenda, building on the earlier North America / Europe workshop:
Item #1: We have completed the AI SBOM Compliance Management Guide
Item #2: We are going live on 20th October – your help with promotion is requested
Item #3: We have started coordination with Lord Clement-Jones in the UK, UK working group, Spec Group, LF legal conference and PyTorch conference
Item #4: Early market feedback can be used to update the guide for solution/market fit – Your help is requested
Item #5: FINOS working group
Item #6: Any Other Business
Watch the Recording:
Get Involved:
Everyone is welcome to be part of this activity! OpenChain has free, open access to all its work groups and study groups. Just turn up, and listen in, and contribute comments, ideas and suggestions.
✉️ We have a dedicated mailing list for the AI Work Group: https://lists.openchainproject.org/g/ai
Attend Future Meetings:
You can find and get the dial-in details for all future meetings from our participate page here: https://www.openchainproject.org/participate
This Meeting Focused on Comments for the CISA SBOM Minimum Elements Proposal for 2025
The comments were as follows:
The comments below are provided by the OpenChain Telco work group. See https://github.com/nokia/Telco-WG
This work group has produced the “OpenChain Telco SBOM Guide” that is available at https://github.com/nokia/Telco-WG/blob/main/OpenChain-Telco-SBOM-Guide_EN.md
This document defines what is a quality SBOM in the telecommunication industry, but it is generic enough to be used by other industries.
It incorporates the “NTIA Minimum Elements” from 2021. We plan to update this guide to be compatible with the CISA 2025 Minimum Elements document when it is finalized.
Nokia has provided a tool to validate an SBOM against the Guide. It is available at https://pypi.org/project/openchain-telco-sbom-validator/
General comments
To make the document easier to understand, it would be good to include concrete examples.
Also, it would be good to provide in an appendix the mapping of the different elements from appendix A in SPDX 2.3, SPDX 3.0 and CycloneDX 1.6.
The document uses the words “must”, “should” and “may”, but it is not clear what the exact meaning is. Are some fields mandatory and others only recommended but optional? It would be good to use BCP 14 [RFC2119] [RFC8174] to be clear.
Data Fields
Component Name
The document asks for multiple entries.
How should that be represented in SPDX and CycloneDX that allow only one value?
Using a hack like putting the different entries in the same field separated by a semi-colon seems very ugly.
An example of multiple names with justification would be useful here.
Component Version
We do not understand “If the Software Producer does not provide a version, then the SBOM Author may substitute the creation date of the file.”
What is the “creation date of the file”? A component might be composed a multiple files. Where do we find a date?
Also, “to specify a change in software from a previously identified version” does not seem to be a satisfactory definition. It means that the first release would have no version.
Software Identifiers
The documents asks that “if there are multiple software identifiers, (…) the SBOM Author should include all of them”.
This will be difficult to implement. It seems better to stick with one identifier, e.g. PURL (while of course allowing multiple identifiers, but not mandating all of them). Conversion tools exist, like purl2cpe https://github.com/scanoss/purl2cpe
Component Hash
It is unclear whether several hashes with different algorithms are allowed. This should be the case.
Dependency Relationship
It is unclear what “Component A is largely derived from Component B” really means.
Same for “is a descendant of another piece of software”.
Tool Name
If you mandate the tool name, you should mandate the tool version also.
A different version of a tool might give different results.
Timestamp
We consider that an SBOM should not change. The timestamp is the time when it was generated.
If an SBOM is recreated, it is a different one, not an update.
Generation Context
Why do you not refer to the “CISA SBOM Type”? https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf
Here you use a different terminology: “before build, during build, after build”.
Does that mean that the “CISA SBOM Type” document is obsolete?
Automation Support
It is difficult to see what you mean by “deprecated versions” of formats.
Usually, there is some form of compatibility between formats.
You should at least list what you consider as deprecated formats at the time of publishing of the document.
Practices and Processes
Frequency
Again, we do not like the notion of “revised SBOM”. Replace “should issue a revised SBOM” by “should issue a new SBOM”.
Coverage
The notion of depth is unclear. We do not understand what is meant by “There is no minimum depth.”
Does that mean that all transitive dependencies must be provided?
That seems in contradiction with what is discussed in “Known Unknowns”.
Known Unknowns
There is no native way to express this in SPDX.
So, how should that be expressed? Please provide guidance and examples.
Appendix A
There is some inconsistency in the table about fields that can have one or multiple values.
Software Producer
- multiple values
- so that should be “Software Producers (to be consistent with Software Identifiers)
Component Hash
- it is unclear whether several hashes with different algorithms are allowed
License
- multiple values
- that should be “Licenses“
Dependency Relationship
- multiple values
- that should be “Dependency Relationships“
- The relationship(s)
Tool Name
-
- multiple values
- that should be “Tool Names“
- The name(s) of the tool(s)
Watch the Recording:
Be part of this:
Everyone is welcome to be part of this study group! OpenChain has free, open access to all its work groups and study groups. Just turn up, and listen in, and contribute comments, ideas and suggestions.
✉️ We have a dedicated mailing list:
https://lists.openchainproject.org/g/telco
💻 We have a dedicated GitHub Repo:
https://github.com/OpenChain-Project/Telco-WG
You are also welcome to participate in any of our other working groups around the world:
Erlangen, Germany – Elektrobit announces that it conforms to OpenChain ISO / IEC 5230:2020 across its entire product portfolio. OpenChain is the International Standard for open-source license compliance and is designed to build trust in the supply chain. The standard defines the key requirements of a quality open-source compliance program. This activity is in furtherance of Elektrobit’s long-standing commitment to the open-source governance and management.
The new accreditation will enable Elektrobit customers to have increased confidence in the company’s ability to manage the use of open-source software across its product portfolio i.e. primarily consists of AUTOSAR software solutions, In-vehicle network and Secure vehicle solutions, Linux for Safety Applications, and User experience.
There are growing concerns regarding the need for robust management of security vulnerabilities and license compliance across software supply chain. This concern is also reflected in regulatory frameworks such as UN Regulation No. 155 – Cyber security and cyber security management system and U.S. Executive Order 14028, “Improving The Nation’s Cybersecurity” emphasizing the requirement for Software Bill of Materials (SBOMs) for software supplied. Elektrobit aims to supports its customers in all spheres of security and license management regarding the safe and compliant usage of open-source software.
OpenChain encourages self-certification, independent assessment, and third-party certification as options for entities seeking to address the risk profile of their supply chain.
“Elektrobit continues to lead in securely developing software. We realized the importance of leveraging Open-Source Software and recognized the need for a robust process to manage the use of it in our products,” says Gaurav Gupta, Open Source Manager at Elektrobit.
“It is hard to overstate the importance of today’s announcement,” says Shane Coughlan, OpenChain General Manager. “Elektrobit has one of the deepest industry pedigrees in bringing increased peace of mind to enterprise and governmental organizations. Certifying their open-source software management underlines their commitment to excellence and serves as a beacon for other companies to follow.”
About Elektrobit
Elektrobit is the trusted partner in the transition to the software-defined vehicle (SDV). With over 35 years of award-winning automotive software expertise, Elektrobit’s innovative portfolio and comprehensive SDV ecosystem empower OEMs, Tier 1s, along with ODMs and Big Tech to build future-ready solutions with speed and confidence. Its SDV building blocks include operating systems, middleware, embedded software, digital cockpit solutions, engineering services, and development workflows – driving faster innovation and seamless integration across the vehicle lifecycle. Elektrobit software powers over five billion devices in more than 630 million vehicles worldwide. It is a wholly owned, independently operated subsidiary of AUMOVIO.
About the OpenChain Project
The OpenChain Project has an extensive global community of over 1,000 companies collaborating to make the supply chain quicker, more effective and more efficient. It maintains OpenChain ISO/IEC 5230, the international standard for open source license compliance programs and OpenChain ISO/IEC 18974, the industry standard for open source security assurance programs.
About The Linux Foundation
The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js, ONAP, PyTorch, RISC-V, SPDX, OpenChain, and more. The Linux Foundation focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at www.linuxfoundation.org.
Check Out The Publicly Announced Community of Conformance:
https://openchainproject.org/community-of-conformance
The OpenChain Project provided a Global Update at Open Source Tech Day 2025 event in Seoul, South Korea on the 21st of October 2025. This event brought together government, industry and academic experts to discuss the intersection of open innovation and commerce. Shane Coughlan, OpenChain General Manager, took the stage to represent the community and encourage a more trusted supply chain.
