The Question That Is Rarely Asked Clearly
A great deal of procurement language at the moment speaks of open source as a sovereignty answer. The reasoning runs roughly like this. Proprietary cloud providers are foreign-jurisdiction firms. Open source is, by contrast, open. Therefore open source is sovereign.
The conclusion is louder than the premises warrant. Open and owned are not the same word. They overlap in places. They diverge in others. Where they diverge tends to be precisely where procurement assumes they do not.
Europe is, at the moment, the most visible case in the Western press. France's Interministerial Digital Directorate (DINUM) announced in April 2026 a migration of its own workstations from Windows to Linux, with a directive to all ministries to formalise plans for eliminating extra-European dependencies by autumn. That is a serious commitment in scale and visibility. It is also not the only one. Huawei launched its HarmonyOS PC line in May 2025 after the company's Windows licence was withdrawn under US sanctions. India has produced BharOS through IIT Madras and government sponsorship. China's procurement directives now favour domestic ISA work (Loongson, RISC-V derivatives) at the chip layer. The question is being asked across multiple jurisdictions; the reasoning, where it goes wrong, goes wrong in similar ways.
A licence is not a deed of ownership. It is a statement of conditions. The question worth asking is: which conditions move ownership towards you, and which conditions hold it elsewhere?
Two Families of Licence, Plus a Fourth Shelf
For the discussion to be useful, the licence landscape needs three shelves rather than two.
Permissive licences (BSD 2-Clause, BSD 3-Clause, MIT, Apache 2.0) let anyone build on the code, fork it, ship it, sell it, and combine it with other code under any licence at all. The original code's authors retain attribution. Everything else is the receiver's to do with as they wish.
Copyleft licences (GPLv2, GPLv3, LGPL) let anyone receive the code and modify it, but require that any distribution of the modified version arrives under the same licence. The receiver does not own what they build with it in the unrestricted sense; they hold it under the conditions the original author set, in perpetuity.
Network copyleft licences (AGPLv3) extend copyleft to the case where the modified version runs as a service rather than being distributed as a binary. AGPL Section 13 closes what is sometimes called the SaaS loophole of classical GPL.
The Server Side Public License (SSPL), introduced by MongoDB in 2018 and adopted by Elastic in 2021, extends AGPL's network clause to require open-sourcing of the entire surrounding management stack. The Open Source Initiative declines to recognise SSPL as open source, citing field-of-use discrimination. Whether that decision is right is a separate question. The practical effect is a fourth shelf that does not behave like the other three.
The European Union Public Licence (EUPL-1.2) sits in the copyleft family and is OSI-approved. It exists in part because the EU wanted a Union-grounded licence with cross-Member-State legal certainty in twenty-three languages.
The GPL Cul-de-Sac
GPL keeps the code open. It does not return it to you.
What GPL guarantees is that every downstream version of the code remains under GPL. The original author's licensing choice propagates indefinitely. This is its virtue in one reading and its cul-de-sac in another. A European entity that needs to take a piece of GPL code, integrate it with proprietary or commercially-sensitive surrounding code, and ship a product, finds that GPL has decided the licensing of the surrounding code as well. The licence absorbs.
A useful demonstration of this point is FreeBSD's compiler migration. FreeBSD 10.0, released in January 2014, moved its base system from GCC to Clang. The technical case existed but was not decisive on its own. The decisive factor was that GCC had moved to GPLv3. FreeBSD wished to ship a base system whose licence terms were uniformly permissive for downstream re-use. GPLv3 did not allow that. So the tree was rebuilt.
That migration is not anti-GPL polemic. It is an architectural fact. A coherent permissive base required a permissive compiler. The presence of a copyleft compiler in the base would have leaked copyleft conditions outwards. FreeBSD's developers concluded that the cost of staying on GCC was higher than the cost of switching. They switched.
For a European sovereignty discussion, the analogous question is: which licence allows the receiver to build a coherent local stack, host it, modify it, and not be required to re-licence everything that touches it? Permissive licences answer yes without conditions. AGPL answers yes for hosted services, provided you publish the modifications. GPL answers yes for the GPL component; anything that links to it must also be GPL. The three answers are not equivalent.
The Honest Middle of AGPL
There is a temptation in any sovereignty discussion to treat permissive licensing as obviously correct and copyleft as obviously wrong. That would be tidy but inaccurate.
AGPL is the honest middle. It says: if you modify this code and use it to serve users over a network, the users have a right to your modifications. It does not require you to share user data, internal management software, or anything outside the modified program itself. It closes the specific gap that classical GPL leaves open and stops there.
The structural difference between AGPL and SSPL is exactly this. SSPL extends the requirement to surrounding management and hosting software, which is what tipped it out of OSI's open-source classification. AGPL keeps the requirement on the program itself.
For European public services that build on open code and run as networked offerings, AGPL is a defensible licence choice. It says, plainly: you may use this, and what you build on top is your code; but the modifications to this code, when used as a service, return to the commons. That is reciprocity, not absorption.
The xz Evidence: Open Is Not Audited
In March 2024, a Microsoft engineer named Andres Freund was profiling SSH connections on his development machine and noticed an unusual amount of CPU time spent inside liblzma. He investigated, and discovered a sophisticated backdoor in the xz/liblzma compression library, assigned CVE-2024-3094 with a CVSS score of 10.0.
The backdoor had been inserted by a maintainer operating under the name Jia Tan, after a multi-year social engineering campaign that began in 2021. The campaign pressured the original maintainer into ceding maintainer privileges. Once granted, the new maintainer introduced the backdoor in version 5.6.0, where it persisted into 5.6.1.
xz/liblzma is open source. Anyone could read the code. The backdoor was discovered, in the end, by a PostgreSQL developer noticing SSH latency on a single machine. Not by the audit infrastructure of the open-source ecosystem. By one person's curiosity.
The lesson is not that open source failed. The lesson is that open and audited are different words, and that a great many sovereignty arguments assume the second when they say the first. Permissive licensing makes audit possible. It does not make audit happen.
For European sovereignty arguments, this is not an abstract point. If you depend on open-source code that you do not audit, you are dependent on whoever is auditing it, or, more typically, on luck. The xz incident is one data point. There will be others.
The Linux Maintainer Adjustment
In October 2024, the Linux kernel project removed approximately eleven maintainers from a particular jurisdiction that had recently come under expanded US sanctions. The change appeared on the kernel mailing list under the formulation compliance requirements. Linus Torvalds confirmed it shortly afterwards and declined to reverse it.
The specific jurisdiction in that particular month is not the point of this piece. The point is that the lever exists, it can be applied, and on that occasion it was. The Linux Foundation is registered in the United States, and US sanctions reach the operations of US-registered organisations. Whichever jurisdiction comes under expanded US legal pressure next has the same exposure to the same mechanism. Huawei's earlier experience with the Entity List in 2019, which led directly to HarmonyOS as a self-developed operating system, is the same lever applied at a different layer of the stack.
This is not a moral judgement on any particular decision. Each decision may well have been the only one available within the constraints. It is a structural observation. The Linux kernel's governance is administered through a US-registered foundation, and is therefore subject to US legal reach. That is a fact about the location of the upstream, not about the quality of the code, and not about the merits of any party in any open conflict.
A licence that is permissive cuts this knot, in practice. A receiver who pulls a permissive codebase, builds it locally, and maintains a local tree is not bound by the upstream's jurisdictional reach. They have the code. They may continue to build it. The upstream's relationship with any single state does not propagate to them.
A GPL codebase places this differently. The receiver may build and modify, but their modifications are governed by the same licence. The relationship with the upstream is not severed by the act of forking. Permissive licensing makes ownership transfer cleanly. Copyleft licensing makes it inherit conditions.
The Legal-Jurisdictional Stake
The European stake in this question is the most thoroughly codified in the Western press, which makes Europe a useful working example. It is not the only region facing the same shape of question.
The CLOUD Act, passed in March 2018, permits US law enforcement to compel US-based service providers to hand over data, regardless of where that data is stored. US-based providers operating data centres in Frankfurt, Dublin, or Paris are subject to it. Their European subsidiaries are subject to it as well, through their corporate connection to the US parent.
The Court of Justice of the European Union's Schrems II ruling of July 2020 (Case C-311/18) held that US surveillance law under FISA Section 702 and Executive Order 12333 does not meet the proportionality standard required by EU law, and invalidated the EU-US Privacy Shield framework on that basis.
These two legal facts do not converge on a single recommendation. They do create a strong reason for European public services and infrastructure providers to prefer software stacks they can host, modify, and audit locally, without external jurisdictional reach. The same reasoning runs in Beijing, in New Delhi, in Moscow, in Brasilia, with the relevant counterpart jurisdiction differing in each case. The principle is not specific to Europe; the codification is.
The EUPL exists in this context. It is a copyleft licence with explicit EU-grounded legal interpretation, intended to give European deployers legal certainty under their own law rather than under foreign law. It is one defensible answer for European public-sector code. Permissive licences are another. India's BharOS, China's HarmonyOS, and similar projects answer the same question from different angles. The choice is real, not merely stylistic.
The Practice That Gives a Licence Meaning
A licence is a permission slip. A permission slip is not, by itself, sovereignty. Sovereignty is the practice of using the permission.
The practical layer consists of three things.
Reproducible local build. The receiver compiles the code from source in a known environment, without reliance on upstream-provided binaries. This is what take ownership means at the build level. It is also what makes audit and modification possible.
Audit and signing. Someone who knows the code reviews it. Someone with cryptographic standing signs the build artefacts. The two together make the deployment defensible.
Continuous re-receipt. Upstream changes are pulled, reviewed, and integrated; the local tree does not freeze. Sovereignty does not mean refusing all upstream input. It means being the one who decides what to accept.
These three practices are licence-agnostic in principle. In practice, they are easier under permissive licensing and harder under copyleft, because permissive licensing does not generate licence-compatibility friction at the integration boundary.
The Limit
This piece argues that a licence is not by itself ownership, and that permissive licences (BSD, MIT, Apache 2.0) and AGPL move ownership most cleanly to the receiver under conditions a European context tends to care about.
It would be dishonest, however, to leave it there. The licence layer is the layer with the most words and the most procurement documents. It is not the layer with the most consequences.
A receiver who owns the licence, but does not own the build infrastructure, does not own the result. A receiver who owns the build infrastructure, but runs it on someone else's silicon, has only moved the ownership question down a layer. A receiver who reviews the source, but does not have the institutional muscle to maintain a local fork through multiple upstream major versions, has obtained an option they cannot exercise.
This piece sets the question. It does not answer the architectural question of how a coherent local stack is even shaped, or the hardware question of where ownership stops being negotiable at all. Those are the next two Sundays.