For most of the past decade, real-time video was a procurement decision: pick a vendor, sign a contract, ship. That framing no longer holds. Video infrastructure now underpins healthcare consultations, parliamentary proceedings, court hearings, and cross-border government collaboration. At that level of institutional dependence, the question of who controls the infrastructure and under which legal regime has become a sovereignty question, not a line item.
On 3 June 2026, the European Commission published its Communication on European Tech Sovereignty, with the EU open source strategy as a central pillar. Alongside it sit three further initiatives: the proposed Cloud and AI Development Act (CADA), the Chips Act 2.0, and the Strategic Roadmap for Digitalisation and AI in Energy. Together, they represent the most coherent EU attempt yet to answer the 'who controls the stack' question at the level of policy and law.
Two points are worth stating clearly before going further. First, the EU Open Source Strategy is a non-binding Communication. It sets direction but imposes no legal obligations on Member States or contracting authorities. Second, CADA is an early-stage legislative proposal with no current legal force; realistic adoption is late 2027 at the earliest, and Member States would then have a further implementation period before any binding procurement requirements kicked in. Neither document creates obligations today. This matters for procurement officers who might otherwise read them as already operative.
Open source features prominently in that answer, and rightly so. But this article argues that open source alone is not sufficient for sovereignty. For video infrastructure, sovereignty depends equally on where the system runs and who operates it.
Table of contents
The strategy is structured around four objectives: open source for tech sovereignty, what it calls 'a vibrant open source ecosystem', open source in public administration, and reinforced standards and international outreach. For organisations evaluating video infrastructure, three of the strategy's commitments carry the most direct weight.
The Commission also opened a call for evidence on open-source digital ecosystems in January 2026, feeding into the strategy's implementation. Organisations with operational experience in open source video infrastructure are well placed to shape how the procurement guidance is written.
The instinct that 'open source equals sovereign' is understandable. Open licences remove dependence on a single vendor's permission to read, modify, and run software. In that narrow sense, they reduce one category of dependency. But when buyers ask the open source vs sovereign question seriously, they find that the licence is only one of three layers that determine whether a deployment is genuinely sovereign.
The first layer is the code and licence: can you read, modify, and deploy the software without a single vendor's approval? An open licence answers yes. This is the layer most procurement conversations stop at, but it is not the only one that matters. For some buyers, particularly those needing full auditability of the server-side stack, the right to fork, or the ability to deploy in an air-gapped environment, it may in fact be the decisive layer. The FSFE's 'Public Code' principle (broadly, the argument that public institutions should only use software they can fully control and modify) has gained new visibility as the strategy's reception has amplified debate about user control. Their view is that free software gives public institutions a kind of control no managed service can replicate.
The second layer is where data is physically processed and stored. A system can be entirely open source but run on infrastructure governed by a non-EU legal regime. US-operated cloud infrastructure is subject to laws that can compel disclosure of data held on that infrastructure regardless of where the servers are physically located. The EU-US Data Privacy Framework, upheld at first instance by the EU General Court in September 2025 though an appeal is now pending before the Court of Justice, provides a transfer mechanism for GDPR-compliant data flows, but it does not remove CLOUD Act exposure for data stored on US-controlled infrastructure. An open licence on the software provides no insulation from that jurisdiction.
The third layer is the operational chain: who operates, supports, and patches the system; where are they incorporated; and who can be compelled, under which law, to hand over access or data? This is precisely what the CADA proposal addresses. CADA's four-level sovereignty assurance model sets Level 1 as a baseline floor, requiring that data is processed and stored within EU infrastructure. Levels 2 through 4 add progressively stricter requirements: independence from third-country legal regimes and supply chain transparency at Level 2, then EU ownership and control, and EU-based personnel at the higher levels. The licence-only approach typically fails at Levels 2 and above, since those levels are concerned with who controls the operational environment, not just the code.
A concrete illustration: an organisation running a self-hosted open source video platform on US-controlled hyperscaler infrastructure has cleared Layer 1 but failed Layers 2 and 3. A managed video service deployed on EU infrastructure, operated by an EU-incorporated entity under EU-governed contractual terms, satisfies Layers 2 and 3, even if proprietary components exist within the stack. The licence is not the sole sovereignty test; the operational chain matters too.
The strategy explicitly positions public administrations as anchor users and contributors to the open source ecosystem, embedding openness and sovereignty-by-design in digital investment decisions. New procurement guidance and open-source-friendly tendering will affect how video platform contracts are drafted, evaluated, and audited across EU public bodies, though binding obligations depend on the outcome of CADA and any implementing regulations.
For a buyer evaluating sovereign video infrastructure today, this creates a practical reason to look beyond the licence. A vendor can truthfully point to a public repository while running their service on infrastructure that would not pass a CADA Level 2 assessment (which requires demonstrated independence from third-country infrastructure). Procurement officers need to ask questions across all three layers.
In practice, that means requiring vendors to evidence the following before contract:
The formal checklist in the section below expands on each of these. The call for evidence on open-source digital ecosystems will shape the granular implementation of procurement guidance over the next 12 to 18 months. Buyers drafting tenders in 2027 should track outputs through the Commission's digital strategy page and the Interoperable Europe Portal.
The strategy's support for open source building blocks validates a model that has existed for some time: self-hosted platforms where an organisation deploys and operates video infrastructure on its own terms.
Two categories of self-hosted options are worth distinguishing. For organisations with dedicated infrastructure engineering capacity, building on open source components (WebRTC libraries, media servers) gives maximum control. For those that want a more complete off-the-shelf foundation, mature and actively maintained open-source video platforms such as Jitsi Meet and BigBlueButton are already widely deployed in European public sector contexts. When deployed on EU-located infrastructure under an EU-operated chain, either of these can satisfy all three sovereignty layers without any commercial dependency on a managed-service vendor. For buyers with genuine air-gap requirements, self-hosting is in any case the only option: a managed cloud service requires ongoing network connectivity to the vendor by definition and cannot meet that constraint.
Self-hosting does carry a full operational burden. Security patching, SFU (Selective Forwarding Unit) configuration, codec management, uptime, compliance evidence, GDPR audit trails: all of these fall to the operating team. The strategy provides no relief for that burden; it simply ensures the underlying components are available and sustainably maintained. Whether that burden is a barrier depends on the organisation's staffing and in-house infrastructure capability rather than being an absolute constraint.
A third path also exists: an embedded or API-programmable video service deployed on EU infrastructure, operated by an EU-incorporated entity under an EU-governed operational chain. This model satisfies Layers 2 and 3 while offloading engineering complexity to the vendor. To be clear about what 'embedded' means here: an SDK that integrates into an existing application can be fully API-programmable, so the integration model does not determine sovereignty status. What determines sovereignty is the hosting and operational chain behind it.
That said, a managed service trades the self-hosting operational burden for a different kind of dependency: not jurisdictional, but commercial and operational. If the vendor changes pricing, is acquired, or ceases to trade, the buyer's ability to maintain continuity depends entirely on contractual portability guarantees and practical migration paths. Buyers should require those guarantees in writing before contract, not simply note them as a checklist item. The portability question in the checklist below is the right place to make that demand explicit.
| Model | Control | Operational burden | Best fit for |
|---|---|---|---|
| Self-hosted open source | Maximum: you own and control the full stack | Very high: security patching, SFU configuration, scaling, uptime, compliance evidence all fall to your team | Organisations with dedicated infrastructure engineering capacity; requirements for deep customisation or air-gapped deployment |
| Managed EU service on EU infrastructure (EU-operated chain) | High: EU hosting, EU operational chain, no extra-EU legal exposure | Low: vendor manages operations, maintenance, and updates; your team integrates and configures | Teams requiring sovereignty guarantees without the engineering overhead; public sector buyers prioritising speed to deployment and predictable compliance posture |
Real-time video is harder to assess for sovereignty than a static SaaS application, because media routing, codec processing, and recording each touch data differently and raise their own sovereignty questions. The generic procurement principles in the strategy need translation into video-specific technical requirements.
Video deployments with sovereignty requirements have a specific technical dimension that generic guidance does not always capture. A media stream that passes through an SFU routing only encrypted packets has a very different data processing footprint (legally and architecturally) from one that is decoded, mixed, or analysed at the server. Recording pipelines raise further distinct questions: where is the recording stored, who holds the decryption keys, and under which legal regime are retention obligations enforced?
AI-based video features raise their own category of questions. Transcription, noise suppression, and real-time translation are commonly processed server-side, and sometimes via third-party model providers. Where that processing happens, and under whose infrastructure and legal regime, is a genuine sovereignty question that procurement specifications rarely address.
To make this concrete with a specific example: our infrastructure is EU-hosted, with sub-processors based in the EU and GDPR-adequate jurisdictions. The SFU routes encrypted streams without decoding or mixing them, which minimises the data processing surface and the associated legal exposure. The embedded SDK is released under a BSD-2-Clause licence, a permissive open licence that grants users the right to use, modify, and integrate without restriction. This provides the kind of no-lock-in code access the strategy promotes, without overstating the picture by labelling the full managed service as 'open source'.
The three-layer model translates into a concrete set of questions for any video procurement process. The following checklist is designed to be reusable in tender specifications and supplier assessment processes.
The EU open source strategy published in June 2026 is an important document for anyone procuring or building video infrastructure in Europe. It correctly identifies open source building blocks as a necessary ingredient of digital sovereignty, and backs that position with procurement guidance, funding mechanisms, and a long-term maintenance framework. The strategy is not yet binding law, and CADA is still a proposal working its way through Parliament and Council. But both documents signal clearly where EU procurement policy is heading.
Buyers who stop reading at the licence will mis-procure. Sovereignty for video infrastructure is the product of three layers working in combination: open building blocks, EU-hosted infrastructure, and an EU-operated chain that is not subject to extra-EU access regimes. The CADA proposal would make this three-layer test increasingly explicit in law, though CADA's specific assurance level requirements will evolve as it passes through Parliament and Council. Procurement processes that apply the three-layer test will be better positioned, and more defensible under audit, than those that treat a public repository as a sovereignty guarantee.
For more on how we approach data security, infrastructure transparency, and sub-processor accountability, download the Security Whitepaper.
If you want to understand how the integration works in practice and what the infrastructure looks like under the three-layer model, contact us and we will walk you through it directly.
The EU open source strategy is one of four pillars of the European Commission's June 2026 Tech Sovereignty Package, published alongside the Cloud and AI Development Act, Chips Act 2.0, and the Energy Digitalisation Roadmap. It places open source at the centre of EU technological sovereignty by promoting European open alternatives in critical technology domains, making public administrations anchor users and contributors, and establishing a long-term maintenance and sustainability framework for critical open source components. The strategy is a non-binding Communication; the binding procurement obligations the strategy anticipates depend on CADA and any implementing regulations that follow.
Not on its own. Open source software addresses one of three layers that determine sovereignty: the code and licence layer, which ensures you can read, modify, and run the software without a single vendor's permission. Sovereignty also requires that data is processed on infrastructure not subject to extra-EU legal access regimes, and that the entities in the operational chain, those operating, supporting, and patching the system, are incorporated and governed within the EU.
Open source is a licensing and development model that grants users the right to inspect, modify, and redistribute software. Digital sovereignty is a broader concept covering legal, operational, and infrastructural control over data and systems. Open source contributes to sovereignty by eliminating licence dependency, but it does not determine where data is processed, who operates the system, or which legal regime governs access to that data. Sovereignty requires all three layers to be addressed.
Self-hosted open source video can achieve full sovereignty if it is also deployed on EU-located infrastructure outside the reach of extra-EU access regimes. Platforms such as Jitsi Meet and BigBlueButton are actively maintained and widely used in European public sector deployments; when deployed correctly on EU infrastructure, they satisfy all three sovereignty layers. Self-hosting is also the only option for buyers with genuine air-gap requirements, since a managed cloud service requires network connectivity to the vendor by definition. However, self-hosting carries a significant operational burden: security patching, SFU management, uptime, scaling, and compliance evidence all fall to the operating team. A managed service deployed on EU infrastructure and operated by an EU-incorporated entity can achieve equivalent sovereignty guarantees for most buyers, with substantially lower operational overhead, provided the buyer verifies all three layers and secures contractual exit and portability provisions.
Buyers should request evidence across three layers: (1) which components are open source and under which licences; (2) where live media, metadata, and recordings are processed and stored, and whether that infrastructure is subject to any extra-EU legal access regime; and (3) who operates the service and where they are incorporated, which sub-processors are involved, and what portability and exit provisions are available. CADA's proposed sovereignty assurance levels (Levels 1 to 4) provide a useful reference framework for structuring these questions, though the final criteria may change before the regulation is adopted.
EU data sovereignty requires more than physical location alone. Data must be hosted on infrastructure that is not subject to extra-EU access laws. Physical EU location on a US-controlled platform does not satisfy this requirement if that platform is legally obligated to respond to non-EU access demands. True sovereignty requires EU-located, EU-operated infrastructure where the controlling entity is incorporated and governed within the EU, ensuring that legal access obligations are determined by EU law rather than a third-country regime.