The EU Just Put Open Source at the Centre of European Tech Sovereignty. We Were Ready.

The Number That Should Stop Every European CIO

Recently, the European Commission published the European Technological Sovereignty Package. It includes the Chips Act 2.0, the Cloud and AI Development Act, a Strategic Roadmap for Digitalisation and AI in Energy, and for the first time in EU digital policy history a full EU Open Source Strategy.

The headline number in the factsheet: €264 billion spent annually on third-country products and services. That’s the figure that should make every European CIO and procurement officer stop and read the document carefully. Not €264 million. €264 billion. Per year. Flowing mostly to a handful of large proprietary cloud and software vendors, organisations whose terms of service, pricing, product roadmaps, and data access policies are set in boardrooms with no accountability to European institutions or citizens.

Commission President Ursula von der Leyen put it plainly: “We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure. This is about protecting our citizens, defending our interests and making our own choices.”

That’s not a technology policy statement. That’s a geopolitical one. And it arrives at a moment when the geopolitical pressure on European digital infrastructure is higher than at any point since the GDPR.

Open Source Is Not a Footnote Anymore

Previous EU digital strategy documents mentioned open source in passing. A bullet point here, a reference to the Free and Open Source Software (FOSS) ecosystem there. The Tech Sovereignty Package is different. The EU Open Source Strategy places open source at the centre of the EU’s technological sovereignty. The Cloud and AI Development Act reaffirms the Commission’s commitment to work towards an open, collaborative and resilient digital environment.

The Commission explicitly draws a line between vendor lock-in and strategic vulnerability, framing the concentration of EU digital infrastructure in the hands of a small number of dominant proprietary providers not merely as a competition concern, but as a strategic vulnerability. That’s a significant shift. For years, the argument for open source in public procurement was economic (lower Total Cost of Ownership) or ideological (digital commons). The Tech Sovereignty Package makes it strategic. Dependency on proprietary software from vendors you don’t control hinders digital sovereignty. That’s the Commission’s position, in a published policy document.

The factsheet also notes 3 million open source contributors in Europe delivering digital solutions. That’s the workforce. The strategy, the contributors, and the political will are all now aligned.

What “Sovereignty” Actually Requires

Here’s where I want to be precise, because “digital sovereignty” has become a label that every cloud vendor sticks on their Frankfurt data centre and calls it done.

Real sovereignty has four requirements. The Tech Sovereignty Package, to its credit, addresses all of them.

1. You need to be able to run the software yourself.
   A “sovereign cloud” where the code is proprietary and the vendor can terminate your licence, change the terms, or access your data at will, is not sovereign. It’s tenancy with marketing language. This applies regardless of where the vendor is headquartered. A proprietary lock-in with a Frankfurt data centre is still a lock-in. Open source with self-hosting capability is the baseline. The Cloud and AI Development Act introduces a sovereignty assessment framework precisely because the Commission understands this distinction.
2. You need to understand what’s in the software.
   Supply chain security is not a buzzword. It’s the question of whether you know what third-party code is running in your infrastructure, where it came from, and whether it’s been audited. SBOMs (Software Bill of Materials), signed builds, and vulnerability disclosure policies are the operational expression of sovereignty in software.
3. You need governance you can verify.
   A vendor that says “we’re committed to open source” without a published governance charter, without a community advisory board, without a defined process for how decisions get made, is making a marketing promise, not a structural commitment. The Open Source Strategy addresses this by calling for organisational and governance capabilities that sustain open source projects over time.
4. You need legal clarity.
   Open source licences are not all equal. The Apache 2.0 licence is permissive, procurement-safe, and compatible with the widest range of European enterprise and public sector requirements. AGPL is a copyleft licence, which means software that incorporates it can be required to be released under the same terms (often a blocker in proprietary public sector procurement). Understanding your licence stack is part of sovereign procurement hygiene.

What We Built Before the Policy Arrived

ownCloud was founded in 2010 in Germany. It’s been deployed in European schools, government agencies, research institutions, and public sector clouds for sixteen years. Millions of users rely on oCIS.

On May 5th, a month before this package was published, we launched the Kiteworks Open Source Program Office. Everything in our OSPO launch maps directly to what the Tech Sovereignty Package is now calling for at the policy level:

Apache 2.0 by default.
oCIS uses Apache 2.0 licensing. New repositories default to Apache 2.0. No copyleft risk in your procurement. No licence ambiguity used as a commercial lever. We put that in writing in our manifesto.

CLA retired, DCO adopted.
Contributors keep their copyright. This matters for sovereignty because it means no single vendor owns the entire codebase. The code belongs to the people who wrote it, licensed to the world under Apache 2.0.

Published governance charter.
Not aspirational language. A document with defined roles, decision-making processes, conflict resolution, a Community Advisory Board timeline, and a 30-day public comment period for any policy changes. It says explicitly that Kiteworks steers the roadmap, and it says explicitly what the community mechanisms to influence that direction are. That’s the structural commitment the Open Source Strategy is calling for.

SBOM, signed builds, VDP.
Supply chain security isn’t theoretical for us. We published a vulnerability disclosure policy, run a bug bounty programme on YesWeHack, generate SBOMs per release, sign our container images, and publish patch management records. Earlier this year we handled a supply chain compromise (CVE-2026-33634, Trivy) with a public incident report, notifications to affected customers in their language, and updated images within the exposure window. That’s sovereignty under pressure, not just in the marketing deck.

12 published documents.
Vision, mission, manifesto, governance charter, AI contribution policy, security disclosure policy, contribution guide, lessons learned, code of conduct, engagement, empowerment, product vision (read more on our OSPO page). Every commitment we make is in writing and publicly verifiable.

Why the OSPO Is the Right Structure

The Tech Sovereignty Package addresses open source at the policy level. OSPOs (Open Source Program Offices) are the organisational structure that makes policy operational inside companies and public institutions.

The Commission’s Open Source Strategy is Europe’s most significant step to date in using open source to achieve a sovereign and resilient digital future. But a strategy without implementation is a document. The Kiteworks OSPO exists to make the ownCloud implementation concrete: a published security policy, a defined contributor pathway, a community governance structure, and a commercial support model that makes the open source product financially sustainable without compromising its openness.

The four elements of our commercial model directly address what European public sector customers need to deploy open source responsibly:

1. Support and SLAs.
   The code is free. Someone answering at 2am when your Virtual Data Room goes down is not. The support tiers give public sector organisations the contractual response they need for critical infrastructure.
2. Hardened builds and SBOM.
   The auditor doesn’t care about the GitHub link. They need a signed SBOM, a patch management record, and a vendor attestation. We produce all three.
3. Compliance documentation.
   Public sector organisations in Germany and across the EU operate under these frameworks. Our Kiteworks subscription tiers include the compliance mapping, the audit support, and the dedicated compliance contact that make ownCloud auditable in regulated contexts.
4. Legal protection.
   Apache 2.0 is permissive. Our support subscriptions add IP indemnification for organisations that need a vendor to stand behind the licence.

The Number That Matters

€264 billion. Per year. Going to vendors whose roadmaps, pricing, and terms European organisations cannot meaningfully influence.

The Tech Sovereignty Package will not move that number overnight. Legislative processes take time. Procurement cycles are long. Institutional habits are sticky.

But the direction is set. The EU wants to build out Europe’s capacity in semiconductors, AI, cloud computing, and open source. The Open Source Strategy, the Cloud and AI Development Act’s sovereignty requirements, the public sector open source mandate: these are the structural conditions for open, governed, auditable alternatives to become the default.

The problem was never where the vendor is headquartered. It’s whether you can audit the code, fork it if needed, verify the supply chain, and run it on your own infrastructure under your own legal framework. Vendor lock-in fails all four tests. Open source, done right, passes all four.

ownCloud has been that alternative since 2010. The OSPO makes the governance and community commitments structural rather than verbal. And the Tech Sovereignty Package, published recently, confirms that what we’ve been building is exactly what European digital policy is now demanding.

The timing is not a coincidence. The problem has been visible for years. We’ve been working on an answer.

—

Read the EU Tech Sovereignty Factsheet: ec.europa.eu/commission/presscorner

ownCloud OSPO: kiteworks.com/opensource · owncloud.com/blogs

Try oCIS: github.com/owncloud/ocis · owncloud.dev

David Walter is VP of the Open Source Program Office at Kiteworks, where he leads open source governance, licensing, and community engagement for ownCloud. He’s been in the ownCloud ecosystem since 2014.