As always, we focused on the question of “how do we use SBOMs in production, large-scale and complex supply chains?” We are dealing with the reality of supply chains with many participants who have different levels of skill, use different formats, and perhaps follow different regulations or policies.
This meeting looked at two important pieces of analysis from the OpenChain Japan SBOM Sub-Group. The goal was to find common challenges, and how we can address them when we consider:
Process management as our focus (the management layer)
Previous OpenChain work in this field (e.g. the Telco SBOM Guide)
Other work around the world (e.g. emerging regulation etc.)
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.
The Elixir Project is pleased to share that the Elixir project now complies with OpenChain ISO/IEC 5230, the international standard for open source license compliance. This step aligns with broader efforts to meet industry standards for supply chain and cybersecurity best practices.
“Today’s announcement around Elixir’s conformance represents another significant example of community maturity,” says Shane Coughlan, OpenChain General Manager: “With projects – the final upstream – using ISO standards for compliance and security with increasing frequency, we are seeing a shift to longer-term improvements to trust in the supply chain.”
Why OpenChain Compliance Helps
By following OpenChain ISO/IEC 5230, we demonstrate clear processes around license compliance. This benefits commercial and community users alike, making Elixir easier to adopt and integrate with confidence.
Changes for Elixir Users
All future Elixir releases will include a Source SBoM in CycloneDX 16 or later and SPDX 2.3 or later formats.
Each release will be attested along with the Source SBoM.
These additions offer greater transparency into the components and licenses of each release, supporting more rigorous supply chain requirements.
Changes for Contributors
Contributions remain under the Apache-2.0 License. Other licenses cannot be accepted.
The project now enforces the Developer Certificate of Origin (DCO), ensuring clarity around contribution ownership.
Contributors will notice minimal procedural changes, as standard practices around licensing remain in place. For more details, see the CONTRIBUTING guidelines
Commitment
These updates were made in collaboration with the Erlang Ecosystem Foundation, reflecting a shared commitment to robust compliance and secure development practices. Thank you to everyone who supported this milestone. We appreciate the community’s ongoing contributions and look forward to continuing the growth of Elixir under these established guidelines.
CSI Piemonte, an early adopter of OpenChain ISO/IEC 5230, has announced their fourth periodic recertification of the international standard for open source license compliance processes.
“CSI Piemonte has renewed its self-certification to ISO/IEC 5230:2020 for the fourth time, aware of its decades-long aptitude to implement, acquire, and publish open source software,” says Marco Alberto Panepinto, Open Source Subject Matter Expert at CSI Piemonte. “Italian law, in particular, requires public administrations to publish self-produced software on the national Developers Italia catalog, on which CSI Piemonte publishes the products implemented for local Piedmontese bodies, including mainly the Piedmont Region. Our processes are aimed at providing and promoting the creation and control of open source software, aimed at reuse by other public administrations, as our legislation provides. It is therefore since 2020 that we have adhered to the standard and we are proud to continue pursuing the goal of making our software open.”
“In recent months we have highlighted recertification activity around our standards to underline the concept of sustainable approaches to software management,” says Shane Coughlan, OpenChain General Manager. “Continuity in supply chain management is key to ensure that issues are minimized and productivity is maximized. We are delighted to collaborate with CSI Piemonte on yet another reminder of this important point, and the suitability of OpenChain standards for such long-term management.”
About CSI Piemonte
CSI Piemonte has promoted technological innovation and digital transformation for public administrations since 1977. OpenChain is delighted to welcome them to our community of conformance.
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 linuxfoundation.org.
Collabora has recently completed its regular 18 month renewal of ISO/IEC 5230 conformance via self-certification, and is highlighting this activity for the benefit of the wider community. This underlines an important principle of standard adoption and use: sustainability through periodically checking processes to ensure their integrity.
“Our renewed ISO/IEC 5230 certification demonstrates Collabora’s unwavering commitment to maintaining the highest standards of compliance to open-source licenses,” says Olivier Potin, Chief Operating Officer at Collabora. “Through OpenChain, we ensure our customers have complete visibility into their software supply chain while guaranteeing compliance with open source licensing requirements. This certification reinforces our position as a trusted partner in delivering open source solutions.”
“The principle of ensuring continued conformance to a standard is a key part of genuine sustainability,” says Shane Coughlan, OpenChain General Manager. “We appreciate Collabora’s decision to publicly highlight their example in double-checking process integrity, and helping to inspire similar long-term approaches in the supply chain.
About Collabora:
Collabora is a global consultancy specializing in delivering the benefits of Open Source software to the commercial world. Whether it’s the Linux kernel, graphics, multimedia or machine learning, Collabora’s expertise spans across all key areas of Open Source software development. By harnessing the potential of community-driven projects, and re-using existing components, Collabora helps its clients focus on creating product differentiation, enabling them to develop the best solutions. From tailoring the latest Open Source technologies to your projects, to integrating Open Source methodologies into your organization, Collabora can help you navigate the ever-evolving world of Open Source. Learn more at collabora.com.
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 linuxfoundation.org.
We will be following up on the activities outlined above on the mailing lists, and we will continue our regular series of calls and meetings throughout the year.
OpenChain is looking at the challenge of addressing policy implementation and information fidelity in SBOM. Suppliers provide different SBOM or document formats. Users need to consolidate them.
Example analysis from the Japan SBOM Sub-Group:
The OpenChain Japan SBOM Sub-Group has been conducting an analysis in Japanese. This is one of several discussions around the world, and it has been consolidated into a detailed document:
We are actively considering all aspects of SBOM Quality, and you are invited to be part of this via our global mailing list. Discussions happen here in English:
Lack of Accuracy in SBOM Information There is a lack of consistent and accurate information about package details such as package names, versions, and supplier names because different departments or providers use varying formats.
Differences in Package Name Notation Even for the same component, different vendors or departments might list slightly different names. For example, one company might mix the official name with abbreviations, include spelling mistakes, or vary between uppercase and lowercase letters, making it difficult for the recipient to consistently identify the component in the SBOM.
Differences in Version Information Notation For the same component, one source might list “1.0.0” while another might use “v1.0” or other formats, resulting in inconsistent version representations that can cause ambiguity.
Variations in Supplier Names Similarly, supplier names might vary. Official company names, abbreviations, or even outdated names that do not reflect mergers or acquisitions can be present, leading to an overall lack of consistency.
Inconsistency of Component Granularity When receiving SBOMs from multiple suppliers, one SBOM might provide detailed information at the file level, while another might compile data at the package level. This inconsistency in granularity requires the recipient to normalize the data.
Insufficient Source Information When Binaries Are Provided When receiving a binary along with its SBOM, detailed information about the source files (such as file listings, hash values, change histories, etc.) is often missing, making it challenging to manage vulnerabilities or assess risks.
Listing of Source Files A list detailing which source files are included in the component.
Hash Values of Source Files Hash values (e.g., SHA-256) for each file to prevent tampering and ensure integrity.
License Information Information about the license and copyright associated with each source file.
Patch or Diff Information Details on modifications or patches applied to the source code.
Build Environment and Configuration Information Data regarding the build environment, such as which compilers or build options were used.
Dependency Information Details about other libraries or components that this source code depends on.
Lack of Integration with Vulnerability Information There are cases where the component or library information listed in the SBOM is not adequately correlated with known vulnerability information (such as security advisories, CVEs, or PSIRT reports).
Lack of Integration between SBOM and Vulnerability Databases Since there isn’t a consistent method to automatically link each SBOM entry (e.g., package name, version, supplier details) with subsequently discovered vulnerability information (for example, CVE numbers or vulnerability details), it becomes difficult to pinpoint which vulnerability affects which software component.
Inconsistency in Reporting Channels and Contact Points When vulnerability information is provided internally (via PSIRT or a security team) or externally, there is often a lack of clarity regarding where in the SBOM this information should be incorporated, or which department should handle it. This can delay communication and hinder prompt responses during vulnerability discovery and mitigation.
Mismatch in Information Sharing and Coordination Between Upstream and Downstream There is often a disconnect between the SBOM provided by upstream vendors and the information managed by the manufacturer assembling the final product.
Use of Different Formats or Standards When the SBOM format or the security management standards of each company differ, it becomes challenging to uniformly interpret and reconcile the information, causing the assessment of risk or the need for countermeasures to rely heavily on individual discretion.
Disjointed Internal Processes If there is no routine process for information updates or feedback between the upstream vendor (providing the SBOM) and the downstream final product manufacturer or security team (handling vulnerability information), it can hinder early detection or impact evaluation of vulnerabilities.
Unclear Accountability in Contracts or Internal Processes There is an issue over ambiguity regarding how much information should be requested within contractual obligations for SBOM provision, and who should be responsible (e.g., quality control or PSIRT) for addressing inquiries if internal communication processes are insufficient.
Diversity in SBOM Formats and Standards Currently, multiple formats (SPDX, CycloneDX, JSON, Excel, etc.) exist without unified quality guidelines or evaluation criteria, resulting in variable judgment on the recipient side.
Difficulty Ensuring the Trustworthiness of Altered SBOMs Sometimes the SBOM generated by a vendor is different from the one generated from an in-house build at the manufacturer. This discrepancy makes it challenging to assess the impact on vulnerability evaluation and risk management.
Lack of Transparency in the Modification Process When an SBOM is modified through several departments or tools after its initial generation, if the modification history or details are not adequately recorded or disclosed, it becomes difficult to verify whether the final SBOM matches the original source.
Risk of Human Error in Manual Modifications If the SBOM is manually corrected or supplemented, there is a high risk of input errors or inadvertent modifications, which can lead to divergence from the original, accurate information, compromising reliability.
Variability in Automatic Generation Processes When multiple automated tools or processes are involved in generating the SBOM, the differences in the output format or content among tools may inadvertently result in loss or alteration of information during integration or editing.
Overlooking of Vulnerability Information Due to Modifications Altered SBOMs might omit or edit crucial details regarding vulnerabilities or dependency information that should be included, leading to inadequate internal or external security assessments.
Lack of Clear Definition for Additional Information Expected in an SBOM For example, there is no clear standard definition for the specific items (such as hash values, timestamps, or listings of source files) that should be included in the SBOM. This leads to each company providing different sets of information, further complicating subsequent analysis or vulnerability assessments.
Insufficient Update Mechanisms and Contact Points When vulnerabilities are discovered, the absence or lack of a centralized contact point (such as a PSIRT department) and an effective communication mechanism regarding the SBOM information can cause delays in information transmission.
The checklist includes whether the SBOM is updated, including the display of update timestamps and a clearly indicated inquiry contact point.
Proposed Solutions and Automation Considerations:
Lack of Accuracy in SBOM Information
Checkpoints
The way each component’s package name, version, and supplier details are recorded
Consistency in the notation of names and version formats
Proposed Solutions (Processes/Mechanisms)
Establish naming and versioning rules based on industry standards or internal guidelines
Introduce an automated validation system (using regular expressions, etc.) to verify these items during SBOM generation
Set up a process for periodic reviews to identify inconsistencies and provide feedback
Automation Feasibility
Automatable: Checks for naming conventions or version formats can be validated using dedicated scripts or tools.
Manual Verification: Ambiguous cases or new exceptions may require human review.
Inconsistency of Component Granularity
Checkpoints
Identification of the granularity used in each SBOM (file level, package level, etc.)
Differences in the level of detail provided
Proposed Solutions (Processes/Mechanisms)
Clarify the “desired granularity” either industry-wide or internally, and adopt a unified format with corresponding guidelines
Build a conversion tool (intermediate tool) to normalize and standardize the granularity of the SBOM data received
Automation Feasibility
Automatable: It is possible to create parsers or conversion scripts that transform various SBOM formats into a unified one.
Manual Verification: In cases where the rules are complex, final verification might require human judgment.
Insufficient Source Information When Binaries Are Provided
Checkpoints
Presence of a source file list
Availability of hash values for each source file
Inclusion of license and copyright information
Documentation of patches/differences and change histories
Records regarding the build environment, compilers, and build options
Dependency information
Proposed Solutions (Processes/Mechanisms)
Mandate the inclusion of the above details as required fields during SBOM creation
Enhance automatic generation tools or adjust settings to include source information in the SBOM
Introduce processes that automatically extract and append necessary details from build logs or static analysis tools
Automation Feasibility
Automatable: It is feasible to integrate build systems with extraction processes to automatically append the required information during SBOM generation.
Manual Verification: A final review by humans may be necessary to ensure complete coverage.
Lack of Integration with Vulnerability Information
Checkpoints
The linking of each component’s version information to vulnerability databases (e.g., CVE, security advisories)
Documentation of contact points and update histories
Proposed Solutions (Processes/Mechanisms)
Develop a system that automatically correlates each SBOM entry with vulnerability information from relevant databases (e.g., through integration with vulnerability scanners)
Implement regular automated scans and an alerting system that ensures prompt action when vulnerabilities are detected
Clearly define and incorporate contact information within the SBOM for unified internal and external communication
Automation Feasibility
Automatable: Integration with vulnerability scanning tools and automated matching and alert systems can be programmed.
Manual Verification: Human oversight may be required to review alerts and determine the applicability of fixes.
Mismatch in Information Sharing and Coordination Between Upstream and Downstream
Checkpoints
Discrepancies between the SBOM provided by vendors and the internally managed SBOM of the final product manufacturer
Existence of update histories, difference reports, or integration processes to confirm consistency
Proposed Solutions (Processes/Mechanisms)
Establish a common repository to aggregate SBOM information from both upstream vendors and downstream manufacturers
Introduce regular synchronization processes (for example, periodic cross-check meetings or automated comparison tools for updates)
Use format conversion tools based on a unified standard to automatically verify consistency
Automation Feasibility
Automatable: Tools for comparing differences or integrating information via standardized formats can be implemented for automatic update checks.
Manual Verification: Evaluation of particular discrepancies or context-specific information might ultimately require human review.
Unclear Accountability in Contracts or Internal Processes
Checkpoints
Clarity on the scope of SBOM information provided and the designated responsible contact details
Documentation of responsibilities as per contractual agreements or internal rules
Proposed Solutions (Processes/Mechanisms)
Clearly state in contracts or SLAs what information is mandatory and who is responsible for it
Establish internal processes for escalation and inquiry handling, with documented contact points and periodic reviews
Embed inquiry management and update history functions directly into the SBOM system
Automation Feasibility
Automatable: For instance, recording contact information and update histories automatically on an SBOM system is achievable through programming.
Manual Verification: Contractual and organizational aspects may require document management and human oversight.
Diversity in SBOM Formats and Standards
Checkpoints
Identification of the SBOM output format (e.g., SPDX, CycloneDX, JSON, Excel, etc.)
Presence of mandatory fields that should be shared across formats
Proposed Solutions (Processes/Mechanisms)
Adopt unified rules or conversion tools based on industry standards (such as SPDX or CycloneDX)
Build a “format normalization process” to convert each company’s SBOM to a common intermediate format and define clear evaluation criteria
Automation Feasibility
Automatable: Using conversion tools or format checkers, it is possible to automatically verify compliance with established standards.
Manual Verification: Exceptional cases or minor adjustments post-conversion might still require human review.
Difficulty Ensuring the Trustworthiness of Altered SBOMs
Checkpoints
Availability of modification history, version control, or log information
Presence of digital signatures, hash values, or verification data to confirm authenticity
Proposed Solutions (Processes/Mechanisms)
Immediately after SBOM generation, attach a hash or digital signature to the original state so that any post-generation modifications can be detected
Implement a modification history management system (using version control, for example) and establish regular audit processes
Utilize automatic verification tools (for hash computation and signature verification) that ensure the SBOM’s integrity
Automation Feasibility
Automatable: Digital signatures and hash verification processes can be entirely automated using software tools.
Manual Verification: In some cases, audits or final checks may still require human review.
Lack of Clear Definition for Additional Information Expected in an SBOM
Checkpoints
Whether the SBOM includes the additional required fields (hash values, timestamps, source file list, license information, etc.)
Proposed Solutions (Processes/Mechanisms)
Develop an industry-wide or internal checklist defining the mandatory metadata that should be included in an SBOM
Employ automated generation or static analysis tools to check for the presence of these essential details and trigger alerts if any are missing
Hold periodic reviews to evaluate and update the additional required items as needed
Automation Feasibility
Automatable: It is possible to build an automated validation tool based on a checklist of requirements.
Manual Verification: A human review might still be necessary to assess the thoroughness of these guidelines.
Insufficient Update Mechanisms and Contact Points
Checkpoints
Inclusion of update history and the record of the latest update time in the SBOM
Presence and clarity of the designated inquiry contact details
Proposed Solutions (Processes/Mechanisms)
Build a workflow that regularly updates the SBOM information and automatically notifies relevant parties when changes occur
Mandate the inclusion of inquiry contact information in the SBOM, and integrate it with a dedicated contact management system (such as a helpdesk or chatbot)
Document the inter-department communication rules regarding updates and establish internal audit processes
Automation Feasibility
Automatable: Update history management, notification systems, and automatic linking to inquiry contacts can be achieved with dedicated tools.
Manual Verification: Evaluation of inquiry responses or the appropriateness of updates might ultimately require human oversight.
S-core, Self-Certified for OpenChain ISO/IEC 5230 International Standard
S-core has officially obtained the OpenChain ISO/IEC 5230 certification, a globally recognised standard for open source compliance. This certification acknowledges the reliability and transparency of S-Core’s open source management system on an international scale.
OpenChain ISO/IEC 5230 is an open source compliance management standard created by The Linux Foundation’s OpenChain Project and published by the International Organization for Standardization (ISO). It provides guidelines to help companies effectively manage open source and mitigate legal risks.
Open Source Specialist S-core’s Journey
S-core is a company that specializes in open source services, leveraging its extensive experience in open source-based infrastructure development.
This company offers full-care service for open source use, from open source adoption, migration, technical support, to governance consulting in order to help customers establish management systems for safe and strategic use of open source.
It has recently strengthened its capability of open source compliance to deliver more reliable and secure services to customers by aligning its open source management system with OpenChain ISO/IEC 5230.
Internally, a dedicated team continuously reviews licenses, assesses risks and operates in-house training programmes to ensure developers use open source correctly. Additionally, S-core has implemented a structured system using open source management tools to proactively identify and mitigate potential risks throughout the development process.
Sunghan Suh, Head of the Open Source Business Division at S-core, stated, “Open source has already become fundamental components in software development and operation across all industries.” He added, “With the acquisition of the OpenChain certification, we will take the lead in the development of the open source ecosystem to enable companies and developers to use open source more safely and efficiently by sharing our extensive expertise accumulated from adoption, development, operation, management to technical support.”
S-core’s Future Efforts
S-core plans to obtain ISO/IEC 18974 certification to further enhance open source security management, reinforcing its ability to address open source vulnerabilities. Looking ahead, the company aims to commit to the growth and development of the open source ecosystem with continued innovation and progress.
The OpenChain Project will be delivering a major talk for the open source ecosystem at the LF Member Summit in March. This is a “lessons learned” talk to help everyone understand how to build and deliver open standards to the community.
Talk Abstract:
The OpenChain Project has built two open source process management standards (ISO/IEC 5230 and ISO/IEC 18974) and deployed them across the open source supply chain. While OpenChain was the first Linux Foundation project in 14 years to produce an ISO standard, it is far from the last.During the 2023~2024 period, we saw growing engagement around Joint Development Foundation and committee discussions around standards or specifications in other LF projects.
This talk will consolidate OpenChain’s lessons learned in creating, submitting and deploying open source standards. It will help projects at any stage in the development lifecycle of specifications, including those only just considering this option for long-term impact. It will also help people with a specific interest in a more trusted supply chain to get more involved in OpenChain, building on our existing work or participating in new potential standards.
Our optics will be on the legal, risk and compliance side due to the nature of the OpenChain Project’s mission for a more trusted supply chain, but the core material will be equally applicable to technical, code or other projects working on this topic.
Registration is required for this free event / kostenlose Veranstaltung, aber Registrierung ist erforderlich
OpenChain and The FOSS-LÄND Community Invite You To An Information Exchange
Want to get better at Open Source?
Open Source offers significant advantages for businesses, but effectively managing it with your developers, vendors, or within your software supply chain can be challenging. Whether you are new to the topic or a seasoned expert in open source management, we invite you to join us from April 7 to 9 in Stuttgart for a share and learn event. During this event, you will have the opportunity to:
Hear from industry peers as they share their open source processes and best practices.
Experience demonstrations from tool creators showcasing automated compliance solutions.
Participate in technical sessions focused on overcoming common challenges in the field.
Discover available support options from both the community and government resources.
OpenChain und The FOSS-LÄND Community laden zum Open Source Austausch ein
Wollen Sie die Open Source Reife Ihrer Organisation verbessern?
Open Source bietet allerhand Vorteile, aber ein effektives Open Source Management im Spannungsfeld zwischen Entwicklern, Zulieferern oder generell in der Software Lieferkette kann eine Herausforderung sein. Ob Sie nun neu in dem Thema sind oder schon langjährige Erfahrung haben, wir laden Sie vom 7. bis 9.April nach Stuttgart ein, um uns gegenseitig dazu auszutauschen und dazuzulernen. In unserem Event werden sich folgende Gelegenheiten bieten:
Einblick in Open Source Prozesse anderer Organisationen und deren Erfahrungsberichte
Überblick über frei verfügbare Open Source Automatisierungs-Tools zum korrekten Umgang mit Open Source inkl. Demonstrationen durch deren Entwickler
Ausblick auf mögliche Lösungsräume zu geläufigen Open Source Management Herausforderungen durch Teilnahme an technischen Austausch-Runden
Durchblick zu den vielfältigen Unterstützungs-Angeboten, die sich durch die Open Source Community im Allgemeinen und durch „The FOSS-LÄND“ für Baden-Württemberg im Besonderen ergeben.
Schedule and Locations / Ablauf und Veranstaltungsorte
Day 1 – 7th April 2025
13:00-19:00: Afternoon Meeting @ Venue 1
FORUM Haus der Architektinnen und Architekten (HdA) (See “Venue and Travel” below for details)
For participants attending the FSFE Legal Workshop in Essen from the 9th of April, we will end Day 2 of our event at 16:45 on the 8th of April. This will allow for easy train connections to Essen. Here is a link to the train connections from Venue 1 to Essen via Stuttgart Main Station.
Q&A
Who is the target audience of this event?
Software developers, security professionals and OSPO representatives
What the event location?
Day 1& 2 – Haus der Architekten in Stuttgart, Day 3 – Urban Harbor Ludwigsburg
No, this is a free event but you are required to register for a ticket
Is this a Linux Foundation event?
This is a community event co-hosted by the Linux Foundation’s OpenChain Project, and it will adhere to the Linux Foundation’s policies and code of conduct
Is the event language english? / Ist die Veranstaltungssprache englisch?
Yes, as we will have international participants, we plan to have english as event language, but for specific sessions we can also discuss to provide it in german (e.g. for people new to the topic) / Ja, wir haben internationale Teilnehmer, daher planen wir mit Englisch als Veranstaltungssprache. Aber wir können uns auch vorstellen bei entsprechendem Bedarf spezifische Themen (z.B. Themen für regionale Teilnehmer, die im Thema neu sind) auch in Deutsch / Schwäbisch 😉 zu machen.
Target group is also SME / KMU – is this acc. to KMU 2003/361 with < 250 employees?
Concerning the event we would welcome also bigger companies but want to explicitly support the small and medium businesses with the content. Only the concrete The FOSS-LÄND offerings (e.g. vouchers/Beratungsgutschein etc.) are explicitly for SME / KMU in the region, see details in german only: https://www.transformationswissen-bw.de/beratung/beratungsgutschein
CRA and NIS2 would be expected as topics & Will the new Software Product Liability Act be a topic?
We are currently collecting proposals from all sides (see question about content above with link to the topic backlog). The general questions about What and Why will be addressed in the opening presentation. You can also join the mailing list to pre-discuss the contents for the workshops/round-tables: https://groups.io/g/oss-based-compliance-tooling
Is this event limited to the automotive supply chain only?
Via OpenChain we are open to more interested parties along other supply chains but want to explicitly support the small and medium businesses in the automotive supply chain (The FOSS-LÄND target group) in the region with the content. If there is bigger interest we can think about a follow-up in an extended setup., please feedback on the mailing-list https://groups.io/g/oss-based-compliance-tooling
Is the Process Stream focussed on Software Development Processes?
While the process stream was originally meant for OSPO and Open Source Management Processes in the supply chain, the Software Development Process perspective may become relevant for the mapping of blueprints around tooling and the automated handling of non-functional requirements.
Will there also be a “Community Stream” e.g. how to collaborate in communities, how to get your OSS project big?
There will be two sections in the target groups: A) new to the topic/management and B) advanced/experts => for the second section such a “Community Stream” could be covered e.g. by TODO Group and Good Governance Initiative contributions. Contributions are welcome, see “content question” above with the link to the topic-backlog.
OpenChain is part of the fabric of quality open source process management. During the Automotive Grade Linux All Member Meeting in Tokyo, we will discuss how our ISO process standards – ISO/IEC 5230 and ISO/IEC 18974 – support technology management activities in Japan and beyond.
“Grab a beverage and food at the AGL Showcase then sit down and learn how AGL and the Linux Foundation can help you gear up your company’s OSPO. Join a special event that will be mostly conducted in Japanese for companies to learn more about OSPO activities within the AGL OSPO Expert Group. This will include presentations from OEM OSPO leaders at Toyota and Honda, OpenChain, and AGL leadership and much more. Afterwards, stick around and talk to AGL developers about what is happening on the project during the AGL Showcase.”
– 17:15-17:25 OSPO Introduction by HONDA – 17:25-17:35 OSPO Introduction by TOYOTA – 17:35-17:45 AGL Introduction by Dan Cauchy – 17:45-17:55 AGL OSPO-EG introduction – 17:55-18:05 break – 18:05-18:15 OpenChain Introduction – 18:15-18:25 OpenChain Japan Introduction – 18:25-18:35 Civil Infrastructure Project Introduction – 18:35-18:45 Discussion & QA
