This post is about US encryption controls on open source software and what programmers need to do to comply with those regulations.
I must start with a caveat because I know practically nothing about the subject! Treat it as one person's understanding of the matter, not legal advice. I am not a lawyer, don't play one on TV or even actually know a real lawyer. I am writing this as an aid to others writing open source software in the hope it will make them aware of the concerned regulations.
My experience with US export regulations are primarily with regard
to my Magicsplat Tcl/Tk for Windows
binary distribution. The distribution includes
which are covered by these regulations by way of their including
The US government places controls on export of a wide variety of materials and technologies. Obvious examples are nuclear technology, any type of chemicals, munitions etc. Perhaps less obviously, software is also an export-controlled item and subject to the Export Administration Regulations (EAR) which fall under the purview of the Bureau of Industry and Security (BIS).
Export controlled items are classified under an Export Control Classification Number (ECCN). The rules governing the export of the item depend on its classification and may range from requirement of an export license, to simple notification to the authorities via email, to exemption.
Whether a piece of software is export-controlled or not depends on its
classification, which is in turn based on its functionality. In particular,
in my case the inclusion of software with cryptographic functionality
placed it in ECCN
5D002.C.1, making it subject to export control.
Based on ECCN numbering,
this is broken down as
5 - Information security
D002 - Software
C.1 - Functions performing cryptography for data confidentiality with
key lengths greater than 56 bits.
This classification is required as the distribution include
modules include cryptographic functions (
which includes SSL/TLS through the OpenSSL libraries,
also includes SSL/TLS functionality.
There are a couple of important points to keep in mind.
The software does not need to implement cryptographic functions to be export-controlled through this category. Mere use of cryptographic functions suffices. For example, imagine you ship software in source form that contains no encryption code but calls on OpenSSL libraries already installed on the target system. This would also fall under the above classification.
If you use open source software as part of your product (open source or otherwise), or some other close software that already has an export license, you are not covered by that software's export license or license exemption. You must file your own.
Export regulations of software cover both source code as well object code. Moreover, you do not have to ship software on physical media for it to be classified as export. Placing it on a web site, or even checking it into a public source repository like Github, suffices for it to be subject to regulations.
The EAR special cases software that is publicly available and open source. These terms have specific meaning as defined in Section 734.3(b)(3) of the EAR. Thankfully, the regulations surrounding export of such software (both object code and source form) were greatly simplified in 2016.
This flowchart describes the process to be followed for meeting export control regulations for software. As outlined there, publicly available open source encryption software is excluded from controls thanks to the Technology and Software (TSU) License Exception after an email notification to the appropriate authorities.
In particular, Section 742.15(b) of the EAR states
(b) Publicly available encryption source code - (1) Scope and eligibility. Subject to the notification requirements of paragraph (b)(2) of this section, publicly available (see 734.3(b)(3) of the EAR) encryption source code classified under ECCN 5D002 is not subject to the EAR. Such source code is publicly available even if it is subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code.
The corresponding notification reads
(2) Notification requirement. You must notify BIS and the ENC Encryption Request Coordinator via email of the Internet location (e.g., URL or Internet address) of the publicly available encryption source code classified under ECCN 5D002 or provide each of them a copy of the publicly available encryption source code. If you update or modify the source code, you must also provide additional copies to each of them each time the cryptographic functionality of the source code is updated or modified. In addition, if you posted the source code on the Internet, you must notify BIS and the ENC Encryption Request Coordinator each time the Internet location is changed, but you are not required to notify them of updates or modifications made to the encryption source code at the previously notified location. In all instances, submit the notification or copy to firstname.lastname@example.org and to email@example.com.
You may note the above specifies source code. However, object code derived from such source code is also exempt via the NOTE to EAR Section 734.3(b)(3).
Publicly available encryption object code "software" classified under ECCN 5D002 is not subject to the EAR when the corresponding source code meets the criteria specified in 742.15(b) of the EAR.
So there you have it. In a nutshell, you have to notify BIS and keep them updated of any changes. Not too bad and vastly simpler than what it was before.
The email notification needs to include certain information. The notification I used for the Magicsplat distribution is shown below. It is based on a template used by Apache for their software.
Dear Sir/Madam, This message is a notification regarding the open source software package Magicsplat Tcl/Tk for Windows. Background information As background, Tcl is an open source interpretive programming language with similar functionality to Python, Ruby etc. Tk is a graphical programming library. More information about these is available at http://www.tcl.tk. The Magicsplat Tcl/Tk for Windows installation package is a compilation of the executables comprising the language and commonly used libraries for the Windows platform. Although the language runtime itself does not contain any code related to cryptography, the included libraries support functions such as communication over SSL/TLS. This submission is with regard to such functionality all of which is implemented by third parties as publicly available open source software. Notification Submission type: TSU under EAR 742.15(b) and 734.3(b)(3) Submitted by: firstname.lastname@example.org Submitted for: Ashok P. Nadkarni Point of contact: Ashok P. Nadkarni Product Name: Magicsplat Tcl/Tk for Windows (32-bit and 64-bit) Product download: https://sourceforge.net/projects/magicsplat/files/magicsplat-tcl/ ECCN: 5D002.C.1 Manufacturers and software components: (only listed for components related to cryptographic functions) - OpenSSL Project, openssl library, source code at https://www.openssl.org/source - Tcllib project, tcllib Tcl standard library, source code at http://core.tcl.tk/tcllib - Ashok P. Nadkarni, twapi Tcl Windows API library, source code at https://sourceforge.net/projects/twapi/ - Curl project, libcurl library, source code at https://github.com/curl/curl Ashok P. Nadkarni
The following then is the list of steps I went through for my distribution.
Check the ECCN page to appropriately self-classify your software.
Follow the flowchart as to the steps required for meeting regulatory requirements.
If you are lucky enough that only email notification is required, send email notifications as described above. In theory, you are supposed to do this before the software is downloadable, even from a repository.
Include appropriate verbage in your license and download page (I do not think EAR requires this, it's more of a courtesy to your users).
We are back to caveats again.
My experience is based on a sample size of one, with specific software components. Your situation may require software to be classified in a different category with different regulatory requirements. For example, crypto for authentication is distinguished from crypto for encryption even if the algorithms are the same. At a minimum, check the linked flowchart above for the steps to be followed.
This is written from a US perspective. Other countries may have their own restrictions on export, import, use and even just possession of cryptographic software. What happens if you write software in Ghana and commit to Github in the US? I don't have the foggiest.
Regulations change every few years or even if they remain, are moved to a different section. For example, the section numbers in the Apache pages are out of date. Email addresses used for notification have also changed. Anything stated in this blog, even if accurate by some miracle when written, may not be so in the future. Stay up to date.
Hope this saves someone some time.
You may find the following references useful for wading through the morass.
Presentation (PDF) on encryption export controls.
Another presentation on EAR from Morgan Lewis.
A paper (PDF) on exporting technology and software, particularly encryption.
Commentary on the 2016 update summarizing changes.
The Apache Software Foundation developers page related to the topic. Note that many of the EAR section numbers mentioned are outdated.
The Commerce Control List from BIS lists the ECCN categories.
The Encryption and EAR page at BIS which is specific to EAR as it relates to encryption software.
Flowchart covering regulation related to cryptographic software.
ECCN Category 5 Quick Reference summarizes ECCN Category 5 (Information Security).
Section 742.15(b) that covers the TSU exemption.
The FOSSology system includes a toolkit that will scan source code for export control issues.