Technology and Digital Policy

I strongly support free software.

Users should be able to study, modify, share, audit, and control the software on which they depend.

These freedoms are particularly important when software is used by public institutions, critical infrastructure, scientific organisations, education, healthcare, industry, or democratic institutions.

Software freedom is not merely a technical preference.

It determines who ultimately controls a digital system.

Software developed primarily with public money should, as a general principle, be released as free software.

Public funding should create public digital assets.

A public institution should not finance the development of software and then become dependent on a private supplier for permission to inspect, modify, maintain, or reuse what it has already paid to create.

Code financed by taxpayers should normally remain available for:

• inspection;
• independent auditing;
• modification;
• redistribution;
• reuse by other public institutions;
• research;
• education;
• long-term maintenance.

Public investment should create software commons that accumulate over time rather than repeatedly financing incompatible proprietary solutions.

I support the principles embodied by the GNU General Public License and other strong copyleft licences.

Software freedom should not merely mean that source code can be inspected.

Users should retain the practical freedom to modify and redistribute software, including modified versions.

Copyleft provides an important mechanism for ensuring that improvements to shared software remain available to future users.

Intellectual-property rules should not be allowed to undermine these freedoms.

Where public software is intended to become shared infrastructure, strong copyleft licences should be seriously considered.

Public administrations should prefer free software by default.

The use of proprietary software should require a documented technical justification when an appropriate free alternative exists.

This preference should take into account more than immediate acquisition cost.

Public procurement should evaluate:

• source-code availability;
• auditability;
• interoperability;
• open standards;
• data portability;
• long-term maintenance;
• supplier independence;
• exit costs;
• security;
• documentation;
• migration capability.

A solution that is initially inexpensive but creates decades of dependence on one supplier may ultimately be far more costly.

Exceptions should remain possible where technically necessary, but proprietary software should be the justified exception rather than the automatic default.

Public institutions and critical systems should use open, documented, interoperable standards wherever possible.

Long-term access to data must not depend on a particular vendor, proprietary application, or undocumented file format.

Standards used by public institutions should be implementable independently.

Documents, scientific results, administrative records, and public information may need to remain readable for decades.

Their accessibility should therefore not depend on the commercial survival or business strategy of a particular software company.

Interoperability should be a fundamental digital policy objective.

Users should be able to communicate, exchange data, migrate systems, and change providers without unreasonable technical barriers.

Dominant digital platforms should not be permitted to use closed protocols or artificial incompatibilities solely to prevent users from leaving their ecosystems.

Where a digital service has become structurally important, public authorities should be able to require documented and usable interoperability mechanisms.

This may include:

• open APIs;
• open communication protocols;
• standardised data formats;
• data export;
• data import;
• third-party client support;
• migration interfaces.

Competition becomes substantially less meaningful when changing supplier requires abandoning data, workflows, communications, or entire technical ecosystems.

Users and organisations should retain effective control over their data.

Data portability should mean more than the ability to download an archive that cannot realistically be reused elsewhere.

Export formats should be documented, structured, complete, and suitable for migration to another compatible service.

Where technically feasible, users should also be able to transfer data directly between providers.

A user's own data should not become an instrument of vendor lock-in.

In critical sectors, minimum requirements for technological independence should be mandatory.

This is particularly important in areas such as:

• energy;
• healthcare;
• telecommunications;
• transport;
• defence;
• public administration;
• scientific infrastructure;
• finance;
• industrial control systems.

Critical systems should satisfy appropriate requirements concerning:

• documentation;
• data portability;
• open formats;
• interoperability;
• long-term maintenance;
• security auditing;
• migration capability;
• access to technical specifications.

Where proprietary software is unavoidable, mechanisms should exist to prevent complete dependence on a single supplier.

Depending on the system, this may include contractual source access, source-code escrow, complete technical documentation, independent maintenance rights, or other mechanisms allowing continuity if the original supplier disappears or withdraws support.

Critical infrastructure must remain maintainable even when commercial relationships change.

Vendor lock-in should be treated as a strategic risk.

Dependence can arise through:

• proprietary file formats;
• undocumented protocols;
• cloud APIs;
• licensing restrictions;
• hardware dependencies;
• identity systems;
• proprietary authentication mechanisms;
• unavailable source code;
• contractual restrictions.

Public and private organisations should evaluate these dependencies before adopting a system rather than discovering them only when migration becomes necessary.

The ability to leave a supplier is itself an important property of a technical system.

Free software policy should not be limited to public administrations.

Citizens, engineers, companies, schools, universities, managers, and industrial organisations should understand the consequences of technological dependency.

When purchasing or deploying software, they should be able to ask:

• Can the system be independently audited?
• Who controls its updates?
• Can the data be exported?
• Are the formats documented?
• Can another supplier maintain the system?
• What happens if the vendor disappears?
• Can security vulnerabilities be independently investigated?
• Can the system continue operating without the supplier?
• Can we migrate away without rebuilding everything?

The objective is not to prohibit proprietary software.

The objective is to ensure that users understand the dependency they accept when choosing it.

Europe should develop genuine technological sovereignty.

A continent of hundreds of millions of people should not depend almost entirely on foreign companies for operating systems, cloud infrastructure, office software, communication platforms, identity systems, and other critical digital services.

Technological sovereignty does not merely mean buying equivalent proprietary technology from a European company.

European ownership is not sufficient; European control and user freedom matter too.

A European supplier can create the same dependency as a foreign supplier if users cannot inspect, modify, migrate, or independently maintain its systems.

For this reason, technological sovereignty should favour free software, open standards, documented interfaces, interoperability, and distributed technical competence.

Strong encryption is essential for privacy, cybersecurity, industrial security, journalism, research, commerce, and democratic life.

I oppose mandatory cryptographic backdoors.

A deliberate weakness introduced for supposedly legitimate access remains a technical weakness.

It can potentially be discovered, reused, stolen, or exploited by actors for whom it was never intended.

Security should therefore rely on strong cryptography rather than exceptional access mechanisms.

The economic and technological power of the largest global technology companies should be limited where it creates excessive dependency or weakens democratic control.

Competition policy alone may not be sufficient.

Public policy should also promote:

• interoperability;
• data portability;
• open standards;
• decentralised technologies;
• free software;
• independent infrastructure;
• alternative service providers;
• the right to migrate.

A competitive market requires more than multiple company names if all users remain trapped inside incompatible technical ecosystems.

Some digital systems should be treated as infrastructure rather than products.

Public administrations should be able to jointly develop and maintain common software for recurring needs such as:

• authentication;
• document management;
• communication;
• secure file exchange;
• administrative workflows;
• public information systems;
• scientific computing;
• collaborative tools.

Such systems should be developed openly and made reusable across institutions.

Public-sector software should accumulate as shared infrastructure rather than being recreated repeatedly through isolated procurement contracts.

Security through obscurity is not a sufficient foundation for critical digital infrastructure.

Critical software should be designed so that independent experts can inspect, test, audit, and improve it.

Free software does not automatically guarantee security, but it makes independent verification technically possible.

Security policy should therefore promote:

• transparent development;
• reproducible builds;
• signed releases;
• independent audits;
• responsible vulnerability disclosure;
• documented supply chains;
• long-term security maintenance.

Digital sovereignty without technical competence and verifiable security would be largely symbolic.

I do not currently adopt a detailed political position on artificial intelligence.

The field is developing too rapidly for me to consider my present views stable enough to state them here as a settled political position.

The technology, its uses, its economic structure, and its social consequences are changing faster than a durable political position can reasonably be formed.

I prefer to revisit this question as the field becomes clearer rather than pretend to have a stable doctrine prematurely.