Encryption, Open Source and Export Control

This article explores a simple, cheap and effective way to reduce your organisation’s compliance risk when dealing with encryption software.

Snowden’s revelations confirmed that the “Five Eyes” powers engage in global dragnet surveillance. He also confirmed that encryption, if done correctly, is highly effective at securing our electronic communications.

With the sustained media focus, public awareness of encryption is increasing and there has been a surge in the number of people who want to encrypt their communications. The market for encryption products is growing and more developers are building software that integrates encryption. This raises important questions about the legal frameworks that regulate the distribution of encryption technology.

The United States export control regulations are the most stringent and far reaching statutes that apply to encryption technology. The Export Administration Regulations (EAR) are comprehensive, covering all US-origin hardware, software (including source code) and technology. They apply to a broad range of technologies, including integrated circuits, aircraft parts, and encryption (which is only a very small part).

The EAR purports to apply to all people, anywhere on earth. The EAR considers anything that was developed in the US, incorporates technology developed in the US, or is transshipped through the US to be “US-origin.” So, if a South African national at a conference in Berlin obtains US-origin encryption software that is restricted for export and she then sends that software to her friend in Zimbabwe, she has violated the US export control regulations, and could face fines and imprisonment if extradited to the US (or if she happens to enter US territory for some other reason).

If you’re in the US or a US citizen, permanent resident or otherwise have significant ties to the US, compliance with the EAR is pretty important; violations can come with criminal penalties that can reach $1,000,000 and 20 years in prison. Although I am unaware of any criminal enforcement actions between 2009 and 2012 for the export of encryption software alone, I wouldn’t recommend testing the enforcement agencies’ resolve as there were 85 criminal convictions for export violations for the years 2010-2012. In addition, the recent Wind River Systems settlement raises the prospect of increased enforcement over encryption exports.

To say the EAR is complex is like saying that discovering the Higgs Boson took a little bit of math. As far as understanding how the EAR applies to encryption technology, there is a thicket of cross- and self-referencing definitions contained in the EAR, most notably software controlled by export control classification numbers (ECCNs): 5D002 and 5A002. Basically, this covers software that encrypts information for the purpose of securing data at rest or data in transit, and does not qualify as “mass market” software, under Note 3 to Category 5, Part 2 of the Commerce Control List. The test to determine whether software qualifies as mass market is fact specific and I’m not going to address that here.

There is, however, an easy way to comply with the restrictions on export of encryption technology imposed by the EAR and ensure that users of your encryption products can verify the relative security of your product—make the entire source code of your product publicly available.

Under Section 740.13(e) of License Exception TSU, publicly available encryption source code may be exported without a license, so long as the notification requirement is met (and updated accordingly). This exception is not limited only to those who distribute their software under an open-source license for free, it is also applies to code that is licensed for a fee or royalty. Hence, making your source code publicly available has the double benefit of simplifying your compliance with the EAR and making your software safer and more trustworthy, since anyone can examine it to ensure there are no mistakes or backdoors.

If you happen to already be working on an open source software project that uses encryption software, or if you want to add encryption functionality to your open source project, then compliance with US export regulations is just an email away.

If you happen to be working with closed source software for sale, then the decision to publicly release your source code is understandably more complicated. But choosing to do so will likely decrease your cost of compliance with the EAR and could increase your credibility with influencers and enterprise customers, both of which will contribute directly to your bottom line.

Disclaimer – Thoughtworks does not provide legal services. This article is intended to provide information that is of general public interest only and is not legal advice with regard to any specific circumstances. There is no attorney client privilege created as a result of you reading this and no communication from you to Thoughtworks will create an attorney-client relationship. You should consult a licensed attorney in your locale with experience in these matters if you need legal representation. Thoughtworks has no duties to you, including duties of loyalty, care or confidentiality; and nothing you communicate to Thoughtworks will be kept confidential, unless we agree to enter into a written confidentiality agreement, signed by authorized representatives for each of us. In addition, the opinions contained herein are those of the author and do not necessarily reflect the opinions of Thoughtworks.