OSS + ELC EU 2026

As the energy system transitions into a highly digital, data-driven ecosystem, grid operators face mounting complexity, rising costs, and increasing pressure to deliver scalable and future-proof solutions. In this context, open source is no longer a technical preference. It is becoming a strategic necessity.

In this session, Alliander shares how it has repositioned open source as a key enabler of its digital strategy. We show how a clear vision helps maximize public value, accelerate innovation, strengthen digital sovereignty, and improve transparency, while maintaining control over long-term costs.

We introduce three guiding principles: Open Source First, Building Together, and Confidence in Openness. We also highlight practical implications, from embedding open source in procurement to actively contributing and opening internal solutions.

This session offers a concrete example for executives on how to move from ad hoc use of open source to a coherent, organization-wide strategy. Reducing duplication, optimizing investments, and strengthening collaboration across the energy ecosystem, including within LF Energy.

It all started with the simple question: "Do we have all exceptions for license dependecies for all the projects?"

As you can imagine this is not a question most organizations can answer out of the blue.
To solve this we started not only generating SBOMS for every single project in the CNCF., but also every Subproject that has a release.
Along the way we hit every wall: inconsistent release processes, license resolution dead ends, CVE matching at scale, and the discovery that generation is maybe 20% of the problem.
We will dig into the full pipeline we built. Automated SBOM generation at scale, auto discovery of Repositories, experimenting with differnet SBOM generation tools, hitting Git limits, license enrichment via deps.dev and ClearlyDefined, vulnerability cross-referencing via OSV, and OpenVEX for suppression.
After we finished this we realized that 10,000+ SBOMs are useless if you cannot search, query, or govern them. So we built an open source toolchain for the whole thing.

You will learn how to build a toolchain for Supply Chain at a sclae that supports a foundation and you can also use in organizatiosn that is fully Open Source and Apache 2 licensed.

Starting up an OSPO is not an easy task - let alone for 300+ companies. That's the scale and problem space we face in the highly federated and distributed enterprise of E.ON.

One of Europe's biggest energy utility provider has it all: critical infrastructure, regulations, services for millions of customers, purpose built hardware, SaaS businesses, an unfathomable amount of suppliers and engineers all over the place.

So before we could even start with our own ideas about the OSPO management we needed to get a hold of the status quo at E.ON for any kind of engineering and business operations. Two years after starting the OSPO we're far from done doing that yet, but we already established quite a bunch of successful initiatives.

We'll present our idea of an Hub-and-Spoke-OSPO, targeted initiatives for distinct parts of the business, curing pain points, building recurring collaborations within the enterprise and how to become more visible as 2-person-OSPO with nearly 80.000 coworkers.

One year ago, we created the OpenChain Meridian 22 Work Group for Central and Eastern Europe. In this year, our community has grown to include members from Poland, Hungary, Finland, Romania, Bulgaria, Greece, and other countries. We promoted OpenChain and our WG formally at open source and security events in Serbia, Slovenia, and Bulgaria, and informally in other parts of Europe and the world. We work in close collaboration with other open source communities to organize free events across Europe.

This talk is a retrospective on this past year of expanding the OpenChain community in the region. We will showcase the interesting topics we focus on in our WG, and share the lessons we learned along the way. We would like to use the talk to promote the WG locally.

The first part of the talk will focus on the journey: how we launched the OpenChain Meridian 22 WG, our promotion activities, and the topics we have tackled so far.

The second second part, about the takeaways: what makes this region special, why we received attention mostly from security communities, and other such curiosities.

The last part will be an overview of the co-located event we are organizing with the community.

For decades, the Open Source Software world has run on a simple, elegant legal hack: standard open-source licenses (like GPL, BSD, or Apache 2.0) use copyright law to enforce openness and collaboration. But as the industry shifts to AI models are we are hitting a catastrophic legal wall? AI models and weights aren't code, they aren't traditional "data" either. Is the licensing regimes we have been reliant on for so long no longer an adequate solution for how to license AI Models and wights when we want to make them available and keep them as Open Source, and if so why do we keep on licensing them this way?

This panel hopes to brings together experts from various fields and industries to discuss some of the challenges and potential risks you may run into then using or sharing AI models and wights under Open Source licenses, and explore some high level ideas of what mechanisms could be used instead of "traditional" Open Source licenses to keep the openness and collaboration we all depend on to further innovation.

The EU CRA is now law, yet confusion persists across the software ecosystem. Many developers still fear personal liability for upstream contributions, while organizations struggle to understand what compliance actually requires.
This talk clarifies the four CRA compliance pathways: Self-Assessment, Standards, 3rd party Conformity Assessment, and the EUCC, and explains how they apply across the software supply chain.

We demystify the CRA’s approach to open source, focusing on OSS stewards such as foundations and legal entities, and their limited obligations compared to manufacturers. A key message: upstream contributors and individual maintainers have no direct CRA compliance responsibilities.
We also examine supply chain security implications, including the need for stronger upstream-downstream collaboration, better dependency transparency, and clearer security ownership at integration points. Misinterpretation of CRA roles risks shifting compliance burden incorrectly upstream, undermining ecosystem resilience.
Attendees will leave with a clear understanding of CRA responsibility boundaries, compliance routes, and the role of open source in a secure European software supply chain.

Open source supply chain decisions such as what to depend on, what to ship, and what to trust are only as good as the open data behind them.

The organizations working hardest to produce that open data are largely doing it in parallel. OpenSSF Scorecard scans 1.3 million packages a week. ClearlyDefined has scanned over 55 million and AboutCode over 20 million, both with ScanCode. We share the same problem: we're scanning and rescanning the same packages for the same (or similar) data.

That redundancy has real costs. Compute, maintainer time, and contributor energy spent on work that's already done is capacity not spent on expanding coverage, improving accuracy, or hardening infrastructure.

It's time to build together. This talk is a conversation about what it would look like to join forces on open software supply chain data, produced with open source tools and backed by open standards with shared infrastructure and aligned and unlocked datasets for wider usage. We'll explore where our data models overlap, where they diverge, and what collaboration would require, so we all can get sustainable, high-quality, and open supply chain data at ecosystem scale faster together.

Most organizations know they should manage open source strategically and efficiently. Few know how to actually do it when you're moving fast, resources are tight, and a supply chain incident can land on the front page.

Over the past several years, we've helped build and run Open Source Program Offices across multiple large German automotive and technology organizations. This session distills what actually worked - and what didn't.

We'll share concrete lessons on: getting buy-in from C-level to developer teams; surviving and learning from supply chain security incidents; scaling compliance without drowning engineers in process; using AI to cut OSPO workflow overhead; and growing open source contribution and compliance culture.

Along the way, we'll show how we used OSS Review Toolkit (ORT), a Linux Foundation project, as the automation backbone - and what we learned making it work in large, regulated industries.

You'll leave with a clearer picture of what it takes to scale open-sourcing and compliance in a regulated industry, and the mistakes worth skipping.