Europe Bet on Open Source for Sovereignty. The Gap Is Governance.

The Linux Foundation published its fifth State of Open Source in Europe this month, and two of its headline numbers sit oddly next to each other. Ninety-four percent of the 367 European organisations surveyed call digital sovereignty strategically important to their technology strategy, with 61 percent calling it very important. Thirty-one percent have no formal open source governance at all [1].

Most sovereignty writing I read stops at the first number. The second one is the interesting one, and it describes something wider than Europe. Swap open source for agents and the same gap shows up.

What the EU actually put on the table

The Tech Sovereignty Package, proposed on 3 June 2026, is four measures: two legislative proposals (Chips Act 2.0 and the Cloud and AI Development Act), the EU Open Source Strategy, and a strategic roadmap for digitalisation and AI in energy [2]. Two of them touch open source directly.

CADA is the one to read, and the verb matters. Article 41 is headed “Promoting open source solutions and open source first,” but what it requires is that the Union and Member States “shall take the necessary measures to encourage Union entities and public sector bodies to use and facilitate the reuse of open standards and components released under an open source licence when building their cloud and AI ecosystem or stack” [3]. It then asks them to take account of “functionalities, including security, total cost, and other relevant, duly justified objective criteria” [3].

That is encouragement plus a cost test. A post claiming Europe now mandates open source procurement has not read Article 41. The same chapter does give the open source machinery some teeth: Article 42 requires public bodies that release software they own under an open licence to publish it through a catalogue connected to the EU OSS Catalogue, Article 43 obliges the Commission to run that catalogue, and Article 44 has the Commission establish a network of Open Source Programme Offices [3].

The assurance ladder is more concrete than the open source provisions. CADA defines four cloud and AI sovereignty levels [3][4]. Level 1 is data processed and stored in the Union. Level 2 adds independence from third countries and transparency over the software supply chain. Level 3 requires EU ownership and control plus criteria such as personnel citizenship. Level 4 requires full transparency and control over the supply chain and no third-country interference. Providers are recognised by Member States after an audit, and levels 2 through 4 require a comprehensive SBOM mapping dependencies, including reliance on non-EU and open source software [3][4].

Article 30 is the part I would hand to a procurement officer. Public sector buyers of cloud services would have to use services recognised at Union assurance level 1 at minimum, and only services at levels 2 to 4 where a risk assessment puts their work in the public-order categories [3]. Derogations exist, and they are narrow: a buyer has to justify them in the tender [3].

The instrument is not uniformly soft, and it is not an open source mandate either. The sovereignty ladder gives buyers a floor to meet. The open source preference is a nudge with a cost test attached. Most of the coverage I have seen quotes the preference and skips the ladder, which inverts where the obligation sits.

The supply-chain transparency requirement is where this gets awkward. The duty sits on providers, not on the body doing the buying: a provider seeking recognition at levels 2 to 4 has to hand an auditor a complete software bill of materials and a dependency list that names non-EU and open source reliance [3]. But a buyer who cannot read a software inventory is not much better off for having demanded one, and the survey finds that most cannot fully account for their own [1]. The ladder sets a floor for suppliers, and the survey suggests many buyers would not be able to do much with the evidence once it arrives [1].

The funding is smaller than the framing suggests. The report puts the Open Source Strategy at €2 billion over seven years, mobilised across the public and private sectors, against a European public sector that spends about €264 billion a year on proprietary IT [1]. The report does not dress this up: it calls the sum “real but modest” and says it becomes a strategy rather than a rounding error only if functioning OSPOs and enforced procurement rules show up alongside it [1].

There is a second document worth knowing about. The Public Procurement Act proposal, published 9 September 2026, makes best price-quality ratio the standard award method, with quality counting for at least 30 percent of the score, and 50 percent for labour-intensive contracts, under a comply-or-explain mechanism [5][6]. Public procurement is about 15 percent of EU GDP [5], so changing how bids are scored changes what vendors build. Open source enters the proposal mainly under the innovation heading, and the report says plainly that it “misses a chance to establish a rebuttable presumption favoring open source solutions whenever functional equivalence exists and to introduce a public money, public code principle” [1].

Between the two documents, sovereignty becomes something a buyer has to score, and open source stays something the buyer is invited to prefer. The result depends on the people running procurement and whether they can evaluate what they are buying.

The package does fund institutional capacity. The Open Source Strategy stands up an EU OSPO Network, a European Digital Infrastructure Stewardship Organisation, an Open Source Maintenance Instrument for critical components, and tools for assessing the sovereignty of value chains [1]. The report expects practical support for public buyers to matter more than any general rule telling them to buy open [1]. What I cannot find in that list is money for the internal work at the buying organisation: the inventory, the review hours, the trained evaluator. That is my reading of the Strategy’s measures rather than a claim the report makes, and if someone can point to the line item I will take the correction. The survey gives the reading some support. Of the 31 EU-headquartered public sector organisations in the sample, 15 report no formal open source governance at all [1].

What governance is worth, in the report’s own numbers

The report’s central finding is a spread. Organisations with no formal open source governance report a benefit-to-cost multiple of 3.6 times on their open source use. Those at the most mature governance level report 4.6. The European mean is 4.1, and upstream contribution alone returns between 2.3 and 3.3 times, with code contributions at 3.3 and community work at 2.5 [1].

Two things about those numbers before anyone puts them in a slide. They rest on 87 respondents rather than the full sample, and the report says outright that it cannot show governance produces the higher return: “None of this proves governance causes the higher return rather than simply correlating with organisations that were already more capable in other ways” [1]. The likelier story is that capable organisations do both.

What the report does have is a gradient that holds across measures taken separately. Upstream contribution rises from 30 percent among organisations with no formal governance to 87 percent at advanced maturity, private forking from 29 to 75, participation in project governance from 18 to 78, and full knowledge of which components sit in your products from 15 to 25 [1]. Four separate measures all moving the same way is better evidence than one multiple, and it is still correlation.

The sentence I would underline is the report’s own: “Not capturing that higher return is not a neutral gap, it is a competitive one.” I would underline it and then look at the figure underneath it. Even at the most mature governance level, only 25 percent of organisations say they fully know which open source components sit in their products [1]. The spread in reported returns is real. Any confidence that the organisations reporting 4.6 are on top of their dependencies should be lower than that spread suggests.

Forty-eight percent of organisations maintain private forks, and the report finds they cannot say what that costs them [1]. Interviewees described the comparison as something they believe and do not measure; the report’s phrasing is “a belief held with confidence and measured with none” [1]. One public body started with external contractors and hired DevOps staff internally after deciding it had too little control over what it was running. Another interviewee had a word for what short-term project funding leaves behind: “zombie files,” published to a repository, discoverable, never touched again [1].

The blockers say the same thing from another angle. Security concerns 39 percent, licensing and IP 36 percent, lack of technical support 35 percent, lack of leadership buy-in 34 percent. The report reads that cluster as “procedural, not technical” [1], and the interviews back it up. Tenders built around bundled proprietary licences and a single support contract do not fit an open source licence paired with a separate support contract, so open source bids lose by default rather than on merit. Procurement officials are rarely trained to evaluate an open source offer, and some public buyers do not know the alternatives exist [1].

The sharpest number in that section is leadership buy-in at 55 percent among EU-headquartered public sector respondents, against 34 percent overall. That is the largest segment gap in that part of the survey [1].

I have some sympathy for the manager in that number. Open source governance is unglamorous work: an inventory of what you depend on, a policy for what you may accept, a named owner, a decision about contribution, and a number attached to the cost of your fork delta. None of it produces a demo. The organisations that do it are also the ones reporting the higher multiple, and the survey cannot say which came first.

What agents do to the capacity gap

Forty-eight percent of European organisations report more open source use because of coding assistants, against 5 percent reporting less, and that is the number that gets quoted [1]. What matters more is the demand those assistants put on review capacity, which the survey says is missing.

The foreword, by Linux kernel maintainer Greg Kroah-Hartman, describes what arrived over nine months. New contributors submitted fixes based on reports from LLM tools. The tools claimed hundreds of bugs per codebase, and those numbers turned out to be wrong once a developer who knew the code looked. Linux kernel CVEs went from an average of 55 a week before the tools to 230 a week now [1]. Kroah-Hartman reads that rise as the tools doing real work, and I think he is right about that part. Some of those bugs had been sitting there for years.

The cost sits on the other side of the ledger. Working with graduate students at Vrije Universiteit Amsterdam over the summer, he found that “even for the best and most powerful LLM tools available, almost half of the changes that were produced were incorrect” [1]. Maintainers now require submitters to prove a change is correct before it is accepted, on the principle that validation is the submitter’s job and not the receiver’s.

Two more data points in the same direction. New contributors to the Linux kernel tripled in the second quarter of 2026, and the OpenStack security team issued 38 advisories by September 2026, roughly thirty times its pre-AI pace [1]. Meanwhile 59 percent of European organisations contribute code upstream but only 37 percent take part in project governance, and only 33 percent call open source very successful for local AI deployment, against a much better picture for cloud, portability, data localisation and interoperability [1].

Together those numbers describe a continent that has largely solved infrastructure sovereignty and has not solved AI sovereignty, while machine-generated contribution and machine-found vulnerability rise against a governance layer a third of organisations have not built. The tools that make contribution cheap make review the bottleneck, and review is a governance function.

Agents matter here because they multiply whatever review and inventory capacity an organisation already has. A third of European organisations have no formal governance for that work to run on, and it is that third reporting 3.6 times rather than 4.6.

Europe prefers the commons it is legislating around

There is a tension in the package that the report flags and then moves past. It deserves more attention than it gets.

Fifty-two percent of European organisations prefer foundation-hosted, neutrally governed projects as their governance model, eight percentage points ahead of the rest of the world, and Europe supplies almost 40 percent of global contributions to OpenStack and Kubernetes [1]. Yet the package builds its stewardship “around new EU-specific vehicles rather than existing global foundations” [1]. The Open Source Strategy’s own justification notes that open source building blocks are mostly maintained through foundations with US and Chinese big tech providing a large share of the funding. The report points out what that framing misses: in open governance, financial sponsorship is decoupled from technical leadership [1].

The Agentic AI Foundation makes the same point concretely. It launched on 9 December 2025 around MCP, goose and AGENTS.md, and every founding Platinum member is American: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI [1][7]. The only European members, SUSE, SAP and Ericsson, sit at Gold and Silver. The report’s summary of Europe’s position is “strong on code contribution, thin on governance seats,” and it notes the pattern was visible from the foundation’s first governance meeting [1].

An EU-hosted stack does not fix that. A seat at the table fixes it, and seats come from participation, which is the 37 percent number again. Buying software from anywhere is easy; writing the spec that software has to follow is not, and that is a participation problem rather than a purchasing one.

What I would do with this

The private fork number is the one I would take personally, at any scale. A handful of patched repositories is a fork, and being small does not exempt anyone from the arithmetic the report describes.

The cheap version of the discipline the €2 billion is meant to buy at scale is a page of notes: what you run, who maintains it upstream, what your patch delta is, what breaks if the project changes direction, and what it would cost to get back on the upstream feed. It is the inventory CADA’s audit framework asks a provider for at levels 2 to 4 [3], and the knowledge a buyer needs to make sense of what comes back. I would write it whether or not anyone asks.

For a public body, the sequencing in the report is the useful part. The OSPO network under Article 44 is the cheapest piece of the package to stand up, it needs no procurement reform to start, and the 55 percent leadership buy-in figure says the obstacle runs upward rather than through engineering [1][3]. Training procurement officials comes next. One interviewee’s suggestion is to separate technology procurement from service procurement and certify buyers the way other professional judgements are certified [1]. The upside for anyone who starts early is that the scoring rules, when they land, favour organisations that already know what they are running.

What this report cannot tell you

LF Research is the Linux Foundation’s research arm, publishing a finding that open governance of open source pays. It is not a neutral party, and this edition was sponsored by member organisations [1]. The sample is 367 self-selected European organisations, 70 percent headquartered in the EU, 88 percent in technical roles and 57 percent in leadership positions [1]. The benefit-to-cost multiples are respondent estimates, not audited accounts. Treat 4.6 times as what organisations believe they get, not what an accountant verified. They also rest on a thin base: 87 respondents answered the benefit-to-cost question, divided across five governance levels, and the report states that it cannot show governance causes the difference [1]. The public sector subsample behind the 15-of-31 figure is 31 people, which is why I gave the raw count instead of a percentage.

None of this is law. Article 41 and the assurance levels still have to go through the Parliament and Council, and the report puts entry into force at the earliest in 2027 or 2028 [1]. The Public Procurement Act is a proposal from September [5]. The €2 billion is small against €264 billion a year, and the report says so itself [1].

The Kroah-Hartman figures come from a foreword, not a study. The CVE counts are one maintainer’s own series, and the “almost half incorrect” result is a summer exercise with graduate students, not peer review. They are worth citing because he is the person doing the work, not because they are audited.

What survives those caveats is a measurement of something that usually goes unmeasured, and a gap that more funding does not close by itself. Europe can pass the procurement rules without building the capacity to use them. The organisations already reporting 4.6 times are best placed when those rules arrive. The third with no formal governance is the furthest from ready, and that group reports 3.6 times rather than 4.6: 15 percent of them say they fully know which components sit in their products, against 25 percent at the most mature level [1].

None of the CADA duties I have described attaches to that survey cohort as such, and none attaches to public buyers as buyers. Article 30 asks contracting authorities to procure cloud services recognised at level 1, and at levels 2 to 4 where their activities fall in the public-order categories [3]. The inventory sits on the supply side: a candidate cloud provider seeking recognition at levels 2 to 4 has to give an auditor a complete software bill of materials and a dependency list covering non-EU and open source reliance [3]. An organisation in that third which is also a candidate provider would be writing the inventory instead of reading it. For everyone else the work stays optional, which is the problem the survey measures.

Sources

1. 2026 State of Open Source in Europe: Navigating AI and Digital Sovereignty Through Open Governance — LF Research / LF Europe, October 2026 (PDF; foreword by Greg Kroah-Hartman). Survey figures, benefit-to-cost multiples and their 87-respondent base, the report’s non-causation caveat, the governance gradient figures, fork and blocker data, interview quotations, the €2bn and €264bn figures, the “real but modest” and “misses a chance” passages, the AAIF membership breakdown, and the kernel and OpenStack figures.
2. Commission proposes tech sovereignty package to strengthen Europe’s digital autonomy and resilience — European Commission press release, 3 June 2026. Contents of the package.
3. Proposal for a Regulation establishing a framework of measures for strengthening Europe’s cloud and AI ecosystem (Cloud and AI Development Act), COM(2026) 502 final — EUR-Lex, 3 June 2026. Articles 17, 20 and 30, plus Articles 41 to 44, read verbatim; Annex II audit criteria for levels 2 to 4, including the software bill of materials and dependency list a provider must give an auditor.
4. Cloud and AI Development Act — European Commission policy page, last updated 3 June 2026. Definitions of the four assurance levels and the recognition process.
5. Commission proposes simpler and more strategic Public Procurement rules (IP/26/1817) — European Commission press release, 9 September 2026. Date of the proposal, best price-quality ratio as the standard award method, the 30 and 50 percent quality weightings, comply-or-explain, and the 15 percent of GDP figure.
6. Proposal for a Regulation on the Public Procurement Act — European Commission, 9 September 2026. The proposal itself.
7. Linux Foundation Announces the Formation of the Agentic AI Foundation — Linux Foundation, 9 December 2025. Founding Platinum member list.