Open Source and Digital Sovereignty: Where Control Really Comes From

The European Commission placed open source at the centre of its technology sovereignty agenda in June 2026. For companies trying to reduce dependence on a small number of technology suppliers, the appeal is clear. Source code can be inspected, adapted and, under the terms of its licence, operated by someone other than the original developer.

That creates options. It does not, on its own, answer who runs the service, which law applies, who fixes vulnerabilities or whether another team could take over during a crisis.

This distinction matters for mid-sized European companies evaluating cloud and software choices. Open source can strengthen control, but only when the commercial, operational and technical arrangements make that control usable. The useful procurement question is therefore not simply whether a product is open source. It is whether the organisation can keep using, securing and moving the system when circumstances change.

Why the EU is focusing on the full lifecycle

The EU Open Source Strategy, adopted on 3 June 2026, treats open source as part of Europe's infrastructure rather than a collection of free software projects. It covers cloud and edge computing, artificial intelligence, cybersecurity, operating systems and software development infrastructure. The stated goals include greater choice, less lock-in and more control over critical digital building blocks.

The important part of the strategy is its focus on the full lifecycle. The Commission proposes support for development, adoption, governance, security and long-term maintenance. It also plans dependency analysis, an assessment framework and an Open Source Maintenance Instrument for important components.

Those measures acknowledge the central weakness in a simplistic "open equals sovereign" argument. Publishing code solves the access question. It does not fund security work, create documentation, establish accountable governance or guarantee that a project will still be maintained in five years.

A related Commission report on sharing and reusing open-source software reaches a similar conclusion. Even mature software can be difficult to adopt when documentation is weak, technical environments differ, licences are poorly understood or nobody owns long-term maintenance. The report concerns public administrations, but the obstacles will be familiar to any company with a lean technology team.

What access to source code actually gives you

Open source gives a buyer several practical advantages. Engineers can inspect how a system works instead of relying entirely on a supplier's description. The organisation can ask an independent specialist to review it, adapt it to local needs and check how data enters and leaves the system.

It can also make continuity easier. If one company stops supporting a widely used project, another company or the user community may continue it. A customer may be able to change support partners without replacing the underlying software, which separates the technology decision from a single commercial relationship.

Open standards and portable formats can extend that advantage. The EU Data Act's cloud-switching rules require providers of platform and software services to make open interfaces available and, at minimum, export customer data in a commonly used, machine-readable format. Open-source products often fit well with that direction because their data models and interfaces can be examined rather than inferred from a vendor's documentation.

These are real gains. They improve the possibility of an exit, but possibility and readiness are different things. A repository that nobody on your team can build, deploy or secure offers less practical control than its licence suggests.

Where control can still break down

The first gap is hosting. An open-source application running as a managed service on infrastructure controlled by a non-EU company remains subject to that operator's contracts, administrators and legal environment. The application licence does not decide where the data sits, who can access backups or which authority can issue a binding order to the operator.

Running the same application with a European cloud company changes part of that picture, but still requires scrutiny. Buyers need to understand the provider's ownership, subcontractors, support locations, encryption-key arrangements and upstream infrastructure. The European Commission's Cloud Sovereignty Framework assesses legal, operational, supply-chain and technological control separately because no single label answers all four.

The second gap is governance. An open-source project may be controlled by a foundation, a single company or a small group of maintainers. The code can remain available while the roadmap, release process and security decisions still depend heavily on one organisation. A licence may permit a fork, but taking over a complex project requires engineers, build systems, testing infrastructure and knowledge of its dependencies.

The third gap is maintenance. Visible code can be audited, yet visibility does not ensure that anyone is reviewing it or preparing fixes. This is why the EU strategy includes maintenance funding and dependency mapping rather than relying on publication alone.

Responsibility also changes with the delivery model. Under the Cyber Resilience Act's approach to open source, unpaid contributors, organisations that sustain projects and companies that put software on the market do not carry identical obligations. A buyer should know which party monitors vulnerabilities, issues supported releases and handles incident reporting. "The community will fix it" is not an operating model.

The final gap is internal capacity. Self-hosting can give a company more direct control, but it also transfers operational work to its own team. A three-person infrastructure group may gain legal and technical independence while losing resilience if it cannot provide updates, backups, monitoring and round-the-clock incident response.

What buyers should settle before procurement

A useful assessment should follow the service from code to day-to-day operation. The answers belong in the architecture record, contract and continuity plan, not only in the product comparison.

• Governance: Who controls releases and security decisions? Check whether the project has several active maintainers, a clear decision process and a credible route for another organisation to continue it.

• Accountability: Which legal entity provides the service and accepts responsibility for availability, security fixes and support? Open-source status should not blur the name of the party that answers when production is unavailable.

• Operation: Where are the live system, backups and support teams located? Identify who holds encryption keys, which subcontractors can access the environment and which jurisdictions apply to them.

• Maintenance: How long will the selected version receive security updates, and how quickly are serious vulnerabilities handled? Confirm whether the support agreement covers the whole stack or only the vendor's own components.

• Dependencies: Which databases, identity services, package registries, deployment tools and cloud features sit underneath the application? A portable application can still depend on a proprietary service that is difficult to reproduce elsewhere.

• Exit: Can the company export its data, configurations and audit history in documented formats? Name the team or alternative supplier that could rebuild the service, then test a small recovery or transfer before treating the plan as credible.

These questions also reveal where a managed service may be the better choice. A European operator with clear responsibility, strong documentation and tested export procedures can provide more usable control than an unsupported installation running on a server that only one employee understands. Sovereignty is strengthened by replaceable relationships and understood dependencies, not by maximising the amount of work kept in-house.

A practical adoption path for a mid-sized company

Start with the reason for considering open source. A customer contract may require stronger jurisdictional control. An approaching renewal may justify testing alternatives. A business-continuity review may have exposed a system that cannot be restored without the current supplier.

That reason determines the test. If jurisdiction is the concern, focus on ownership, hosting, administrator access and subcontractors. If continuity is the concern, focus on documentation, data export, replacement support and the time needed to rebuild the service. If negotiating position is the concern, prove that a second operator can run the same software before the next contract discussion.

Choose one bounded workload rather than turning open source into a company-wide rule. A suitable first candidate has clear data boundaries, an available support market and limited ties to proprietary platform features. Run it with realistic backups, updates and monitoring long enough to expose the operational work hidden by a product demonstration.

Then perform a modest exit exercise. Export the data, restore it in a separate environment and document what is missing. Measure how much depends on the current operator, how long the move takes and which knowledge exists only in one person's head.

The result may support a move, a mixed architecture or a decision to stay with the current supplier under better terms. All three can be sensible outcomes. The point is to turn theoretical access to code into evidence that the organisation has options it can actually use.

Europe's new strategy gives open source a serious role in digital sovereignty, while its emphasis on maintenance and governance keeps the claim grounded. Open source is a valuable means of gaining control. Hosting, accountability, skills and tested exit capacity determine how much of that control reaches the buyer.

Thinking about migration? Book a free consultation to discuss your situation.