This recap covers the Open Community for Compliance track at Open Community Experience 2026 (OCX26), with sessions focused on the Cyber Resilience Act (CRA), SBOMs, open source governance, and what compliance actually requires from engineering teams.
Across three days at OCX26, the Open Community for Compliance track stayed grounded in one reality: compliance is no longer a legal discussion happening somewhere else. It is now shaping how software is designed, built, and maintained.
The focus of these sessions was on what teams are expected to deliver, how regulations translate into engineering work, and where organisations are still unprepared.
Key topics from the Compliance Track
A few patterns kept coming up across the sessions:
- Compliance is shifting from documentation to enforceable requirements with real consequences
- Developers are directly accountable for delivering parts of compliance, not just legal or security teams
- SBOMs provide visibility, but they do not solve compliance on their own
- Open source ecosystems introduce shared responsibility that is still not clearly understood
Alongside the main sessions, the track included hands-on workshops that focused on breaking down the Cyber Resilience Act into practical steps. The workshop “Are you ready for the CRA? Learn how the EU regulation will affect open source” led by Olle E. Johansson provided a structured walkthrough of the CRA scope, key obligations, and how open source projects, maintainers, and commercial actors fit into the regulatory framework. Participants worked through concrete questions around SBOMs, vulnerability handling, and the role of economic operators, with a clear focus on what teams can do today to prepare.
Day 1 at Open Community for Compliance: Highlights
FOSS, AI and compliance: Good match or not? with Lina Böcker
This session focused on the tension between AI systems and existing compliance frameworks. A core issue is that AI introduces new layers of uncertainty. Data provenance, licensing, and model behaviour are not always traceable in the same way as traditional software components. This creates gaps between what compliance frameworks expect and what teams can realistically prove.
The discussion made it clear that existing approaches are not enough. AI systems require new ways of tracking inputs, outputs, and responsibilities. You can see the recording on our OCX YouTube channel.
One key takeaway: AI systems expose gaps in current compliance models, especially around traceability and accountability.
Lessons from the CRA standardisation effort with August Bournique
The ongoing effort to translate the Cyber Resilience Act into concrete standards was highlighted and one point stood out immediately: “The regulator is a blunt instrument.”
August Bournique pointed out how broad legal requirements are being turned into technical expectations, often with ambiguity. This creates friction for teams trying to implement compliance without clear guidance.
It also highlighted that the standardisation process is still evolving, meaning organisations are working with incomplete information while deadlines remain fixed. You can see the recording on our OCX YouTube channel.
One key takeaway: CRA requirements are still being defined, but teams cannot wait for full clarity before acting.
Open source and standardisation: necessary but at times challenging collaboration towards compliance with Timo Perälä
This session explored the practical challenges of aligning open source ecosystems with formal standards. A key point captured the gap between expectations and reality: “Standardisation is always a compromise.”
Open source projects move quickly and rely on distributed contributions, while compliance frameworks expect consistency and traceability. Bringing these together introduces friction that cannot be fully removed.
The session emphasised collaboration as the only viable path forward, even if it slows things down. You can see the recording on our OCX YouTube channel.
One key takeaway: Standardisation introduces necessary structure, but it conflicts with how open source ecosystems naturally operate.
Day 2 at Open Community for Compliance: Highlights
CRA, NIS2, DORA: What senior Java engineers must deliver before 2027 with Markus Schlichting and Ixchel Ruiz
The impact of regulation becomes very concrete at the developer level. Both financial and operational consequences were highlighted, with the point that “legislation without threat are not take serious for the players on the market.”
Beyond fines, the risk goes further. Products can be removed from the market entirely if they do not comply.
Software is now treated more explicitly as a product that must be understood and documented. SBOMs were compared to ingredient lists, enabling traceability across systems. You can see the recording on our OCX YouTube channel.
One key takeaway: Developers are directly responsible for delivering compliance, and failure can remove products from the market.
Taming the SBOM chaos – A legal compass for the CRA and open source compliance with Hendrik Schöttle
A common misconception was addressed head-on: generating an SBOM is not enough.
Visibility is necessary, but it does not equal compliance. Organisations still need to fulfil licence obligations, manage dependencies, and ensure contractual alignment. The role of SBOMs sits within a broader legal and operational framework, not as a standalone solution. You can see the recording on our OCX YouTube channel.
One key takeaway: SBOMs provide visibility, but compliance requires additional legal and operational work.
Open source serves the servants too with Daniel Thompson-Yvetot
The focus here moved to enforcement and institutional readiness. The current situation was summarised bluntly: “We’re not ready and the governments are behind”, as Daniel Thompson-Yvetot pointed out.
Market surveillance authorities will be able to request documentation, investigate vulnerabilities, and restrict products.
There is a clear gap between regulatory and operational capability, both in organisations and in enforcement bodies. You can see the recording on our OCX YouTube channel.
One key takeaway: Enforcement may be uneven at first, but organisations still need to prepare for real scrutiny.
Day 3 at Open Community for Compliance: Highlights
Eclipse Apoapsis ORT server: An open source platform to automate CRA checks with Martin Nonnenmacher and Sebastian Schuberth
This session examined how the Eclipse Apoapsis ORT server extends the OSS Review Toolkit into a platform for automating compliance workflows end to end. The focus was on replacing fragmented, manual checks with a structured system that connects licence compliance, vulnerability management, and policy enforcement.
The platform introduces a shared interface that enables collaboration beyond engineering teams, bringing legal and compliance roles directly into the workflow. This reflects a shift towards organisation-wide responsibility for compliance rather than isolated ownership. You can see the recording on our OCX YouTube channel.
One key takeaway: compliance is becoming a continuous, automated process embedded into development workflows, rather than a static validation step before release.
Making open source best practices visible for quality driven regulated industries with Philipp Ahmann
Philipp Ahmann explored how open source development practices can be systematically mapped to the expectations of regulated industries, where quality and compliance must be demonstrated, not assumed.
The talk challenged the gap between documented processes and actual implementation. As stated during the session, “a process is worth nothing if nobody follows the process,” reinforcing the need to base compliance on observable, verifiable practices rather than intent.
The work presented focused on identifying existing practices across open source projects and making them visible, assessable, and reusable in regulated environments. This approach enables organisations to align with compliance expectations without introducing entirely new frameworks. You can see the recording on our OCX YouTube channel.
One key takeaway: the foundation for compliance already exists in open source practices, but it needs to be made explicit, measurable, and reusable.
CRACY: Open source tools to make CRA compliance easy with Ulrich Seldeslachts
Ulrich Seldeslachts introduced CRACY, a set of open source tools and methodologies designed to simplify CRA compliance, particularly for small and medium-sized organisations.
The session focused on translating regulatory requirements into practical tooling. The tooling covers key areas such as SBOM generation and validation, vulnerability tracking, dependency analysis, and compliance guidance. The emphasis on open, community-driven solutions addresses both cost and accessibility challenges, enabling broader adoption across the ecosystem. You can see the recording on our OCX YouTube channel.
One key takeaway: open source tooling is becoming a central mechanism for making compliance scalable, transparent, and accessible across organisations.
What this means in practice
Across the three days, a consistent pattern emerged. Compliance is no longer something teams can address at the end of a project.
It requires:
- Knowing what is inside your software
- Managing vulnerabilities continuously
- Maintaining documentation and traceability
- Aligning engineering, legal, and security practices
The shift is structural. Compliance is becoming part of how software is built, not something added afterwards.
Many of the practical questions raised during the track were addressed directly in these workshops, where teams worked through real compliance scenarios rather than abstract requirements.
If you missed one of the sessions from the Open Community for Tooling, you can now see them on our YouTube channel.
