Publicly available encryption source code, and the object code compiled from it, is in most cases not subject to the Export Administration Regulations (EAR) at all. Since 2021, BIS has to be notified only when the code implements non-standard cryptography. Much of the world's cryptography is open source, and the EAR recognise this. The boundary is precise, though, and products built on open-source code are classified in their own right.
The rule for open source encryption export
Under § 734.3(b)(3) and § 742.15(b) of the EAR, encryption source code that is publicly available, and the object code compiled from it, is not subject to the EAR, provided the notification requirement (below) is met where it applies.
What "publicly available" means
The code must be posted where the public can access it without restriction, such as an open repository or website. Any fee can cover only reproduction and distribution costs. A private repository, a customer portal or code shared under non-disclosure does not count.
When do you need to notify BIS?
Since a 2021 rule, notification to BIS and the ENC Encryption Request Coordinator is required only when the publicly available code implements "non-standard cryptography". Code implementing standard algorithms (for example AES, RSA or TLS libraries) needs no notification. Notifications are made by email before or at the time the code is made available.
Standard and non-standard cryptography
This distinction decides whether notification is needed. "Non-standard cryptography" means cryptography involving proprietary or unpublished algorithms, including those not adopted or approved by a duly recognised international standards body. Widely used published algorithms and protocols, the ones implemented by mainstream open-source libraries, are standard. A project that invents or customises a cipher, or uses an unpublished one, should assume notification is required.
What stays controlled
Commercial products that include open-source encryption are classified in their own right: typically 5D992.c or 5A992.c if mass market, or 5D002 or 5A002 otherwise. The product does not inherit the library's status. The steps are in encryption export controls explained, and for hosted software see cloud computing and encryption.
Private forks and modifications that have not been made public stay controlled. So does technology, for example design know-how shared privately: publishing different code does not release it.
Embargoes and prohibited parties still apply. Knowingly providing code to sanctioned persons can raise separate issues under OFAC programmes.
Worked examples
| Example | Result |
|---|---|
| An open-source TLS library on a public repository | Not subject to the EAR; standard cryptography, so no notification |
| A new cipher published by a researcher on a public repository | Not subject to the EAR once notified, because it is non-standard |
| A commercial app using that TLS library, sold in app stores | Classified, typically 5D992.c (see the mass-market release) |
| An enterprise appliance built on open-source cryptography, sold under negotiated contracts | Often 5A002.a, exported under License Exception ENC |
Steps for software companies
- Inventory the open-source cryptography in your products.
- Classify each product as well as the libraries in it.
- If you publish your own crypto code, decide whether it is standard or non-standard and notify where required.
- Keep records of what was published, where and when.
The encryption classification FAQ covers the product questions that follow.
Common mistakes
Two errors follow from the sections above: treating a private repository as "publicly available", and assuming the commercial product inherits the library's status. Three more come up:
- forgetting that fixes and features kept private before release are not yet public;
- overlooking sanctions when distributing to specific users in embargoed countries (how to screen for sanctions);
- notifying for standard cryptography where no notification is needed (harmless, but unnecessary).
Frequently asked questions
Does a public release have to be free?
Code can be publicly available if any fee covers only reproduction and distribution.
Are compiled binaries covered?
The object code compiled from publicly available source code is treated the same way.
Open-source products in ECCN.help
For a commercial product that uses open-source encryption, the ECCN.help Classification Workflow walks the Category 5 Part 2 questions (exclusions, the Cryptography Note, filings) and records the answers.
ECCN.help provides research and assistance, not legal advice. Verify every result against the regulation.