Export Controls (EAR) on Open Source Software

Published , updated

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 tcllib, tclcurl etc. which are covered by these regulations by way of their including cryptographic functionality.

Export control in brief

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.

Export of software

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 tcllib whose modules include cryptographic functions (pki, aes etc.), TclCurl which includes SSL/TLS through the OpenSSL libraries, twapi which 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.

What constitutes software export

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.

Publicly available open source software

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 [email protected] and to [email protected].

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.

Notifying BIS

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: [email protected]
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

As per advice from the Open Source Initiative, you may send them a copy of the notification to the email address specified in that advice page.

Summary of steps

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).

More caveats

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.

References

You may find the following references useful for wading through the morass.