Dries Buytaert

"Buy European" is becoming Europe's rallying cry for digital sovereignty. The logic is intuitive: if you want independence from American technology, buy from European companies instead.

However, I think "Buy European" gets one thing right and one thing wrong. It's right that Europe benefits from a stronger technology industry. But buying European does not guarantee sovereignty.

Sovereignty is not about where a company is headquartered or where software was originally written. It is about who ultimately controls the technology.

The right question to ask about any technology: can someone take the software away from me?

Sovereignty has two dimensions: how much control you have today, and how much of that control is structural, built into the legal foundations.

The proposed scale measures the second. It evaluates how resilient software is to change, whether through acquisition, relicensing, or loss of critical funding.

I used five levels, modeled on Europe's familiar A-through-E labels for energy efficiency and food nutrition, from structurally sovereign to fully dependent. This scale is meant as a starting point, and I expect it to improve through scrutiny and feedback.

At the bottom, grade E, is foreign proprietary software: no source code, no right to modify, and no alternative if the vendor changes terms. Your vendor is subject to its home government's jurisdiction, and by extension, so is your data.

Grade D is European proprietary software, which is where "Buy European" usually comes in. It has real benefits: European jurisdiction, GDPR alignment, local accountability, and it keeps investment circulating in the European ecosystem. As someone who has started companies and invests in startups, I want more technology companies to succeed, not fewer. But "European" can be a temporary property of a company: it can change with a single board meeting.

Skype was founded by a Swede and a Dane, built by Estonian engineers, and headquartered in Luxembourg. eBay acquired it in 2005, and Microsoft acquired it in 2011. The eBay transaction turned a world-leading European technology into an American one, and it was cemented with the Microsoft deal.

So ownership and jurisdiction matter, but they're not enough. A European company can be acquired tomorrow. Open Source offers something more important: it separates the code from any single company or country.

Not all Open Source is equally sovereign

This is also why drawing lines between "European" and "non-European" Open Source misses the point. Open Source separates software from geography by design. What matters is not where a project began, but whether anyone can take control of it later.

But Open Source sovereignty exists on a spectrum. The level of protection comes down to two legal levers: the license itself, and the copyright ownership, which determines who has the power to change the license.

Grade C is Open Source under a permissive license like BSD, MIT, or Apache. You can view the code and fork it if needed, but the license does not require improvements to remain open. A company can take the code, build on it, and release a proprietary version.

If a closed commercial version becomes the standard through branding, hosted services, or enterprise features, governments that depend on it can become legally and operationally locked in again. They are back at grade E.

Redis shows how this dynamic unfolds. It was Open Source under a BSD license for fifteen years. In March 2024, Redis Ltd. relicensed it under restrictive terms that the Open Source Initiative does not approve as Open Source.

Fortunately, the community forked the last open version as Valkey, and Valkey is thriving. That is the strength of permissive Open Source: you can escape when terms change. Governments were fortunate Redis was forked, but the structural risk remains.

Grade B is Open Source under a copyleft license like the GPL, with a single copyright holder.

Copyleft adds a protection permissive licenses lack: any derivative of released code must also remain Open Source. For policymakers, this is a meaningful upgrade. Once code is published, it can always be forked, inspected, and maintained independently, even if future versions change direction.

This is the level that saved MySQL. MySQL AB, the Swedish company behind MySQL, released it under the GPL, so when Oracle acquired MySQL through the Sun Microsystems deal, the GPL ensured the code remained open. Michael Widenius, MySQL's original creator, took the code and built MariaDB. Oracle got the brand, but the world kept the code.

And because MariaDB inherited MySQL's GPL license, it must stay open too. No future acquirer can make MariaDB proprietary. That is the difference between copyleft and a permissive license: copyleft lets someone fork, and forces the fork to stay open.

But grade B still has one limitation. The copyright holder can release future versions under a different license. The existing code is protected by the GPL, but the project's future license is controlled by whoever holds the copyright.

Some projects amplify this risk by requiring contributors to sign a Contributor License Agreement, or CLA, which grants the project owner the right to relicense contributed code. Elasticsearch, founded in Amsterdam, used its CLA in 2021 to relicense from Apache 2.0 to a non-open-source license, despite having over 1,500 contributors.

Finally, grade A is copyleft Open Source with distributed copyright ownership. When hundreds or thousands of contributors each own their portion of the code, relicensing requires the consent of every one of them. For anyone who refuses, the project must rewrite their contributions from scratch.

Drupal has had contributions from tens of thousands of people across 25 years, which makes relicensing structurally impossible. No acquisition, no board vote, no change in strategy can take these projects away from the people who build and depend on them. The code is structurally sovereign by design.

Sovereignty is a long-term commitment

Not every system needs to be grade A, and grade A projects take decades of community investment to build. Moving from grade E to grade D is progress. Moving from D to C is more progress. The scale is not a filter that disqualifies; it is a tool that makes tradeoffs visible, so that when governments choose a lower grade, they do it knowingly, not unknowingly.

Building and sustaining grade A projects requires long-term investment. It takes years of sustained community commitment and, likely, public funding that treats Open Source as infrastructure.

A grade A project that loses important funding often needs investment to remain viable. But unlike acquisition or relicensing, funding risk is largely within the EU's control through government procurement and public investment.

Recommendation for the European Commission

Sovereignty involves many things: data location, supply chains, technical talent, and standards. Licensing and copyright form the structural foundation because they determine whether legal independence is even possible.

The European Commission's Cloud Sovereignty Framework reflects this broader view. It evaluates cloud software across eight sovereignty objectives, including Technology Sovereignty, which asks whether software is "accessible under open licenses". This is a welcome step. But it treats open licensing as binary: either software is open or it isn't.

As this blog post shows, that is not enough. The European Commission's framework should distinguish between software that is open today and software that is open permanently.

I would encourage the Commission to strengthen its Technology Sovereignty objective in two ways:

1. Distinguish between license types. Permissive licenses (BSD, MIT, Apache) place no obligation on derivatives to remain open. Copyleft licenses (GPL, AGPL) require derivative works to be released under the same open terms.
2. Assess copyright concentration and relicensing risk. A project with a single copyright holder or a Contributor License Agreement can be relicensed regardless of its current license. A project with distributed copyright ownership cannot. This is the difference between a revocable and an irrevocable commitment to openness.

In follow-up posts, I will share two more recommendations for the Commission's framework: one about the relationship between the eight sovereignty objectives, and one about infrastructure jurisdiction. Together, these three posts aim to help strengthen what is already a serious and welcome effort. If you'd like, you can subscribe to follow along.

I think the Software Sovereignty Scale should be part of European procurement policy. When a government selects a content management system for its public websites or a database for its national health records, it should know the structural sovereignty grade of the technology it depends on.

For critical software, the question is simple: how easy is it for someone to take the software away from us?