Note: This document is for informational purposes only and is not intended as legal advice. If you wish to develop and distribute cryptographic software, particularly for commercial sale or distribution, then you should consult an attorney with expertise in the particular laws and regulations that apply in your jurisdiction.
This document discusses the proposed changes released on December 17, 1999, by the U.S. Department of Commerce [Commerce] in the document "Draft II Encryption Export Regulations" [DraftII]. The changes need to be read in relation to the existing Export Administration Regulations [EAR] administered by the Bureau of Export Administration [BXA], and this document assumes that you have a basic knowledge of how the existing regulations are structured. For those unfamilar with the details of U.S. encryption export control I've provided an overview to the existing regulations in a separate document, "Overview of U.S. Encryption Export Regulations (1999)".
An "encryption component" is defined to be "[any] encryption commodity or software (except source code), including encryption chips, integrated circuits, application specific encryption toolkits, or executable or linkable modules which alone are incapable of performing complete cryptographic functions, and is designed or intended for use in or the production of another encryption item." The grammar of this sentence is somewhat unclear due to ambiguity over where the clause "including encryption chips ..." ends. I presume the intended meaning is that an "encryption component" is "[any] encryption commodity or software (except source code) [which] is designed or intended for use in or the production of another encryption item", with examples of "encryption components" being given as "encryption chips, integrated circuits, application specific encryption toolkits, or executable or linkable modules which alone are incapable of performing complete cryptographic functions". (In other words, the correct reading of the definition is that obtained by replacing "and is designed ..." by "which is designed ...".)
The term "encryption component" is referenced extensively in the proposed changes to 740.17 and 742.15, as well as in Note 1 to Category 5, Part 2 of the Commerce Control List.
An "open cryptographic interface" is defined to be "[a] mechanism which is designed to allow a customer or other party to insert cryptographic functionality without the intervention, help or assistance of the manufacturer or its agents, e.g., manufacturer's signing of cryptographic code or proprietary interfaces." The definition that goes on to say that "If the programmatic interface to the cryptographic hardware or object code software has a fixed set of cryptographic algorithms, key lengths or key exchange management systems that cannot be changed, it will not be considered an "open" cryptographic interface." An open cryptographic interface is also distinguished from a "general application programming interface", where such interfaces are defined as "those that accept either a cryptographic or non-cryptographic interface but do not themselves maintain any cryptographic functionality".
This new definition clarifies an ambiguity in the existing regulations with regard to applications that implement an interface to encryption functionality, but do not themselves contain such functionality. Note that the new definition provides three ways in which an application can escape being classified as having an "open cryptographic interface": the interface can be general-purpose in nature, can implement only a fixed type of encryption functionality, or can control the type of functionality callable through the interface, for example, by requiring the add-on encryption modules be digitally signed by the application's developer (as done by Microsoft in the CryptoAPI scheme). However only the first of these ways applies to applications distributed as source code.
The simplest and most straightforward way for the U.S. government to
relax controls on open source encryption software would have been to revise
734.3 and 734.7 to treat publicly available encryption software and technology
in the same manner as other publicly available software and technology.
However the proposed changes to the EAR do not do this. Instead the changes
create a new class of "unrestricted encryption source code" which is released
from EI ("Encryption Item") controls and may be exported and reexported
under the TSU ("Technology and Software - Unrestricted") license exception.
More specifically, the proposed language for 740.13(e) allows the TSU license
exception to be used for "[encryption] source code controlled under
5D002 which would be considered publicly available under Section 734.3(b)(3)
and which is not subject to an express agreement for the payment of a licensing
fee or royalty for further commercial production or sale of any product
developed from the source code" (740.13(e)(1)). Note that open source software
meets these criteria, but that software in source form available under
other licenses may not; for example, software released under the Sun Community
Source License (SCSL) does not meet these criteria, because the SCSL requires
payment of royalties for commercial derivative works.
The proposed new language for 740.13(e)(1) requires that those wishing to export encryption source code of this type must first submit written notification to the Bureau of Export Administration and provide either the "Internet address (e.g., URL)" of where the software can found, or a copy of the source code itself. However the EAR do not require such software to be reviewed or approved by BXA, either at the time of original export or any time thereafter; the only requirement is to provide written notification beforehand. The proposed changes to the EAR go on to require (in 740.13(e)(2)) that you "not knowingly export or reexport" the source code (or products developed with it) to the "T7" nations accused by the U.S. of sponsoring international terrorism (Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria), but then limit the effect of this prohibition (in 740.13(e)(3)) by stating that it does not apply to "[posting] of the source code on the Internet (e.g. FTP or World Wide Web) where source code may be downloaded by anyone".
Based on the proposed changes to 740.13, the following activities would appear to be permitted for U.S.-based developers and others subject to U.S. jurisdiction:
However note that the proposed changes to 740.13 do not (in and of themselves) appear to permit any of the following activities:
Another issue of potential concern to open source developers is the EAR prohibition regarding "technical assistance", in 15 CFR 744, "Control Policy: End-User and End-Use Based" [EAR744]. In particular, 744.9, "Restrictions on Technical Assistance by U.S. Persons with Respect to Encryption Items", states that "No U.S. person may, without a license from BXA, provide technical assistance (including training) to foreign persons with the intent to aid a foreign person in the development or manufacture outside the United States of encryption commodities and software that, if of United States origin, would be controlled for 'EI' reasons under ECCN 5A002 or 5D002." This would seem to restrict the ability of U.S. open source developers to provide development or other services to non-U.S. developers working on open source encryption software, even when the software in question was developed outside the U.S.
No changes were proposed to 744.9. However in the existing regulations 744.9(a) goes on to say that "this prohibition does not apply if the U.S. person providing the assistance has a license or is otherwise entitled to export the encryption commodities and software in question to the foreign person(s) receiving the assistance." In the case of open source encryption software in source code form, the proposed changes in 740.13 mean that a U.S. developer is in fact "entitled to export the encryption ... software in question" (except for the specific case of "foreign persons" in the "T7" nations), and therefore the prohibition on "technical assistance" does not apply.
Based on the proposed changes to 740.13 in combination with 744.9 in the existing regulations, it would appear that U.S.-based developers and others subject to U.S. jurisdiction are permitted to provide technical assistance relating to the creation of open source software in source code form, whether that software is of U.S. origin or not, as long as the "foreign person" being assisted is not a national of the "T7" nations. Of course if the technical assistance being provided is provided in the form of a public web page or a posting to a public newsgroup then it is impossible for the developer to ensure that "T7" foreign nationals do not take advantage of the assistance.
Here we can perhaps assume the existence of a "safe harbor" similar to that provided by the proposed language in 740.13(e)(3). Given that posting open source encryption software in source code form to a public Internet site (where it can be "downloaded by anyone") in and of itself does not constitute "knowingly export[ing] or reexport[ing] source code ... to Cuba, Iran, Iraq, Libya, North Korea, Sudan, or Syria" and is therefore permitted, we can perhaps reasonably assume that providing technical assistance relating to such source code in a public Internet forum is also permitted; the only reasonable exception to this permission would seem to be when the assistance is directed specifically to a "T7" foreign national, for example, in response to a question from someone readily identifiable as such a national. (For example, if the questioner's email address has a domain name associated with one of the "T7" countries.)
A remaining ambiguity is associated with providing "technical assistance" relating to build problems and other questions relating to creation of binaries from open source encryption software in source code form; after all, 740.13(e) gives permission only to export encryption software in source code form, it does not in and of itself provide permission to export binaries generated from that source code. And if a U.S. developer does not have permission to export a binary executable implementing encryption functionality, then (by 744.9(a)) they do not have permission to provide technical assistance to "aid a foreign person in the development or manufacture outside the U.S." of such a binary executable. I discuss this issue in more detail below.
As noted above, the proposed new language in 740.13(e) allows essentially unrestricted export or reexport of open source software in source form; however 740.13(e) does not in and of itself address the issue of export or reexport of open source software in binary form. (This is not an issue for open source software in general; publicly available software in general, which includes open source software in general, is not subject to regulation under the EAR, as specified in 734.3, and the relevant sections of the EAR do not make a distinction between publicly available software in source form and publicly available software in binary form.)
We must therefore look elsewhere in the EAR and proposed changes to it in order to determine what provisions apply to binaries created from open source software in source form. The proposed changes create a fairly complicated scheme classifying encryption software into various classes and applying different regulations to each class; most classes can be exported using the ENC license exception, as described in 740.17, "Encryption Commodities and Software (ENC)", and 742.15, "Encryption Items". The different classes vary based on the strength of the encryption functionality (56-bit symmetric key length, 64-bit symmetric key length, greater than 64-bit symmetric key length, etc.) and on whether the software is considered "retail" encryption software, "mass market" encryption software, or otherwise. For our purposes we care only about "full strength" encryption software, which may be considered either "retail" software or not.
"Retail" encryption software is discussed in the proposed language for 740.17(a)(3), "Retail encryption commodities and software products", and 742.15(b)(3), "Encryption commodities and software eligible for classification under ECCNs 5A002 and 5D002". Treating encryption software as having "retail" status requires formal review and approval by the Bureau of Export Administration; once approved for "retail" status such software remains classified under 5D002, but may be exported and reexported under the ENC license exception to any end-user in any country (excluding the "T7" nations), regardless of the strength (e.g., key length) of the included encryption functionality. If the software is made available via "free or anonymous download" then you are not required to make any reports to BXA concerning who downloaded the software (see 740.17(g)).
In order to be given "retail" status software must meet a set of criteria of which the most important (for our purposes) are that the encryption software must be "specifically designed for individual consumer use" and that "the cryptographic functionality cannot be easily changed by the user". (This latter criterion implies that "retail" software must be distributed in binary form.) 740.17(a)(3)(iv) gives as examples of retail software "general purpose operating systems and their associated user-interface client software", "programmable database management systems and associated application servers", "low-end servers and application-specific servers (including client-server applications, e.g., Secure Socket Layers (SSL)-based applications)", and (last but not least) "encryption products distributed without charge or through free or anonymous downloads".
"Retail" status is thus potentially available to binary versions of a wide range of open source software that might have encryption functionality: Linux or *BSD kernels, desktop software and window managers, web browsers and web servers, email and news clients, mail transfer agents, news servers, databases, editors, file encryption utilities, and so on. However as noted obtaining such status requires submitting a formal "classification request" to BXA, as described in 740.17(e), and the BXA may either not approve such request or may delay its response indefinitely. Also, "retail" status is not available for products implementing an open cryptographic interface as defined in 772 (see 740.17(f)), so binaries of open source software products would presumably qualify only if they are linked in such a way that the user cannot easily substitute different encryption functionality. (However this does not affect the exportability of source code for open source software implementing an open cryptographic interface; see the final sentence of the proposed 740.17(f)).
Other full-strength encryption software (besides "retail" software) is discussed in 740.17(a)(2), "Encryption commodities and software", and 742.15(b)(2), "Encryption commodities and software eligible for classification under ECCNs 5A002 and 5D002". Such software may be exported or reexported to "any individual, commercial firm, or other non-government end user" (again excluding end users in the "T7" nations, per 740.17(b) and 742.15(b)(2)). The only significant difference from "retail" software appears to be the prohibition against export to "government end users", as defined in Part 772. The proposed language for 734.2(9)(ii) appears to indicate that for software downloaded from the Internet the prohibition against distribution to "government end users" can be met by rejecting access from systems having "government domain names". (".gov" and ".mil", the domain names associated with the U.S. government and military respectively, are given as examples of such names, though I doubt the intent of the EAR is to prevent access to encryption software by U.S. government and military end users.)
[General purpose encryption toolkits, as discussed in 742.15(a)(5) -- does this section actually matter for open source encryption toolkits? Seems to imply that binaries for such toolkits can be exported under license exception ENC to any non-government end users after BXA review and classification (742.15(a)(5)(iv)), which is essentially the same as the treatment for full-strength non-retail software. However there are some additional reporting requirements for "foreign product[s] developed for commercial sale using ... general purpose toolkits", though it is not clear that this would actually be an issue in practice.]
[What about U.S. use of non-U.S. encryption source code followed by reexport? The "no de minimis" rule would seem to still apply, but export of source code containing mixed U.S./non-U.S. code would seem to present no problem. Binaries are another issue, as discussed above.]