Open source as the gateway to sovereignty

If there was one belief that tied together the closing remarks at the Dropsolid x Beltug event in Ghent, it was this: open source isn't just a licensing preference, it's the most realistic path Europe has toward genuine digital sovereignty.

Dominique De Cooman, CEO of the Dropsolid group, put it plainly in his closing remarks, open source is, in his view, the gateway to true sovereignty. It's also, quite literally, where his company's name comes from: Dropsolid was built on Drupal, the open-source content management system, and the company's platform is built on open-source components for exactly that reason.

The case for open source as strategy, not ideology

De Cooman's argument wasn't sentimental. It was practical: if the vendors underpinning your technology stack are themselves built on open foundations, an organization retains real options. You're not locked into a single company's roadmap, pricing decisions, or continued goodwill. Even smaller companies can build meaningful, defensible technology by building on and contributing back to open ecosystems, effectively punching above their weight class.

He also pointed to a frustration shared by several people in the room: European public money isn't yet flowing to open-source alternatives at anywhere near the scale it should be, given how much of a viable European tech stack is already available in open-source form today. He referenced ongoing conversations with European policymakers around mandating open-source use in public digitalization projects, conversations that, in his account, came under real pressure and ultimately produced a weaker outcome than initially expected.

His read was candid: real momentum toward open source at the public-funding level may need external pressure to materialize, but once it does, the opportunity for genuinely sovereign, open technology stacks becomes real.

Open source isn't free of complexity

But treating "open source" as a simple, low-risk default would be a mistake, and Roeland Delrue, co-founder of the cybersecurity company Aikido, used his time on the panel to explain why.

Aikido uses open source extensively, both defensively and strategically. Some of their own security tooling is deliberately open-sourced for transparency, so customers can see exactly what they're integrating into production systems, which matters a great deal when the software in question sits inside live, sensitive environments.

In other cases, Aikido has open-sourced a tool specifically to undercut a competitor charging heavily for something similar, a calculated business move rather than a purely philosophical one.

Delrue's caution was about the fine print. Open-source licenses vary enormously in what they actually permit, and getting this wrong carries real consequences. Permissive licenses (like MIT) allow essentially unrestricted use. Others, like certain LGPL variants, can carry obligations, for instance, requiring payment or disclosure once the software is used in a commercial product, even if it was free for private use.

Keeping track of every license across a software stack (something often referred to as a software bill of materials) becomes critical during events like M&A due diligence, when legal teams comb through exactly what open-source components a company relies on and under what terms.

When "open source" becomes a trap

Delrue shared a striking example of how license ambiguity can be weaponized. He described a company offering PDF-generation software under two nearly identical versions, one genuinely free to use, the other requiring payment once used commercially, deliberately positioned to cause confusion. That company reportedly used data from a popular document-sharing service to identify which businesses were using their tool, then pursued payment claims against companies (including major airlines) that had unknowingly used the paid-tier version under the belief it was the free one.

The takeaway wasn't "avoid open source." It was that if your organization writes and ships its own software, license management needs to be an active discipline, not an afterthought. If you're not writing software yourself, adopting open-source components is largely unavoidable and generally low-risk, but the calculus changes the moment your organization is building and distributing its own products.

The trade-off nobody mentions: who do you call at 3am?

Delrue was also clear-eyed about open source's real limitations. Community-maintained open-source software doesn't come with service-level agreements, guaranteed uptime, or a support contract you can escalate to when something breaks.

If your organization needs dedicated support and a clear point of accountability, commercial software, open-source-based or not, often still has a role to play. Open source isn't a wholesale replacement for commercial relationships; it's a component of a broader sovereignty strategy, not the entire strategy itself.

The takeaway

Open source's appeal as a sovereignty strategy isn't that it's automatically safer, cheaper, or simpler, several stories from the panel proved it can be neither. Its appeal is that it removes the single point of dependency that comes with proprietary, closed vendor relationships, and it gives organizations (and public institutions in particular) a realistic way to build technology stacks they can actually inspect, adapt, and own, rather than simply rent.

Getting there responsibly means treating open source with the same rigor as any other vendor relationship: understanding the license, tracking the dependency, and being honest about where community-maintained software needs a commercial backstop.

See it live

Book a demo