“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