OSS + ELC EU 2026

Modern SoCs have a variety of CPU cores on board - e.g. on ARM we often see Cortex A, plus Cortex M, plus System Controllers. The number of cores is as increasing as the demands. Concepts like 'Software Defined Vehicle' (SDV) from the automotive sector is just one example for such complex demands. One obvious requirement is to run other OS than Linux on dedicated cores. Which means that resources like memory, clocks, pin control, power domains, etc. may not be under the sole control of Linux anymore. They now need to be shared and synchronized between all the participants. How does this work in practice? How do technologies like remoteproc, rpmsg, mailboxes, hardware spinlocks, virtio, and devicetree come into play here? How is their status-quo? And what about the non-Linux sides? What is open, what is proprietary, and how does this affect actual solutions? This talk is the result of a journey trying to support LinuxZephyr based AMP using a complete FreeSoftware stack on a Renesas community board.

All active components require power. The device tree should properly describe these supplies so that the software can control power to the devices. On the other side of things, regulators also have their power inputs, and constraints on their power outputs. The device tree should also describe this. Nothing should be left to default.

This session will present how to fully describe the regulator tree of a system, how to identify missing bits, and how to properly describe regulator constraints.

AI agents are evolving from simple chatbots to coordinated systems that plan, collaborate, and execute real-world tasks. But moving from a working prototype to a production-grade multi-agent system is where most teams struggle.

In this session, two practitioners share battle-tested patterns from deploying agent swarms in industrial environments. We cover:
The architectural shift from single-agent to multi-agent: when and why you need a swarm
Comparing open source frameworks (LangChain, AutoGen, Strands Agents SDK) — strengths, trade-offs, and selection criteria
Practical orchestration patterns: task delegation, shared memory, tool coordination via MCP (Model Context Protocol)
Live demo: building a multi-agent system that collaborates to solve a real task
Safety-first design: guardrails, execution boundaries, and observability for production
Attendees will leave with a reusable architectural blueprint applicable to any open source agent framework.

The Zephyr USB host stack is still evolving and remains an experimental subsystem for many real-world applications. This session presents practical experience in enabling key USB host classes in Zephyr, including UVC (USB Video Class), CDC-ECM, and USB Hub support, along with a series of architectural improvements to the host stack.
The presentation highlights the challenges and lessons learned while bringing these features to Zephyr, including attach/detach handling, dynamic class matching for composite devices, device lifecycle management across class drivers, the core stack, and UHC drivers, dynamic configuration selection, and limitations in current APIs.
In addition, the session identifies gaps in the current USB host subsystem and outlines potential directions for future evolution. It aims to provide practical insights and guidance for developers working on USB host support in Zephyr.

Spot instances reduce cloud bills by up to 90%, but choosing which to use is a multi-dimensional puzzle where price, performance, interruption risk, and instance heterogeneity all interact. Kubernetes provisioners like Karpenter optimize a narrow slice of this problem, tightly coupled to a single cloud vendor, AWS.

KubePACS is an open source project that separates the decision from the execution. A vendor-neutral optimizer computes the best mix of instance types for a workload's cost-performance-availability profile, then translates that into native configuration for the user's provisioner

The talk goes deep into the system: the ILP-based selector for cost-performance-availability trade-offs, the GSS-driven optimizer that tunes them automatically, multi-node spot placement awareness for robust capacity across cloud providers, and clean integration with upstream Karpenter.

Attendees see measured gains over baseline configurations and take away an architecture pattern for performance-aware spot instance provisioning. We close with our intent to grow KubePACS as an open source community effort and welcome contributors to shape what comes next.

Autonomous VTOL aircraft require reliable, precision landing capabilities to enable real world applications from package delivery to infrastructure inspection. This session presents a complete open-source precision landing system built on ROS 2 and PX4, covering the full development lifecycle from high fidelity simulations to flight tested deployment.

We'll walk through how we developed, validated, and refined a multi-sensor perception and control stack that achieves centimeter-level landing accuracy using only commodity sensors and open-source tools. The system uses AprilTag fiducials for dock detection, fuses visible and infrared camera streams with a Kalman filter for robust pose estimation, and executes a phased descent state machine with real-time PID control.

The presentation covers:
Simulation first development: Building a Gazebo SITL environment with realistic sensor models
ROS 2 + PX4 integration: Bridging autopilot and perception via micro-XRCE-DDS,
Production deployment: Lessons learned scaling from lab prototype to field-tested hardware. Practical guidance on composing a production system from ROS packages, PX4 firmware, and community-contributed modules.

Modern Linux based distributed systems generally rely on bespoke "agent" services on each node for introspecting their state or issuing operations.

In this talk I'd like to explain systemd's vision of improving and cleaning up this logic, with the ultimate goal of avoiding any local agents but nonetheless making the system nicely introspectable and accessible, with modern technologies.

For this, we'll talk about the Varlink IPC system, and the numerous Varlink APIs systemd provides these days. We'll also cover the HTTP Varlink proxy, which opens up these APIs in a web-native way, with modern authorization mechanisms. We'll also discuss systemd's metrics collection/report generation subsystem, it's cryptographic properties and remote access to it.

libiio is an open source C library developed by Analog Devices for interfacing with Industrial I/O (IIO) devices - ADCs, DACs, IMUs, RF transceivers, temperature sensors, and more. It underpins a broad ecosystem of host-side tools including Scopy, pyadi-iio, and MATLAB, all of which connect to targets over network, serial, or USB transports.

This talk walks through the architecture and practical mechanics of the port. We will cover how libiio's external backend integrates with Zephyr's device model, allowing any driver that implements the IIO device driver API to appear as a first-class IIO device. We will look at built-in bridge drivers that wrap any Zephyr ADC, DAC, or sensor device into an IIO device. We will also cover how the module integrates into the Zephyr build system using Kconfig, device tree, and snippets to enable libiio with minimal changes to an application.

We will demonstrate a Zephyr board being queried from Scopy and pyadi-iio, and close with a look at what is in progress - trigger support for deterministic sampling and streaming, and a USB transport as a complement to the existing UART and network transports.

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.

This talk could prevent the next big data breach.

Building enterprise-ready AI poses challenges around data security, scalability, and integration, especially in compliance-regulated industries. We're already seeing security breaches with AI Agents in the news. This is a complex problem - Imagine having N users, M Agents and O actions. How do you design permissions around that?

This session will cover how modern permissions systems can ensure AI Agents have access only to authorized data. The talk will look at why the Google Zanzibar model of authorization which uses Relationship-Based Access Control (ReBAC) is well suited for fine-grained authorization at scale. The talk covers the nuts and bolts of how a Google Zanzibar system works under the hood, and how to apply it to AI Agents with techniques such as pre-filteration and post-filteration.

The talk will also include a live code demo implementing authorization for AI Agents + RAG using Open Source tools such as Weaviate, Langchain, and SpiceDB.

Linux was not developed around fault-containment properties expected of safety-certifiable software.

The linear map lets kernel code access memory across userspace ownership boundaries, so corruption can affect another process or container. Shared slab/page allocators and per-CPU caches compound this risk: corrupted state may remain latent and later affect unrelated subsystems. MMIO can cause external interference when a faulty driver accesses the wrong register or device because of corrupted state or an incorrect Device Tree or ACPI-derived base address.

Building on ELISA Linux Features WG (LFSCS) work, we use ks-nav call-tree artifacts to show that even narrow services depend on shared infrastructure across subsystems.

Reducing the configuration lowers function count but also usability; restoring functionality introduces transitive dependencies, so assessment cannot be limited to newly enabled code.

These findings challenge treating Linux as safe by default or relying on proven-in-use arguments alone. In a monolithic, shared-address-space kernel, fault containment and qualification scope must be demonstrated, not assumed.

Is it a multicopter? Is it a fixed-wing? Not quite: It is a quantum superposition of both, and only upon flipping the transition switch we can observe the VTOL state with certainty.

VTOL vehicles bridge the design space between either pure vehicle type and enable long, efficient flights combined with accurate and soft landings. However, they challenge our software engineering and architecture skills, and properly supporting all VTOL vehicles in PX4 is quite the balancing act.

In this talk, we will go over the architecture and implementation decisions that connect those two vehicle types within a running system. We will visit some VTOL specific features and see where they slot in, and finally we will conclude with possible paths for further improving VTOL support in PX4.