Articulation of export control regulations (FR/EU/USA/CH)

Open and controlled: Open Source put to the test by export control in 2026

Available translation: Français

Open Source and export control have never stopped crossing paths. In 2026, the question is critical: open AI, post-quantum encryption, a now codified Chinese regime, and an American framework on AI models being called into question.

This post offers an overall reading of the three major US / EU / China dynamics (all of them rooted in the Wassenaar Arrangement), recalls the historical interplay with free software licences, and draws operational lessons for Open Source users, vendors and communities.

Used massively across the world, Open Source software finds itself on the front line every time the legislator turns to digital regulation: cybersecurity, artificial intelligence, sovereignty, interoperability. Each time, it stands out as the natural answer because it intrinsically meets the goals being pursued: transparency and auditability, mutualisation of investment and compliance costs, free competition and interoperability. Conversely, this centrality exposes Open Source to a set of regimes that were not designed with the distributed nature of software production in mind. This generates a lack of harmonisation whose effects we recently documented for the three European regulations applicable to AI.

Export control -​- first and foremost the American EAR and ITAR regimes -​- is arguably the regime most historically at odds with the Open Source movement: it directly intersects with the sovereignty issues of states and regional blocs by aiming to prevent certain technologies from leaving them. In the current context of instability and protectionist surges, these regimes have evolved significantly for several concurrent reasons: reconfiguration of the American framework on AI models, staged entry into force of the European Cyber Resilience Act, Chinese codification of dual-use in December 2024 (followed in April 2026 by two decrees strengthening the Chinese extraterritorial arsenal). Practice itself is also evolving: code production assisted by generative AI (largely carried out on American servers, on the basis of American or Chinese models) is becoming the norm, and is shaking up the classical legal categories of export control.

In brief

These regimes apply to so-called dual-use items, that is “products, including software and technology, which can be used for both civil and military purposes” (Article 2 of Regulation (EU) 2021/821). The European reference list contains ten categories numbered 0 to 9, covering nuclear matters, special materials, electronics, computers, telecommunications, sensors, navigation, the maritime field and aerospace. For Open Source, three areas concentrate most of the questions: encryption (category 5 part 2 “information security”); space (category 9 “launchers, satellites, propulsion systems”, now at the heart of New Space strategies); and more recently artificial intelligence and high-performance computing (categories 3 and 4, extended to advanced semiconductors, accelerators and post-quantum cryptography).

Justified on security grounds, these regimes are particularly intrusive and may even apply beyond the borders of their country of origin. The American and Chinese systems are thus said to be extraterritorial: they may apply to goods produced outside the United States or China where certain conditions are met (use of imported tools, integration of components, contributor nationality, etc.). Compliance therefore does not consist in satisfying a single national regime in isolation, but in articulating several regimes depending on the situation and the countries concerned.

This post is intended for manufacturers, vendors, maintainers and managers facing these questions, and offers an overall reading. It builds on earlier work (see in particular the 2015 analysis on the export of free software encryption tools in the American model (in French)) and complements recent analyses on the interplay between European regulations and the Open Source exception. It does not claim to be exhaustive but rather invites discussion and collective improvement; to that end, the sources of the accompanying decision-tree diagram are shared under CC BY-SA 4.0.

Open Source and export control: a conflicting coexistence

Open Source embodies a logic of unrestricted sharing (copyleft being just one variant of it) that proceeds from an individual and proactive step: the application of an Open Source licence. Export control logic, by contrast, embodies a state’s will to limit the circulation of certain technologies, towards certain countries or persons, without taking into account the will of stakeholders (or even against their will). The opposition is head-on.

The articulation of the two regimes is, in fact, the result of a political and judicial battle waged in the United States from the 1990s onwards, whose main features are worth recalling:

  • From a political perspective, two episodes are emblematic. Philip Zimmermann, in 1995, had MIT Press publish the source code of PGP in book form (and as such protected by the First Amendment, hence not subject to the ITAR export restrictions then applicable to strong encryption). Likewise, Adam Back boarded a plane wearing a t-shirt printed with an implementation of the RSA algorithm and the inscription “WARNING: this shirt is classified as a munition and may not be exported from the United States, or shown to a foreign national“.
  • From a judicial perspective, the cases Bernstein v. U.S. Department of Justice (1999) and Junger v. Daley (2000) led American federal courts to recognise cryptographic source code as a form of expression protected by the First Amendment, forcing the Department of Commerce to introduce, from 2000 onwards, a License Exception TSU for published encryption code. This doctrine -​- judicial before becoming regulatory -​- is what allows OpenSSL, GnuPG or Let’s Encrypt to exist and to be distributed without prior authorisation today.

Two more recent episodes have served as reminders of the underlying political and economic stakes:

  • In May 2019, the Bureau of Industry and Security (BIS) added Huawei and sixty-eight non-American affiliates to the Entity List, prohibiting US companies from supplying them with any US-origin technology without a licence. The immediate practical effect was Google’s withdrawal of official support for Android Mobile Services on new Huawei devices. While the decision did not concern the Open Source layer (today used in Huawei’s mobile operating system), the loss of Google support clearly undermined the manufacturer’s dominance.
  • In October 2024, eleven Russian developers were removed from the Linux kernel MAINTAINERS file via a patch by Greg Kroah-Hartman, confirmed by Linus Torvalds and later commented on by the Linux Foundation in a note titled “Navigating Global Regulations and Open Source: US OFAC Sanctions”. Export law here came to limit the acceptability of individual commits.

Discover our “Software supply chain transparency” support offering

The three major export-control dynamics affecting Open Source

Looking at the regulations applicable in the three major geographic blocs (United States, European Union and China) helps -​- without claiming to be exhaustive -​- to understand how these regimes work together in practice.

United States: a solid publicly available exception, but a grey area on AI

The American Export Administration Regulations (EAR) regime rests, for software and technology, on a central exception: any technology or software “already in the public domain” or “available in usable or operable form to the general public in any country” falls outside the scope of the EAR. The License Exception TSU, specific to published cryptographic code, adds a notification obligation to the BIS (without requiring a formal agreement from the latter).

Under the EAR, the notion of “public domain” does not refer to the public domain in copyright terms. Rather, it designates technologies or software that are freely accessible to the public, without access or distribution restrictions, and available in directly usable form. In practice, this broadly covers software released as Open Source -​- provided the code is genuinely published openly (e.g. on a freely accessible repository), complete and operable, with no prior access controls. This carve-out, however, only applies to the version actually made public: private branches, restricted-access repositories or incomplete versions remain subject to the EAR.

Combined with the de minimis rule (which sets, depending on the destination country, the threshold -​- 0%, 10% or even 25% -​- beyond which a foreign product containing US content triggers the application of US extraterritorial law), it allows the worldwide circulation of OpenSSL, of most encryption libraries and, now, of a significant share of open-weight AI models.

The second tier of the regime is the Foreign Direct Product Rule (FDPR, § 734.9), which extends US jurisdiction to products manufactured abroad using American technology. Of note, the Biden administration published in January 2025 a rule dedicated to AI. The Framework for Artificial Intelligence Diffusion extends EAR obligations to certain closed-weight AI model weights, along with an AI-specific FDPR variant that explicitly excludes published open-weight models, on the well-known model of the Open Source exception. However, this scheme was “rescinded” (i.e. rendered inapplicable) in May 2025; the regime therefore exists on paper but its application is suspended and could be reactivated by a simple policy statement. On the broader topic of regulating open AI models, see in particular our dedicated post.

European Union and France: a stable but two-tier architecture

In Europe, the regime controlling dual-use goods and technology is set out in Regulation (EU) 2021/821 of 20 May 2021. The General Software Note (Annex 1, paragraph b) provides for an exception for software “in the public domain”, understood according to criteria close to the American ones: effective public dissemination, absence of usage restrictions, accessibility to a wide audience without specific charges. In line with the times, the Annexes have been updated to extend to advanced semiconductors, certain AI items and post-quantum cryptanalysis.

The Regulation contains a so-called “catch-all” Article 4, allowing the control of unlisted items where a national authority becomes aware of an end-use for military purposes. In the same spirit, an Article 5 was introduced in 2021 to extend to cyber-surveillance items that may be used to violate human rights. Their activation is left to the discretion of national authorities.

French law combines, at its level, two complementary regimes:

  • The first is the national implementation of the European Regulation: France can add items to a complementary national list under Article 9 of the Regulation (today used only for quantum technologies);
  • The second (based on Article 30 of the LCEN) pre-dates the Regulation and adds specific constraints on encryption software. The same encryption software may therefore simultaneously fall within the European dual-use regime and the French cryptology regime (where it includes cryptographic functions), each regime carrying its own declaration or authorisation obligations. Lastly, a “general public” qualification (Annex II point 3) eases the formalities under three cumulative conditions: distribution by retail sale without restrictions; publicly advertised price; user installation without substantial supplier assistance. Prima facie incompatible with Open Source software, this derogatory regime is also subject to the discretion of ANSSI (it remains to be seen whether ANSSI’s recent pro-Open Source strategy, which notably promotes open by default, will change the trend).

China: the absence of an exception as a deliberate choice

The Chinese regime is the most concerning at present: the 2020 Export Control Law (CECL) laid down a general framework, supplemented by the Regulations on Export Control of Dual-Use Items adopted on 19 October 2024 and entering into force on 1 December 2024. Unlike the American and European regimes, neither of these texts mentions any notion equivalent to “publicly available”, “public domain” or “open source”. This absence is all the more concerning because:

  • The extraterritorial reach of Article 49 of the 2024 Regulations allows the Ministry of Commerce (MOFCOM) to control items manufactured outside China but containing components of Chinese origin, or produced using Chinese-origin technology. The principle is not quantified -​- unlike the American regime -​- but appears to be governed by thresholds defined through sector-specific announcements (such as the 50% rule for rare earths).
  • The Catalogue of technologies prohibited or restricted for export (updated in July 2025) includes areas directly sensitive for Open Source: AI and machine learning, advanced and post-quantum cryptography, drone navigation algorithms, gene-sequencing software.

The 2024 and 2025 announcements regarding rare earths confirm a pattern of discretionary application that is hard to anticipate. For an Open Source project whose community includes contributors from third-country jurisdictions, as well as for any reuser of these projects, this is a real sword of Damocles.

Two recent State Council decrees, immediately applicable and adopted in reaction to American and European extraterritorial measures, demonstrate that this regulatory instrument is becoming central: Regulations on the Security of Industrial and Supply Chains (7 April 2026) and Regulations on Countering Foreign Improper Extraterritorial Jurisdiction (13 April 2026).

A decision tree to find your bearings

The diagram accompanying this post takes up and generalises the decision tree that inno³ produced as part of a client study carried out in a specific sector context. It situates the various rules concerning the export of French technology outside the European framework by articulating the main export-control laws likely to apply. As a reminder, the regimes are cumulative:

[Image to be added -​- see French source]

(Access the source file or an HD version via the dedicated git repo. Feel free to contribute directly by submitting changes via the repo or via inno3.fr.)

Lessons, recommendations and open questions

Mastering the software supply chain -​- let’s call it know your supply chain, by analogy with banking law’s know your customer -​- is no longer just a matter of free-licence compliance or sound cybersecurity practice; in 2026, it is also a discipline of extraterritorial law. Several lessons stand out:

  • The first is documentary: the Software Bill of Materials (SBOM), now mandatory under the CRA, is the pivotal instrument of mastered export-control compliance. It can therefore be considered a multi-purpose asset: cybersecurity, licence compliance, export due diligence. See also our analyses on the CRA and Open Source, in particular the CRA guide co-authored with CNLL.
  • The second concerns governance: the Contributor License Agreement (CLA) and Developer Certificate of Origin (DCO) mechanisms were designed to secure the chain of copyright ownership. They can be enhanced with a clause declaring the contributor’s origin and residence, together with a commitment to flag any personal status that may trigger an extraterritorial regime (sanctions, export control). This approach -​- close to what the Linux Foundation has begun to formalise in its compliance guidelines -​- applies just as much to infrastructure projects as to AI initiatives. Such an evolution must not disproportionately burden community projects: a simple declarative statement, integrated into the DCO, suffices in most cases and does not require maintainers to perform active verification.
  • The third concerns strategy. Publishing a cryptographic component, a dataset or model weights does not fulfil the same goal depending on whether one seeks scientific recognition, community adoption or commercial diffusion. The choice of licence, the documentation of context (threat models, use cases, limitations) and the publication architecture (main repository, mirrors) directly affect the “publicly available” qualification under the EAR and the “in the public domain” qualification under the General Software Note of the European Regulation. Open Source strategies thus become increasingly central to the development strategies of large organisations -​- and even to geopolitical balances -​- openness emerging as a lever for internationalisation and standardisation.
  • The fourth is forward-looking. Several questions remain open and worth flagging as such, in particular: the future of the American framework on AI models, the issue of generative AI used as a code-production tool (does it bring such code within the scope of these extraterritorial laws?), and the question of how the Chinese regime is applied (see also this post).

For a better grasp of Open Source and regulatory issues, follow our “Open Source and Cybersecurity” course.