Just the Facts – Exporting Encryption Algorithms

Open source developers may not realize it but in certain circumstances their work is subject to export regulation. When open source developers create an account on SourceForge.net they are required to agree to SF’s terms and conditions. Checking that innocuous little box to “opt-in,” they are acknowledging that they are aware and pledge to comply with Section 740.13(e) of the Export Administration Regulations (”EAR”) 15 C.F.R. Parts 730-772.
There are only three facts that you need to know about the above:

1. The fact that you have no idea what this is does not get you off the hook
2. See number 1
3. See number 2

The fact is the US government regulates the transfer of encryption technology to other countries. One of the big challenges for multi-source developers, who create products which mix open source with other types of software, is understanding whether there is encryption in their code. As software developers increasingly leverage open source and other components, it becomes more challenging for them to have intimate knowledge of what is in their code.
If it turns out you are using strong encryption, then you most likely are required to submit a notification or license application with the US Commerce Department. Strong encryption uses key lengths greater than 80 bits for symmetric algorithms, 1024 bits for asymmetric algorithms and 160 bits for elliptic curve. The requirements differ depending on the function of the product, the end user, the destination country, the encryption strength, and the intended use. If you are using weak encryption (defined in my October 13th blog, then you are OK. If you are between the limits of weak and strong, well then… make friends with a knowledgeable compliance professional.
Black Duck Software published an analysis that we performed looking at the encryption content in open source projects. We found that about 7% of open source projects contain encryption algorithms, however not all encryption is strictly controlled. We did find nearly 8,000 projects which could require a notification or license application to be filed before exporting. This includes some of the most popular open source projects.
Our message for multi-source developers is simply this: “Know Your Code.” If you want to learn more about complying with encryption export regulations, we have put together a guide to encryption export compliance for open source developers (and for developers using open source).
PS: Two more facts – two popular sites, SourceForge and Google Code, have language about export in their user T’s & C’s. See below:
SourceForge Terms of Use
You are aware that all postings of open source encryption code controlled under U.S. Export Control Classification Number (ECCN) 5D002 must be simultaneously reported by email to the U.S. government. You are responsible for submitting this email report to the U.S. government in accordance with procedures described in this document and Section 740.13(e) of the Export Administration Regulations (”EAR”) 15 C.F.R. Parts 730-772.
Google Code Additional Terms: By using Google Code (the “Service”), you agree to be bound by our Google Terms of Services located here.
5.2 You agree to use the Services only for purposes that are permitted by (a) the Terms and (b) any applicable law, regulation or generally accepted practices or guidelines in the relevant jurisdictions (including any laws regarding the export of data or software to and from the United States or other relevant countries).