Non-Standard Cryptography¶
The EAR used to require an email notification for publication of many types of encryption software or technology, including when published as part of an open source project. This requirement was changed in 2021. The email notification requirement now applies only to publicly available encryption software that implements a “non-standard cryptography”. [1] “Non-standard cryptography” is defined by the EAR as:
… any implementation of ‘cryptography’ involving the incorporation or use of proprietary or unpublished cryptographic functionality, including encryption algorithms or protocols that have not been adopted or approved by a duly recognized international standards body (e.g., IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA, and GSMA) and have not otherwise been published. [2]
Among other subject areas, software developers focus on encryption, which is of primary importance in the EAR. The EAR regulates exports of certain encryption software and technology. The definition of “encryption software” is very broad and can include software that merely activates or enables encryption features in another software or hardware product. [3] For software implementations of standard encryption functionality, including encryption hardware when represented in software design files, the most common ECCN classification is 5D002. If encryption software is “subject to” the EAR, then in order to export it anywhere except to Canada, one would need to first confirm that an exception applies, or request and obtain a license from BIS to permit the export.
However, before considering whether an exception or export license is necessary, the first question should be: is the encryption software “subject to” the EAR at all?
Encryption source code classified under ECCN 5D002 is not subject to the EAR if both (1) it is “publicly available,” and (2) either implements a standard, publicly available cryptography, or implements a non-standard cryptography and an email notification has been sent for it to the addresses listed in that section. [4]
For the first part of the test, the meaning of “publicly available” refers to the EAR’s definition of “published,” which includes public dissemination by posting on the Internet on sites available to the public. [5] Given this, the first part of the test should be met for all fully-public open source software projects: if the project’s source code is openly available on the Internet, then it should be considered “published” and therefore “publicly available.”
The second part of the test requires a determination of whether the publicly available encryption technology implements non-standard cryptography. Implementing non-standard cryptography, may require that an email be sent to two specified email addresses, one at BIS and the other at the US National Security Agency (NSA). The email should include the URL of the publicly available code (or a copy of the code itself). An updated notification should be sent later if the previously provided URL or copy has changed. [6]
Finally, after the two-part test is satisfied, then its corresponding object code counterpart is also not subject to the EAR. [7]
It is rare to find non-standard cryptography in an open source software project as it will be published and therefore will no longer meet the definition of non-standard cryptography. [8] Anyone using such a form of cryptography should consult a legal advisor on how to proceed.
At The Linux Foundation, the source code for all of our projects, including encryption software, is publicly available. In most if not all cases, it is standard cryptography, and we have additionally provided email notices as described above for many of our projects. We also make copies of these email notices publicly available for viewing on the LF’s website. [9] As a result, The Linux Foundation’s project source code and corresponding object code are not subject to EAR encryption restrictions.
Please keep in mind that this applies only to the open source project itself. Downstream redistributors of modified project code, or products derived from it, where the source code is not publicly available would still need to evaluate their own compliance with the EAR (just as with any other software that they export).
Footnotes
