“We’re switching to Linux.” “We’re going with open-source software.” These phrases come up whenever a committee discusses software sovereignty, and they’re stated as if they were self-evident, as if open-source code alone were enough to settle the issue. It does settle part of it. It leaves another part untouched, and sometimes it merely shifts the problem without solving it. Sovereignty isn’t determined by the opposition between proprietary and open-source software. It’s determined layer by layer: who controls what, and can we break free from it.

What Open Source Actually Guarantees

Free software is based on four freedoms, formalized by the Free Software Foundation: the freedom to run the program for any purpose, to study how it works, to redistribute it, and to modify it and distribute the modified versions. Open source, as defined by the Open Source Initiative, covers a similar scope. These freedoms are not theoretical. They result in three concrete properties.

First, auditability. The source code is readable and therefore verifiable. An organization that wishes to do so can examine what the software actually does, without having to take the publisher’s word for it. In a regulated industry, this transparency serves as evidence.

Second, the absence of a revocable license. A free license—whether GPL, Apache, or MIT—cannot be revoked by unilateral decision. The publisher cannot cut off access to a version that has already been obtained, nor can it prohibit its use overnight. Continuity does not depend on the goodwill of a third party.

Finally, the ability to fork. If the project changes course, shuts down, or falls into hostile hands, the code remains available and someone else can take over its development. The maintenance community, when it exists, distributes this burden among multiple contributors and organizations.

What It Does Not Guarantee

None of these freedoms is a service. Open-source code comes with no support, no guarantee of fixes, and no roadmap. The freedom to modify is only meaningful to those who know how to modify, and the freedom to audit is only meaningful to those who have the means to do so. Reading the source code of a kernel, a hypervisor, or a database to ensure it contains no vulnerabilities requires rare skills and an ongoing investment. Available code is not the same as audited code.

Security follows the same logic. Free software is not secure simply because it is open-source; it is secure when competent people read, test, and fix it over time. The 2021 incident involving the critical log4j vulnerability—a building block present in countless systems and maintained by a handful of volunteers—served as a reminder that an open-source, ubiquitous component can remain underfunded and under-monitored. Openness makes auditing possible; it does not actually perform the audit.

Above all, open source says nothing about the infrastructure. Free software always runs somewhere—on machines, within a network, under a jurisdiction. The code’s license and the host’s legal affiliation are two distinct issues, and the former never addresses the latter.

Cases Where OSS Truly Makes a Difference

Free software impacts sovereignty when it acts on the right levers. Three situations illustrate this.

Local deployment. Free software installed on infrastructure controlled by the organization eliminates dependence on a remote service provider. The code is on-site, governed by a chosen legal framework, with no outbound calls to a third party. This is the scenario that comes closest to true independence.

Regulatory auditability. For a health authority, a bank, or a critical infrastructure operator, being able to produce the exact code that processes sensitive data is not merely a convenience—it is sometimes a legal requirement. A sealed, proprietary component prevents this verification; an open-source component enables it.

The absence of a revocable license. A critical proprietary service may see its terms change, its price rise, or its access cut off by a vendor’s decision or as a result of an extraterritorial measure. A free license shields the software layer itself from this risk. It does not shield the rest.

Cases Where It Makes No Difference

Conversely, the “open source” label offers no guarantee of sovereignty in several common scenarios.

Free software deployed at a third party’s site. A free database or orchestrator operated as a managed service on foreign infrastructure is subject to that operator’s legal jurisdiction, just like a proprietary product. The code is open, but the dependency remains complete. The nature of the license does not alter the legal affiliation of the entity operating the machine.

Dependence on proprietary components. A free operating system that will only boot with proprietary drivers, signed microcode, or closed-source firmware is not autonomous. The visible layer is open, but it relies on building blocks that cannot be read, reproduced, or replaced. Freedom ends at the first sealed piece of hardware.

The lack of internal maintenance capability. The freedom to fork a critical kernel is only meaningful for those who can actually maintain it. A highly regulated company or a defense contractor that lacks the engineering resources to take over development of an OS whose publisher is withdrawing finds itself dependent on a service provider, whether open-source or not. The right to modify does not create the ability to modify.

In these three cases, the key aspects—control over the layer and the ability to move away from it—are not guaranteed by the license. They depend on where the software runs, what it relies on, and who knows how to manage it.

The right question, therefore, is never about the label. It must be asked layer by layer, from hardware to service: who controls each layer, under what rights, and what happens the day that control is lost. Free software shifts some of these answers in the right direction. It does not write the others for you.

Sources

  • Free Software Foundation, definition of free software, gnu.org
  • Open Source Initiative, Open Source Definition, opensource.org
  • Apache Software Foundation, Log4Shell vulnerability (CVE-2021-44228), December 2021
  • ANSSI, recommendations on software foundation security, cyber.gouv.fr

The French government has made its decision, and this changes the game

The debate has moved beyond online forums. In 2026, the Interministerial Directorate for Digital Affairs (DINUM) will require each ministry to submit a plan to reduce digital dependencies outside Europe. The scope is broad: workstations, collaboration tools, antivirus software, artificial intelligence, databases, virtualization, and network equipment. The switch from Windows to Linux as the operating system is merely the most visible layer of a much deeper transformation.

Alongside the OS, the government is promoting its own suite of tools: Tchap for messaging, Visio for videoconferencing, and FranceTransfert for file sharing—all grouped together in the Digital Suite. The National Health Insurance Agency has already migrated 80,000 employees to these tools. The stated goal is to have more than two million employees using these tools by 2027. The catalyst is not a technical whim. The resurgence of trade tensions in 2025 has reignited the issue of jurisdiction, and the CLOUD Act has become too prominent to ignore.

The Gendarmerie Did It Twenty Years Ago

What’s new is the scale, not the principle. The National Gendarmerie has been running on Linux since 2008, using GendBuntu, a custom-built version of Ubuntu. As of June 2024, it had equipped 103,164 workstations, representing 97 percent of its fleet. The savings are clear: approximately two million euros less in annual licensing costs, and a total cost of ownership reduced by about 40 percent.

What matters isn’t the number—it’s the method. The Gendarmerie did not make the switch all at once. It began as early as 2004 with painless building blocks—the web browser, the office suite, and email—while internal expertise and governance were being developed. The operating system came last, on ground that had already been prepared. In 2026, DINUM explicitly cites this model as the path forward for other ministries. Software sovereignty cannot be bought; it is built, layer by layer, over the course of years.

Open Does Not Mean Secure

One pitfall remains, and it is precisely the one this article has been highlighting from the start. Choosing Linux and open source eliminates one dependency. It does not come with security as a bonus. A sovereign tool is not secure by design. It still needs to be audited, hardened, and maintained with just as much rigor as any proprietary software—sometimes even more, since responsibility can no longer be outsourced to a vendor.

The government’s email system learned this the hard way, discovering that its French origin and open-source code did not exempt it from the work of securing the system. In fact, the opposite is true: the freedom to look under the hood imposes the duty to do so. Open source makes security verifiable; it does not guarantee it. Those who fail to verify end up with a dependency they thought they had eliminated—along with the added illusion of being protected.

That is the whole meaning of “is not enough.” Linux is a prerequisite, not a solution. The solution lies in what we do with the freedom it makes possible: the expertise we maintain, the layers we truly control, and the security we take responsibility for rather than delegating.