OSS + ELC EU 2026

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.