Proposals

Eclipse Atesor is an agentic, state-driven system that takes a Git repository URL (only required input) and returns a verified RISC-V build together with a complete porting recipe. The architecture is a hierarchical planner / supervisor / executor graph implemented with LangGraph, in which roughly 70% of routine analysis is handled by deterministic, zero-LLM scripted operations and the remaining steps are delegated to specialised agents that operate strictly inside a sandboxed RISC-V container. These LLMs are fine-tuned very precisely to handle build-neutral package porting.

The system is composed of the following coordinated agents:
 

PLANNER
Derives a high-level TaskPlan from the repository's structure, build system, and detected architecture-specific code.
 

SCOUT
Produces a concrete BuildPlan (configure, compile, install, verify) tailored to the detected build system (CMake, Make/Autotools, Meson, Ninja, Go modules, Cargo).
 

BUILDER
Executes the plan inside the RISC-V sandbox, captures structured output, and records every command, exit code, and duration.

FIXER
When the Builder reports an error, classifies it (dependency, compilation, linking, architecture, configuration, missing tools, …), retrieves relevant few-shot examples, and proposes either shell remediations or source patches that are re-applied through a validated patch pipeline.

SUPERVISOR
Verifies agent outputs against known anti-patterns (hallucinated commands, unsafe operations), routes the next step, and escalates when the system detects a loop, repeated error category, or budget exhaustion.
 

SUMMURIZER
On success, writes a Markdown porting recipe and persists the build to a recipe cache so that future requests for the same package short-circuit the LLM pipeline entirely.

The project further includes a lightweight few-shot memory system. Curated examples for each agent role live in JSON files in the repository; successful porting runs can append novel patterns back into this store under file-lock-protected I/O. This delivers measurable accuracy improvements without requiring a vector database or any external infrastructure. 

A separate recipe cache records every package that has been successfully ported, keyed by package and sandbox profile, so that a project ported once can be re-built deterministically by anyone without re-invoking any LLM.

Every hospital, clinic, and lab runs on a patchwork of software systems that were never designed to talk to each other. A patient's record might live in one application, their lab results in another, their imaging in a third, and their billing in a fourth - each speaking a different digital language, often built decades apart. Getting these systems to share information reliably is one of the most persistent and expensive problems in healthcare, and it is the problem the Eclipse Open Integration Engine exists to solve.

Eclipse Open Integration Engine sits between healthcare systems and translates between them. When one system needs to send information to another, the engine receives the message, converts it into a format the receiving system understands, applies any rules the organization has defined, and delivers it. It does this thousands or millions of times a day in production environments around the world, quietly handling the flow of clinical and administrative data that keeps a healthcare organization running. Healthcare IT teams use it to connect electronic health records to laboratory systems, to route imaging orders, to feed data warehouses, to exchange information with public health registries, and to bridge older systems with modern, standards-based interfaces.

The project provides three things: the engine itself, an administrator application for designing and monitoring message flows, and the documentation needed to operate both. Implementers organize their work into channels, each representing a single integration between systems. A channel defines where messages come from, what should happen to them along the way (filtering, transformation, enrichment, routing), and where they should go. Channel logic is expressed in a combination of configuration and JavaScript, which gives integration teams enough flexibility to handle the unusual real-world cases that healthcare data is famous for, without forcing them to build and deploy custom applications.

Under the hood, Eclipse Open Integration Engine is a cross-platform integration engine (written in Java) that acts as an interpreter for healthcare systems, translating message standards into formats that target systems can process. The engine allows health IT teams to manage message pathways (channels) through filtering, transformation, extraction, and routing stages. It supports bidirectional conversion between standards like HL7, JSON, and XML. The project features a modular architecture with custom JavaScript-based scripting and connectors for protocols like HTTP/S, FTP, and direct database connectivity. It also includes a management administrator interface for channel development and operational monitoring.

AI coding agents are most useful when they can act autonomously: run commands, install packages, edit files, and iterate without asking for permission at every step. Granting that autonomy directly on a developer's host machine is risky: agents can damage system files, leak secrets, fall victim to prompt injection, or interfere with one another when running in parallel. Most organizations have no consistent way to constrain or audit what their agents actually do.

Eclipse Enclave addresses this gap by providing a sandboxed runtime in which agents operate inside isolated containers (and, in the future, microVMs or other isolation backends) with their own filesystem, process tree, and network stack. A sidecar gateway restricts outbound network traffic to allowlisted domains and records what each agent reached out to. Multiple agents work in parallel without interfering with each other by operating on separate Git worktrees of the same project. Auth, configuration, and history persist across restarts under user control. A control center surfaces the state of all running agents and provides a single place to start, stop, inspect, and review their work.

The same isolation, logging, and policy infrastructure that makes agentic development safer for individual developers also produces the evidence and controls needed by organizations to operate agents responsibly: per-session audit trails, network access logs, dependency provenance records, and policy enforcement points that map to requirements emerging from the EU AI Act and the EU Cyber Resilience Act.

Eclipse Enclave deliberately separates agent execution from agent identity. It treats agents as pluggable workloads behind a common runtime, configuration, and policy surface. This lets the community focus on isolation, observability, governance, and integration — and lets adopters mix and match agents and editors without rebuilding the surrounding infrastructure each time.

In summary, the Eclipse Particle Cloud Security (PCS) project provides vendor-neutral, open source technology for multi-provider storage protection, improving data sovereignty by ensuring no single provider can recover customer plaintext from its store alone, while supporting recovery and embedding in existing storage software and services.

Eclipse Bucky is a lightweight Java S3 client with no 3rd party dependencies. It is designed to be minimal and easy to use, providing a straightforward interface for interacting with Amazon S3 compatible services.
After much searching we could not find a Java S3 client that did not have a large number of dependencies. This client only uses the Java standard library.

Eclipse SSAM is a lightweight container execution framework optimized for automotive ECU environments in the context of Software-Defined Vehicles (SDV). It rapidly initializes container environments to begin application execution, and continuously verifies the integrity of container packages to detect tampering or unauthorized modifications in real time.

The framework provides the following core capabilities:

• Package Management — supports installation, removal, and upgrade of container packages
• Integrity Verification — ensures package integrity using Linux dm-verity and EROFS
• Container Execution — runs containers via an OCI-compatible container runtime (crun) using Systemd
• Resource Isolation — in addition to the resource isolation provided by OCI Runtime, enforces ext4 project quota on writable data partitions to limit disk usage per container-native application

Unlike conventional OCI-compliant solutions, Eclipse SSAM is purpose-built for resource-constrained, safety-critical systems where fast startup and tamper detection are essential. It selectively adopts OCI concepts while prioritizing performance and security over full specification compliance.

Eclipse SSAM operates on Linux-based host operating systems and relies on externally provided low-level runtimes, focusing solely on efficient container execution in constrained environments.

By open-sourcing SSAM under the Eclipse Foundation, we aim to foster cross-industry collaboration and contribute to a robust, scalable vehicle software ecosystem.

Eclipse KeySealer provides an open source KMS plugin for Kubernetes encryption at rest.

The initial implementation is based on k8s-kms-plugin, a gRPC service that implements the Kubernetes KMS v2 API and connects Kubernetes to a local or remote PKCS #11-capable key store. The plugin enables Kubernetes clusters to protect API data, such as Secrets, by using a key encryption key stored in an HSM, TPM-backed provider, software token, or external key manager exposed through PKCS #11.

Eclipse KeySealer is intended to provide a vendor-neutral home for Kubernetes KMS integrations with hardware-backed and externally managed keys. It helps Kubernetes operators use protected keys without depending on a single cloud provider, hardware vendor, or proprietary key-management integration.

The project is designed for production-oriented Kubernetes deployments where data-at-rest encryption, key isolation, key rotation, auditability, and interoperability with existing cryptographic infrastructure are important requirements.

Eclipse KeyPont is a collection of Go libraries for applications that need to use protected cryptographic keys, cryptographic tokens, and standard cryptographic protocols.

The project provides Go developers with reusable building blocks for integrating hardware security modules, PKCS #11 devices, key-management systems, and JOSE-based application protocols into Go software. The libraries are designed to be idiomatic for Go developers, to work with standard Go cryptography interfaces where appropriate, and to provide clear examples for common use cases such as signing, decryption, token-backed keys, JWT handling, and JOSE object processing.

Eclipse KeyPont provides a vendor-neutral home for these libraries under Eclipse Foundation governance. The project is intended to encourage broader collaboration among users, maintainers, device vendors, cloud providers, and application developers who need interoperable cryptographic integrations in Go.

The Eclipse Dataspace Hub is a community-driven enablement project that lowers the entry barrier for developers and organizations adopting dataspace technologies, such as the Eclipse Dataspace Components (EDC), the Connector Fabric Manager (CFM), or Data Plane implementations.

The project addresses key challenges facing dataspace newcomers: fragmented documentation, scattered repositories, and a lack of hands-on examples. It is structured around three complementary areas: (1) a comprehensive library of sample code and reusable templates provides reference implementations for common EDC extensions and integration examples with external systems; (2) fully functional end-to-end demonstrators illustrate realistic cross-organizational data sharing scenarios; (3) a centralized, community-maintained knowledge base consolidates core concepts, architectural patterns, and operational guidance in one accessible location.

What it is not: The project does not engage in core dataspace specification development or maintain production-grade code. It focuses exclusively on education, enablement, and demonstration. Any enhancements or bug fixes identified during sample development are contributed upstream to the appropriate repositories.

The project builds upon existing Eclipse dataspace technologies and aligns with prominent dataspace initiatives to foster interoperability across data ecosystems.

Eclipse Canon-C is a header-only semantic standard library for C99 targeting safety-critical embedded systems. It provides explicit ownership annotations, Result and Option types, arena allocation, fixed-capacity collections with caller-owned buffers, traceable contracts, and a coherent error-handling model — all designed for formal verification with Frama-C and certification under DO-178C, ISO 26262, IEC 62304, IEC 61508, EN 50128, and ECSS-E-ST-40C.

The library follows a strict dependency hierarchy: core/primitives → core → semantics → data → algo → util. Each layer is complete and independently usable. The core layers are freestanding-safe, with no RTOS, OS, or libc dependencies, allowing Eclipse Canon-C to run on bare metal, on Eclipse ThreadX, or alongside any other RTOS including FreeRTOS and Zephyr.

Eclipse Canon-C's continuous integration pipeline produces certification evidence as a normal part of every commit: 51 test binaries across GCC, Clang, and MSVC on three platforms; AddressSanitizer and UndefinedBehaviorSanitizer in every Debug build; Valgrind memory analysis; libFuzzer fuzzing; clang-tidy and Cppcheck static analysis; MISRA C:2012 advisory checks; and true Modified Condition/Decision Coverage measurement using GCC 14's -fcondition-coverage flag. The verification infrastructure is in place; ACSL annotations and Frama-C proofs are the next planned milestone.