Europe's tech sovereignty debate has frequently centered on software, which is now often linked to open licensing and governance as a tool for structural sovereignty. When Europe talks about hardware sovereignty, it tends to focus on manufacturing: foundries, supply chains, and the geographic concentration of semiconductor production. Far less attention is paid to openness: who controls the design tools, the IP blocks, and the chip architectures that feed those foundries, make up those supply chains, and support that production.

To that end, the EU's landmark Tech Sovereignty Package — released earlier this month alongside an accompanying Open Source Strategy — tells only part of the story. It makes a compelling case for technological sovereignty broadly, showcasing how proprietary technology (mostly identified as software) creates structural dependencies in European supply chains that go beyond market inefficiencies. These dependencies can lock institutions into foreign-controlled systems in ways that undermine strategic autonomy. Open source is positioned as a lever of structural sovereignty, a means of reinforcing open strategic autonomy and digital resilience. Yet the emphasis again remains largely on software. The same principles for openness should apply to hardware.

The limits of a software-focused approach to tech sovereignty

Open-source hardware — a paradigm that has existed nearly as long as open-source software — offers many of the same benefits: transparency, auditability, and the freedom to adapt and build. At the physical layer, however, the stakes are higher and the dependencies harder to escape. Code can be forked overnight; fabrication plants cannot. Design tools, chip architectures, IP blocks, and manufacturing equipment are all vectors of dependency, and in most cases, those vectors currently run through non-European actors.

The open-source response is not to replicate proprietary production at a European scale. That is a separate, longer, and far more expensive project. Instead, the goal should be to open the design layer: making hardware knowledge a commons rather than a controlled asset, lowering barriers to participation, and building the technical capacity needed to support meaningful sovereign production. This is precisely what the open-source hardware movement has been doing for decades (for example, with Arduino from Italy): giving researchers, engineers, and makers access to tools and designs they would otherwise be unable to afford or inspect.

Gaps in Europe’s open-source strategy

On these points, the EU’s Tech Sovereignty Package is frustratingly silent. The Open Source Strategy from the European Commission breaks new ground on software while treating hardware — the physical infrastructure on which all software ultimately runs — largely as an afterthought.

To its credit, the package does get some things right. The Chips Act 2.0 and “Open EU Foundry” provisions are a real step forward in addressing manufacturing dependency. On hardware more broadly, however, the strategy is more tentative. It also gestures at RISC-V — an open-source Instruction Set Architecture (ISA) that allows anyone to design, manufacture, and sell custom microchips without paying royalties, and to open electronic design automation (EDA) software tools used for designing electronic systems.

These aren't token references. Research from the OSAwards.eu initiative, drawing on interviews with hardware experts across Europe, identifies RISC-V as a credible lever for building European technological capabilities. The same is true for open-source EDA tools, even if they remain far short of what their proprietary counterparts offer for cutting-edge silicon design. The aim is not to displace commercial tools but to pair high-quality open tooling with paid commercial support, the combination of which has proved most durable in software.

But citing a handful of projects is not the same as building a strategy around open-source hardware. The problem is that the strategy as a whole does not treat openness at the physical layer as a strategic priority in its own right. It pays little attention to robotics, edge computing, networking hardware, or scientific instrumentation — domains where Europe has significant capabilities, but also substantial exposure to external dependencies. Those dependencies extend well beyond chips. Europe, for example, lacks a domestic company capable of designing and manufacturing the high-end servers that power its data centers.

While numerous open-source software projects are referenced, work like CERN's long-running leadership through the CERN Open Hardware License and Arduino — both European inventions — are only mentioned in footnotes or annexes. Little attention is paid to other open source hardware innovations, even though there are numerous European exemplars, like White Rabbit, representing exactly the kind of open hardware commons the strategy could build upon.

The package also does not address the problem of stack coherence. A sovereign operating system running on a foreign-controlled chip with a proprietary instruction set offers only partial sovereignty at best. Open-source hardware is not a niche complement to the software agenda, but a prerequisite for making software sovereignty physically real. The logic that drove open source to revolutionize software education and economic activity applies just as directly to hardware: RISC-V is doing for processor design what Linux did for operating systems. The question is whether European policy will follow that logic to its conclusion.

Important connections to Europe’s strategy for digital skills

On skills, the gap is acute and underappreciated. Hardware design requires a different set of competencies than software. The European talent shortage in chip design and EDA is estimated at over 100,000 professionals. The strategy's skills provisions don't reflect this, and do little to engage the designer communities who have historically been the seedbed for open hardware innovation. Universities like ETH Zürich, TU Delft, and the University of Bologna are producing high-quality graduates, but not at the scale the Chips Act's ambitions require.

Full independence in cutting-edge semiconductor fabrication is not a near-term goal, and this isn't where investment should focus. The more viable and strategically important path is building absorptive capabilities: investing in R&D programs like ETH Zürich's PULP platform, funding open EDA toolchains, connecting open foundry provisions to open design ecosystems, and extending the governance logic of open-source software — stewardship, commons-based development, public-private partnership — to hardware.

Two further moves would further sharpen this approach. The Commission should extend its own “Public Money, Public Code” principle to hardware. A great deal of publicly funded design already exists, and requiring labs and universities to release it — ideally alongside firms that customize and commercialize it — would reduce waste and give Europe a broader base of alternative commercial alternatives should any single vendor prove unreliable. Much of the software infrastructure agenda also transfers directly. An EC-supported hardware catalog (e.g., CERN’s ohwr.org is one model) and a “GitHub for hardware” that supports comments and visual diffs on a design would both fill a gap that proprietary vendors are already racing to close within their own cloud ecosystems.

It’s not too late

Europe’s strategy is not set in stone, and much of the package’s language on open source is already inclusive of both software and hardware. The simplest safeguard would be to make that inclusion explicit throughout. This would mean treating “open source” as covering software and hardware alike, since the boundary between them is increasingly blurred, and recognizing open source as a route for disseminating publicly funded hardware, not only software.

Such interpretation matters because it shapes the implementation of the strategy. It can also help to address a material omission in the package, which will influence where investments are made. Sovereignty that stops at the software stack is not structural sovereignty; it is, at best, a partial answer to a deeper problem.