Open source is not sovereignty by itself — proof is the ability to maintain, switch, and exit
The 2026 Digital Decade report says 85% of Europeans support investment in EU-developed infrastructure and 82% favour reducing external dependency. The new European strategy places open source at the centre, while recognising the issue that decides the outcome: long-term maintenance and governance.
- Nature
- Velqory perspective grounded in European policy and supply-chain risk management
- Decision
- Procurement, architecture, security, finance, and continuity
- Published and verified
- 7 August 2026
- Boundary
- Open source is not treated as an automatic synonym for security, European origin, or autonomy
In brief
Available code increases choice, inspection, and adaptability, but it does not automatically transfer skills, build chains, operators, funding, data, or infrastructure. The Open Source Strategy is policy; the Cloud and AI Development Act remains a proposal. For leadership, sovereignty should become five tests: build, operate, maintain, port, and exit within a known boundary. Without that evidence, “European”, “open source”, and “sovereign” remain commercial attributes, not controls.
- The 85% and 82% figures come from the Special Eurobarometer cited by the Commission; they measure public support, not organisational technical maturity.
- The European strategy treats lifecycle, funding, maintenance, and governance as essential conditions for open source.
- CADA is a legislative proposal from 3 June, not an obligation already in application.
- Leadership should request an exit test with time, cost, functional loss, data, and owner — not merely repository access.
Policy has changed; technical dependency has not disappeared
The Commission defines technological sovereignty as Europe's ability to act with greater control over technologies, data, and infrastructure while reducing dependencies. The 3 June package includes Chips Act 2.0, the CADA proposal, the Open Source Strategy, and a digital roadmap for energy. They are instruments of different nature and maturity; treating them as one law already in force would be wrong.
The Open Source Strategy itself identifies limited funding, difficulty maintaining and scaling projects, fragmented visibility, procurement barriers, and dependence on dominant providers. The reuse report adds technical, legal, organisational, cultural, and strategic barriers. Code availability removes one barrier; it does not create an organisation capable of sustaining it.
Fact, policy, and proposal
- Package presented
The Commission publishes the strategy and presents related legislative proposals.
- Reuse in focus
Interoperable Europe highlights practical barriers to sharing and reuse.
- Leadership test
The company converts a sovereignty narrative into technical and contractual evidence.
Five proofs replace a sovereignty statement
NIST treats supply-chain risk across the lifecycle: acquisition, development, integration, operation, maintenance, and disposal. The same discipline works for sovereignty. The question is not only where a supplier is headquartered; it is who controls each dependency and what it costs to continue when one part fails or no longer serves.
Run the tests on a relevant service, not a data-free prototype. Record time, skills, formats, functional differences, and manual steps. If the alternative exists only on paper or requires the original provider to start, exit capacity has not been proven.
Verifiable sovereignty scorecard
| Proof | Question | Evidence | Failure |
|---|---|---|---|
| Build | Can we reproduce trusted artefacts? | Code, dependencies, pipeline, signing, and instructions | Only a third-party binary exists |
| Operate | Can we observe and administer without a critical black box? | Metrics, logs, interfaces, runbooks, and access | Operation depends on an exclusive account |
| Maintain | Who fixes and funds it for three years? | Maintainers, SLA, budget, fork, and succession | Community without owner or capacity |
| Port | Do data, identity, and configuration leave in usable form? | Export, import, reconciliation, and timing | A file exists but does not restore service |
| Exit | How much do we lose, and for how long? | Exercise, RTO/RPO, cost, degraded functions, and approval | Plan never executed |
A 30-day exercise that fits the leadership calendar
In week one, select a service and map dependencies through identity, data, observability, support, and infrastructure. In week two, reproduce the build and restore in a separate environment. In week three, export data and operate a critical function without the primary control plane. In week four, present loss, cost, time, and decisions.
The decision need not be immediate replacement. It may be to fund maintenance, obtain additional rights, create a second capability, accept a dependency for a defined period, or stop making a sovereignty claim that does not survive testing. The value is making dependency explicit and governable.
- Do not confuse an open licence with a reproducible build chain.
- Include people and funding in the technical map.
- Measure functional loss, not only data transfer.
- Repeat the exercise when architecture, contract, or maintainer changes.
Sources consulted
Consulted on the stated update date.
Opens in a new window.- 012026 State of the Digital Decade packageEuropean Commission · EU-DIGITAL
- 02Strengthening Europe’s Tech SovereigntyEuropean Commission · EU-DIGITAL
- 03Communication on European Tech Sovereignty and EU Open Source StrategyEuropean Commission · EU-DIGITAL
- 04The EU Open Source StrategyEuropean Commission · EU-DIGITAL
- 05Proposal for the Cloud and AI Development ActEuropean Commission · EU-DIGITAL
- 06Report on strategies to boost open source reuseInteroperable Europe · EU-INTEROP
- 07Cybersecurity Supply Chain Risk Management Practices for Systems and OrganizationsNIST · CY-NISTCSRC
Participate
Share the analysis. Add context.
Distribute the article through your channel or leave an observation connected to the topic.
Comments
Loading the conversation.