Schedule

What does the blackhole information paradox, one of the most famous puzzles in modern theoretical physics has to do with AI and copyright? Can the legal profession learn something from Hawking and Susskind's famous battle of intellect, and the race to unify general relativity and quantum mechanics.

When a book falls into a black hole, it is utterly destroyed, yet quantum physics dictates its underlying information must still exist somewhere, scrambled in the cosmic radiation. Can we apply some of these concepts to how copyrighted material is "consumed" by the digital blackhole when the AI is trained?

AI developers are using this cosmic loophole to defend algorithmic training.

They vacuum up millions of copyrighted works, crush them into abstract mathematical weights, delete the source files, and claim the copyright has "evaporated". The AI output is just akin to Hawking radiation. But when an AI suddenly regurgitates a copyrighted article verbatim or spits out a garbled stock-image watermark, does the truth becomes undeniable: the information was never destroyed. It was just hidden?

This talk will explain the increasing threat of Non-Practicing Entity (NPE / patent troll) approaches to companies over the use of open source technology, especially cloud technology, and it will reveal how companies across many industries are being approached by showing a detailed situation map. It will contextualize the issue based on how historical patent threats to open source were addressed, both from operating companies and NPEs. It will then explain how the current threat is being faced, progress so far, and what is needed in the mid-term to ensure damage to companies and communities is minimized. This talk will differ from previous discussions by providing the map of current challenges, and by going into detail only possible under Chatham House Rule. Attendees will come away understanding more about the urgency of our current community situation, and more clearly understanding the defenses available to projects and companies. The goal is to empower managers, legal teams and project teams to make good decisions if the need arises.

Open source is increasingly becoming critical digital infrastructure, but its sustainable adoption requires more than technology alone. In this keynote, Omar Mohsine, United Nations Open Source Coordinator, will share lessons from the United Nations’ journey to scale open source across a complex, global organization. Drawing on the development of the UN Open Source Principles, the UN Open Source Community of Practice, and initiatives to strengthen open source governance and capacity building, the keynote will explore how organizations can move from good intentions to practical, sustainable and compliant open source practices. It will highlight the importance of shared principles, clear responsibilities, automation, community collaboration and a culture of contribution, offering insights into how open compliance can become an enabler of innovation, trust and digital sovereignty.

SPDX 3.0 introduced the ability to track provenance of compliance information about data sets. The combination of software and data provides the fundamentals for AI BOMs. SPDX 3.1 continues to refine what is possible to track to license compliance, and enable regulatory policies like CRA to be supported. Examples of what is possible using SPDX 3.1 and Zephyr builds will be demonstrated.

This talk will provide an update on the new capabilities that have been included into SPDX 3.1, and review the capabilities already in SPDX 3.0 that can support the 2026 CISA SBOM minimum elements.

Generative AI and agentic development — "vibe coding," coding agents, and MCP-connected tools — are making AI-generated code an everyday reality in enterprises. It raises hard questions: open source pulled in unnoticed; no record of which model produced what; guardrails that ship off by default. License compliance, built for when humans wrote the code, now has to evolve — and the same tools can also help, like drafting SBOMs humans then verify.
OpenChain is the Linux Foundation community behind ISO/IEC 5230, the standard for open source license compliance. Its Japan Work Group is compiling a cross-industry catalog of these issues, targeted for July 2026. This session introduces the catalog and frames it around two questions every team now faces: how to manage the risk, and how to capture the benefit. Practitioners from a range of industries — manufacturing, internet, the public sector — react from their own experience, then open the floor to engineers, enterprises, and AI vendors.
Attendees leave with a concrete, field-sourced map of what's actually emerging — not theory — while builders of AI coding tools and the MCP ecosystem hear directly what enterprises need.

AI's explosive growth reshapes open source licensing, bringing severe challenges and new opportunities.

Core Challenges
Generative AI Risks: AI tools rewrite open source code, enabling Copyleft evasion ("license laundering"). A 68% conflict rate in AI codebases makes this a critical IP risk.

Unclear Rules: Traditional licenses rely on "human authorship." Pure AI works lack copyright protection, creating a "copyright vacuum" where standard terms fail.

Agentic AI: Autonomous systems modify and distribute software beyond the tracking limits of manual reviews and current SCA tools.
Opportunities

AI automates license identification, compatibility checks, and reporting. It predicts pre-launch risks to prevent IP disputes and summarizes complex rules, boosting legal and R&D efficiency.

This panel explores how the foundational principles of the open source movement such as collaboration, transparency, and community engagement can revolutionize management practices while embedding critical cybersecurity resilience. We will delve into how these values can be applied to projects, teams, and entire organizations to foster innovation, sustainable growth, and a robust security posture.

Featuring insights from experts Ayumi Watanabe, Mariya Kelsch, Takashi Ninjouji, and Marcel Kurzmann, and moderated by Nikola Babadzhanov, the session will move beyond theory. Using real-world examples, our panelists will discuss successful open source management strategies, examine governance guides, and highlight the importance of integrating a strong cybersecurity angle into every stage of open source adoption and management. The discussion will also address the dual challenges of scaling open source initiatives securely and managing the complexities of the software supply chain.

You will leave with actionable insights on enhancing collaboration, agility, and organizational resilience in a landscape where security and trust increasingly go hand in hand.

Safety standards such as ISO 26262 require far more than source code. Requirements, architecture descriptions, tests, safety analyses, verification results, and evidence of process compliance are essential artifacts for the development and assessment of safety-related systems. While these work products are well established in traditional development environments, their role and availability in open source projects are often less understood.

This presentation examines how safety-related artifacts are created and maintained in open source ecosystems, using Eclipse S-CORE and Zephyr as practical examples. It discusses which artifacts are needed, how they support compliance activities, and where challenges remain for transparent and collaborative safety development.

The session then introduces the SPDX Functional Safety Profile and shows how safety artifacts, evidence, and traceability information can be represented using a standardized, machine-readable format. Attendees will gain an overview of the profile structure, key relationships between artifacts, and how SPDX can support the exchange and management of functional safety information across organizations and supply chains.

Software engineering has undergone continuous evolution and iteration over decades. From the early waterfall development model, to collaborative development enabled by Git, then to DevOps, and now to the current era of intelligent development empowered by agent skills — security has always been an indispensable component throughout the entire journey.

With nearly 20 years of industry accumulation, Open Source China has built robust tooling capabilities for intelligent development and management solutions under the AI paradigm. Today, I am delighted to share our software factory development model and the governance framework for security solutions. At the core of the software factory architecture lies the Trusted Central Repository, with security capabilities natively integrated into its core design.

Open Source China is home to Gitee, the world's second-largest code hosting platform with 15 million developers. We boast China's largest productized DevSecOps solution, serving over 1,000 customers. We also operate MoArk, a platform hosting thousands of datasets and models, as well as the largest open-source technology forum community in China.

Managing open source compliance within a single organization is by no means an easy task. In particular, the recent exposure of security vulnerabilities due to source code disclosure and the combination of open source and AI technologies are making open source governance a very difficult challenge. Furthermore, the complexity is compounded by the need to establish common standards for many institutions in Korea that operate under the same government budget, each possessing its own unique legal teams, risk tolerance, and IT maturity levels.
This presentation introduces the process by which Korean government-funded research institutes spanning diverse fields moved beyond fragmented open source practices to become the "GRI Open Source Council (a non-profit corporation)." This single governance body was established to coordinate open source compliance, strategy, and community activities at the national level. It also examines specific governance design strategies to ensure that this organization—organized as a free community of eight government-funded institutes, including ETRI, rather than being government-led—can produce tangible results rather than remaining a mere symbolic body.

Universities are hubs of innovation and have played significant roles in many industries and in open source. Yet, despite the large footprint universities have within the open source community, knowledge about open source licensing remains uneven in academia. Academic OSPOS can help bridge this gap through outreach, training and open source SBOM tools. While these are fairly standard strategies employed by corporate OSPOs, these strategies must be adapted for academic communities, which are comprised of students, staff, researchers and faculty who may not share the same goals or technical abilities. This session focuses on the challenges and needed adaptations. It also highlights an area for improvement: creation of user friendly SBOM tools.

By focusing on licensing outreach, universities can produce:
(i) software that is compliant with applicable open source terms, easing potential downstream supply issues; and
(ii) individuals who can resolve license conflicts and intentionally select an appropriate license for their work.

In turn, this benefits industries that rely on work created at universities, and that hope to hire developers versed in open source matters.

Your scanner says MIT. Legal approves the ticket. But the package may call a commercial AI API, bundle a proprietary SDK, or depend on a non-FOSS container image. These obligations often sit outside LICENSE files and remain invisible to traditional compliance workflows. As open source increasingly relies on external commercial services, integration-driven obligations have become a major blind spot in enterprise FOSS compliance.
In this talk, we introduce Context-Aware, a system that detects commercial APIs, proprietary SDKs, AI/ML services, non-FOSS container images, and other integrations starting from a package or PURL. Findings are stored in a graph model for impact analysis, tracking, and compliance investigations.
We will share lessons learned from operating the system, including real-world examples of unexpected commercial dependencies in widely used projects, discuss detection techniques that worked, and approaches we abandoned due to excessive noise.
Attendees will leave with a practical framework for uncovering compliance blind spots and identifying integration-driven obligations before they reach production.

Software compliance – whether for licensing or security – depends on accurate data about millions of open source components. Many organizations try to solve the same problems independently, scanning the same packages repeatedly and creating isolated knowledge bases that can't be shared or verified. This redundancy wastes resources and leads to inconsistent – and sometimes inaccurate – compliance outcomes across the industry.

A better approach is open data for compliance and software supply chain security. Just as open source thrives on shared code, compliance can benefit from verified information about software origins, licenses, and vulnerabilities. AboutCode and ClearlyDefined are pioneering this model by creating community-curated datasets of transparent, verifiable compliance data that anyone can access and improve for digital sovereignty.

This talk will explain why open data is essential for scalable and accurate compliance workflows. We’ll demonstrate how to leverage this data in your compliance practices to enhance automation for compliance and software supply chain management.

When compliance data is shared like public infrastructure, we all comply better, together.

After helping a local company establish an OpenChain ISO/IEC 5230 conformant program, OCF began asking how the same principles could support public-sector teams with different constraints.

This lightning talk shares how OCF used ISO/IEC 5230 and 18974 not as standards to impose wholesale, but as a vocabulary for roles, processes, and expectations. The work remains incomplete; our contribution is the translation and persuasion process, and the lessons it offers other Asian public-sector ecosystems.

At the central-government level, Taiwan's Ministry of Digital Affairs approached open source through Public Money, Public Code and the Standard for Public Code. OCF translated OpenChain's license-compliance and security-assurance principles into guidance that public servants, procurement teams, and vendors could discuss. Other agencies are exploring whether shared procurement requirements could create broader change.

Local governments followed different paths. Taipei added hackathons and community-response requirements to selected procurements, while Tainan's disaster-prevention and smart-city projects gained momentum through sustained engagement with local communities.

OpenChain demonstrates that enterprise adoption of an open standard requires more than a specification. As the Model Context Protocol (MCP) emerges as a key standard for agentic AI, similar questions are beginning to surface:

• How can organizations show that implementations conform to the standard?
• What role does conformance play in governance, procurement, interoperability, and trust?

This session explores the parallels between OpenChain and MCP, sharing early insights into how community-driven conformance could become a foundational layer for trustworthy AI infrastructure, while highlighting how OSPOs could bridge legal, security, and engineering teams as these standards mature

We're retrofitting existing solutions onto a new development methodology. It's not working.

LLMs are a paradigm shift: fundamental assumptions about software development and rights in code are not working. Even defining "software" is now a challenge.

The legal and technical tools we have are patching existing modalities in a way that satisfies no one.

Andrew Katz explores some of the fundamental questions: what is source code in the age of vibe coding? How can a constantly shifting code base comply with regulation (like the Cyber Resilience Act) which demands a fixed, deterministic SBOM per release? How can the subtle requirements of a copyleft licence be respected when the code is used in training data for an LLM which subsequently generates an output based on that code?

Andrew will present a potential solution, based on solid research, and shows how it can be engineered to to meet the needs of the open source community, software development business, and individual developers.

It may even reveal a possible pathway to solve one of the most intractable and persistent FOSS issues: how to remunerate the developers.

But what does this solution mean for copyright itself?

Scanning source code for license compliance and copyright extraction is
currently the slowest step in most compliance pipelines. ScanCode
Toolkit is the scanner of choice for many organisations and although
it's thorough it can take long enough that scanning ends up in a nightly
batch job rather than in CI, where it should run ideally for quick
feedback to developers and compliance managers.

Hayaku (速く, "fast") is a lightweight pre-scanner that makes a different
set of trade-offs than existing scanners. It reuses ScanCode's vast
license detection rule set but drops a few features such as partial
matching, which is the most expensive operation in ScanCode, but
compensates by tightening existing rules and adding new ones. Rules are
converted to run on YARA, the industry standard for malware detection at
scale. Fact extraction is decoupled from interpretation, which makes
results cacheable across runs and projects. In our tests we have seen
speedups of up to 70x, in a bit over 1,400 lines of Python code,
including documentation.

Hayaku isn't a ScanCode replacement. Rules are broadly interchangeable,
and the efficient division of labour is to pre-scan with Hayaku on every
commit and run ScanCode periodically to fill in the blanks that Hayaku
missed.

The talk covers the design trade-offs and what they cost, the result
format, where Hayaku is currently the wrong tool, and how to try it.

Software supply chains demand a holistic approach to maturity, integrating security, license compliance, and quality management. But how do standards like OpenChain ISO/IEC 5230 and ISO/IEC 18974 fit within a broader enterprise framework like ISO 9001? Navigating this landscape is a key challenge for every organization.

In this session, Marcel Kurzmann (OpenChain Board Member) and Nikola Babadzhanov (OpenChain Ambassador) share a practical blueprint from the Bosch OSPO. They reveal how a global technology leader leverages its foundational Quality Management System to systematically address open source compliance and security.

We will guide you through several different aspects of the supply chain maturity – the standards landscape, automation at scale and the OSPO's strategic role in preparation for regulations like the EU CRA.

This talk provides a clear map for integrating open source governance into your existing quality processes, ensuring a transparent, secure, and compliant supply chain.

This panel brings together end users, integrators, data providers, and developers to share hands-on experience of using open source health indicators for effective supply chain management.

Maintenance, sustainability, and collaboration dynamics are increasingly used as early indicators and predictors of supply chain issues. Unmaintained repositories are an obvious red flag, but many “grey areas” offer crucial intelligence. The XZ Utils case is a flagship example: networks of trust, human activity patterns, and unexpected changes in code capabilities were key to early threat detection.

This panel shares that lens with the OpenChain community, building on the Capability Maturity Model (where these signals are already referenced) and talks at Open Compliance Summit 2025 on adding new security layers to close gaps in the existing supply chain.

We’ll ground the discussion in real-world examples, and share how to grow a high-quality dataset from scratch, why open sourcing the datasets matters as a foundation for future work, and how to build them in a community-driven way, with ecosystem collaborations like OpenChain central to that success.

License scanners work well when source files contain standard license headers. However, code reuse does not always respect file boundaries. Copied code may lose its license info, a comment may mention GPL only to prohibit its use, and a proprietary notice may not match a known license. An LLM alone is not sufficient, because it may produce confident but unsupported compliance conclusions.

We present an agentic workflow for open source license compliance. The workflow combines existing scanner results with provenance analysis, retrieves license text to interpret variants and exceptions, and reconciles source, repo and package data, Git history, and upstream projects. Rather than returning a license label, the agent creates a case file with the relevant source lines, possible code origin, candidate license expression, uncertainty, potential impact, and recommended next action.

High-confidence, low-impact findings can be saved automatically. Custom licenses, copyleft, conflicts, and other issues are escalated to a human regardless of model confidence. We show how AI can perform the most repetitive work while humans retain control over legally and operationally significant decisions.

LG Electronics open sourced FOSSLight in 2021 to share the tools and practices it had developed through years of open source governance. Through continued development, FOSSLight has grown beyond scanning and compliance checks into a broader ecosystem that supports the ongoing management of open source.
This session shows how FOSSLight brings the different parts of this work together into a continuous open source governance workflow. It will explain how its components work together, moving from initial analysis to review, SBOM exchange, vulnerability follow-up, and automation.

This session will present Baseline-information Obligations Mapping (BOM) ontology that will help practitioners map SBOM minimum elements (or baseline attributes) to metadata standards in a more consistent and more machine-readable way.

We propose a bridge ontology that is designed to be used as a "mapping justification" with the Simple Standard for Sharing Ontological Mappings (SSSOM). A SSSOM mapping is a statement that there is a correspondence between two semantic entities. It comprises two components:

1. the core mapping (subject, predicate, object; for example, g7ai:sbom-author, skos:broadMatch, spdx3:createdBy or ntia:author, skos:broadMatch, cdx:authors)

1. the supplementary information about the core mapping (for example, map author, mapping confidence, and its justification). The BOM ontology provides SBOM minimum elements vocabulary that can be used with the justification, so we can know that both of the mappings in (1) above are based on the bom:doc-author concept for “Document Author” in SBOM minimum elements.

We will demonstrate how this can reduce SBOM mapping time while offer more consistent mapping.

In global supply chain security, process failure frequently stems from human error induced by cognitive overload. While automated scanners and SBOM tools exist to ensure compliance, the ultimate integrity of open technology management relies entirely on practitioner execution. When compliance interfaces and tooling workflows are overly complex, developers bypass protocols or misconfigure security policies, creating unintended process vulnerabilities.

Drawing on practical experience as an open-source maintainer at the AsyncAPI Initiative, this session analyzes how optimizing the ergonomics of compliance processes reduces systemic friction. We present an actionable framework for:

1. Identifying hidden cognitive bottlenecks in policy enforcement workflows that trigger practitioner resistance.
2. Standardizing interaction heuristics across automated compliance tools to lower entry barriers.
3. Structuring compliance pipelines to incentivize developer adherence rather than friction.

This session provides compliance officers and process managers with evidence-based strategies to secure the human element in open supply chains.

AI is becoming important in compliance work, but it is not always clear where and how to use it. Compliance rules are often spread across guidelines, checklists, procedures, and documents. In this session, we first list each requirement, the evidence needed to check it, what sources are available, what is missing, and who should make the final decision.

We consider how AI can help extract requirements, find related documents or records, and suggest evidence mappings and gaps. Human reviewers then confirm the meaning of the rule and evidence, and decide whether the requirement can be checked automatically, needs more evidence, or still requires human judgment.

The two speakers have worked on OSS license compliance and Sustainable AI, including Green Software. We use examples from both areas. For OSS license compliance, we look at obligations, usage conditions, and approval records. For Sustainable AI, we look at energy use, carbon emissions, and related information. By comparing these two areas, we try to find common points about where AI can help and where human judgment is still needed. We also look for a general way to use AI in compliance reviews that may apply to other areas.

Whether an SBOM arrives with usable license and copyright data depends on the generator and the ecosystem, but enough entries come back without a concluded license or a copyright notice that filling them in by hand remains a real part of the audit effort.
To narrow that gap I built and open-sourced a tool, which has run in production for over 18 months across more than 30,000 entries.
The purpose of the talk is to show that a language model can genuinely help fill those gaps, and to be precise about where. Drawing on that experience, it looks at which parts of license identification the model handles well, which are better left to deterministic rules, and why the split fell further towards rules than I expected. It also covers why each determination has to carry its evidence and reasoning, and what that requirement rules out.

Starting September 2026, the EU Cyber Resilience Act requires digital product manufacturers to detect, triage, and report actively exploited vulnerabilities within 24 hours. Manual triage can't keep pace across deep, distributed dependency trees.

This session presents a working automation setup using OpenSearch and Ansible. Every build produces a live SBOM in CycloneDX format, streamed into OpenSearch and enriched against CISA's KEV catalog and EPSS scores.
OpenSearch Dashboards then shows what's actually being exploited, not just a generic CVSS score.

The second half covers what happens when a detection rule flags a compromised component. The system checks exposure and confidence, then either triggers a scoped Ansible playbook to isolate it, or routes it to an engineer. Every action is logged, becoming the draft of the report the regulator requires.

Attendees will leave with:

1. A reference architecture diagram and source code on GitHub
2. Ansible roles for SBOM generation, KEV/EPSS enrichment, and remediation
3. A working example turning logs into a compliance report draft
4. An honest look at where automation is safe, and where judgment matters

Vulnerability data is broken in the same way software supply chains were a decade ago: fragmented, duplicative, and not trustworthy. The EU Cyber Resilience Act (CRA) makes that a legal problem, not just a technical one, requiring organizations to track, report, and respond to vulnerabilities across their software supply chain.

The open source community is addressing this head-on with three interlocking efforts:

1. Data: vulnerability information as a shared, curated and verified commons, deduplicated and traceable to source. Teams can stop re-triaging the same advisory, and correct data produces the audit trail the CRA demands.

1. Standards: open, ecosystem-agnostic identifiers (PURL, VERS, and a new identifier for security advisories) so any tool or organization can refer to the same vulnerability the same way, closing a gap that complicates CRA reporting across fragmented toolchains.

1. Tools: practical open source software turns CRA and other regulatory compliance obligations into an automatable pipeline anyone can adopt.

The result is a new foundation for software supply chain security, built on data you can trust, standards you can share, and tools you can run.

An SBOM identifies components, but it does not by itself show whether a vulnerability affects a product release, what action was taken, or whether the decision can be reconstructed. This session presents a practical evidence chain from SBOM validation through vulnerability correlation, product-specific applicability and impact assessment, remediation decisions, VEX statements or security advisories where appropriate, and retention of supporting rationale.

It examines common failures: incomplete SBOMs, scanner matches treated as conclusions, unclear ownership, weak links between assessments and product versions, and decisions that cannot be reproduced. Building on established open source governance and security assurance practices, including ISO/IEC 5230 and ISO/IEC 18974, the session shows how these practices can support product-level vulnerability handling, traceability, and evidence management for CRA readiness.

We file digest pinning under reproducibility and build performance, somewhere near the bottom of a best practices page nobody reads. I think it is an evidentiary control and it belongs in policy.

Here is the argument, and it takes about two minutes. The big compromises this year did not exploit anything. They swapped the artifact sitting behind a name that had already been reviewed and approved. A tag is a mutable pointer. If your approval is recorded against a mutable pointer then you have not approved a component, you have approved a label somebody else can redefine later. That will not read as an approval to an auditor, and it should not.

The rest of the time: what actually changes when pinning becomes a requirement rather than a suggestion, what it costs in practice, the places it genuinely breaks, and the two spots where every team I have looked at forgets to apply it.