21 October 1997: Link to related article, Access to U.S. Software and Other U.S. Technology by Foreign Nationals:" http://www.oikoumene.com/softwaccess_xprt.html

13 October 1997
Source: http://www.oikoumene.com/software-inetxport.html
Thanks to Sandy J. Wong <sandy@OIKOUMENE.COM>

See related Greguras article, "Systems-on-a-Chip: Intellectual Property and Licensing Issues:"
http://www.oikoumene.com/IPinICs.html

I. Introduction

 

The rapid growth of the Internet as a means of distribution of software has created a new set of export compliance issues and challenges. U.S. export control regulations, for the most part, have been designed to address "traditional" exports in which a software package is physically shipped to a foreign recipient on a CD-ROM, disk or other media. While most experienced exporters have implemented effective export compliance procedures for their physical shipments toforeign locations, many exporters are still struggling to implement compliance procedures for their Internet exports.

 

Both the Export Administration Regulations ("EAR") and the International Traffic in Arms Regulations ("ITAR") were amended to transfer export control jurisdiction over "encryption software" to the EAR In the December 30, 1996 Federal Register. This jurisdiction transfer clarified the U.S. government's existing interpretation of its former rules governing exports of encryption software and brought into focus Internet export compliance issues.

 

The most fundamental compliance question focuses on identifying which Internet activities are exports, and require export compliance procedures. The EAR establishes two different definitions of Internet "export," one for encryption software and another for non-encryption software. These two categories of software are addressed separately below since there are different regulatory rules for each category.

 

Please note that none of the following restrictions apply to exports to Canada of either category of software. Exports of software to Canada for use in Canada are not subject to any export controlrestrictions.

 

II. Encryption Software [top]

 

The Clinton Administration' s decision to transfer export control jurisdiction over encryption software from the ITAR to the EAR did not result in any meaningful relaxation of export controls on encryption. Instead, the transfer continued the existing controls and added a separate set of rules within the EAR for encryption software.

 

A key provision that has been carried over from the ITAR to theEAR is that the EAR imposes its full export control jurisdiction overall encryption software, even software that is available for freewithout any restriction. Previously, the EAR did not impose anycontrols or restrictions on software under its jurisdiction if thesoftware was available for free to any party.

 

A. Definition of Encryption Software

 

For the purpose of this memorandum, "encryption software" applies only to software controlled by ECCN 5D002 for "Encryption Item" reasons in the Commerce Control List ("CCL"). "Encryption software" does not include software that employs encryption only for authentication, encryption of passwords or PINs, and certain banking or money machine functions. In addition, "encryption software" does not include certain mass market software limited to a 40 bit or less keylength if the Commerce Department has issued a product specific written ruling stating that "Encryption Item" controls do not apply. These limited or weak encryption functions are within the definition of "non-encryption software."

 

B. Definition of Export

 

EAR section 734.2(b)(9) clearly states that the mere act of posting encryption software on the Internet is an export. The EAR does not contain a similar clear statement for non-encryption software, but rather implies that an export occurs when the party posting the software receives information that indicates that a potential downloader is located outside the U.S. or is a foreign national.

 

Export of encryption software means:

an actual shipment, transfer ortransmission out of the U.S.; a transfer of such software in theU.S. to an embassy or affiliate or a foreign country; downloading, or causing the downloading of, such software to locations (including electronic bulletin boards, Internet file transfer protocol, and World Wide Web ("WWW") sites) outside the U.S.; or making such software available for transfer outside the U.S., over wire, cable, radio, electromagnetic, photooptical, photoelectric or other comparable communications facilities accessible to persons outside the U.S., including transfers from electronic bulletin boards, Internet file transfer protocol and WWW sites.

 

Importantly, the Internet-related element of the definition of export of encryption software may be overcome if the person making the software available takes precautions adequate to prevent unauthorized transfer of such code outside the U.S. Unless the prescribed compliance procedures or "precautionså" are implemented, posting encryption software on the Internet is a violation of the EAR because it is an export and encryption software requires an export license for all countries.

 

C. Compliance Procedures

 

EAR section 734.2(b)(9) requires that the following compliance procedures or "precautions" be implemented when making encryption software available over the Internet:

 

1) Ensuring that the facility from which the software is available controls the access to and transfer or such software through such measures as implementing an access control system that through automated means or human intervention:

checks the address of every system requesting or receiving a transfer and verifies that such systems are located within the U.S.; provides every requesting or receiving party with notice that the transfer includes or would include cryptographic software subject to export controls under the Export Administration Act ("EAA") and that anyone receiving the transfer may not export the software without a license; and every party requesting or receiving a transfer of such software must acknowledge affirmatively that he or she understands that the cryptographic software is subject to export controls under the EAA and that anyone receiving the transfer may not export the software without a license.

2) As an alternative to 1) above, an exporter may implement other precautions that have been approved in writing by the Commerce Department's Bureau of Export Administration ("BXA").

 

The prescribed compliance procedures are intended toensure that no "export" occurs since encryption software may not be exported to any destination without a specifically approved export license from BXA.

 

---

 

III. Non-Encryption Software [top]

 

A. Definition of Non-encryption Software

 

For purposes of this memorandum, "non-encryption software"is software under EAR jurisdiction other than "encryption software."

 

B. Publicly Available

 

Any non-encryption software that is made available for free (or at a price that does not exceed the cost of reproduction and distribution) to any interested party without restriction is defined bythe EAR to be "publicly available" and not subject to any export controls. Thus, for example, if all of the software on a WWW page is freeware or shareware available for downloading by any party for free, there are no export compliance restrictions applicable to the software and there need not be any compliance procedures for such activities.

 

C. Non-Publicly Available

1. Definition of Export

 

As indicated above, the EAR does not contain a clear definition of "export" of non-encryption software. BXA interprets the EAR to mean that non-encryption software is subject to export restrictions when a party posting such software on the Internet knows it is being exported. According to EAR section 734.2(b), "export" of non-encryption software means:

a shipment or transmission of items(regardless of the country of origin of the items) out of the U.S.; or a "release" of technology or source code to a foreign national in the U.S.

BXA interprets the definition of "export" of non-encryption software to mean that if the party making the software available over the Internet receives any information or "Red Flags" that software is about to be downloaded by a foreign party, i.e., "exported," the party making the software available must analyze that information to determine if the software requires an export license for that foreign party.

 

2. Compliance Procedures

 

Most non-encryption software may be exported to most destinations, subject to certain limitations, without an export license.The compliance procedures for non-encryption software, therefore, may bedesigned to allow most çexportså to take place as long as the exporter(i.e., the party making the software available over the Internet)implements procedures to ensure that the software is not exported tounauthorized parties.

 

If a company sells software over the Internet and during the course of a transaction does not receive any "Red Flag"information that may indicate that the buyer is a foreign party, the sale may be considered a domestic, that is, non-"export," transaction. Examples of "Red Flag" information that a seller may receive would include the buyer having a foreign Internet address extension (such as.jp or .uk), a foreign Domain Naming System ("DNS") address, a foreign physical address, a company name or personal name identified as foreign on BXA's Denied Parties List ("DPL") or the Treasury Department's Specially Designated Nationals, Terrorists and Narcotics Traffickers("SDNs") Lists. If the seller does not receive any of that information, no "export" has occurred and no export compliance procedures would be required for the sale.

 

As a practical matter, it is likely that most Internet software sales would involve the seller receiving "Red Flag" information. The seller is responsible for all information it receives even if the information is never seen by a human and is only stored on a computer. Thus, for example, if during the course of an Internet transaction, a buyer lists France as his physical home address or provides an Internet address with a ".jp" country extension, the seller has received "Red Flags" and knows an export is occurring even if no human ever sees that information. Therefore, as a practical matter, itmay be prudent for the seller to assume that it will receive "Red Flag" information from a foreign buyers and implement export compliance procedures.

 

BXA's position for software available from Intranet sites or subscriber or customer-only sites is that if the party knows that anyone that may access such limited access sites is outside the U.S., the party must treat the mere posting of software on the site as an export. Thus, export compliance procedures must be implemented for such restricted access sites.

 

The two primary types of export restrictions that should be addressed in compliance procedures for non-encryption software are country-based restrictions and prohibited party restrictions.

 

3. Country Restrictions

 

Most non-encryption software may be exported to most countries without an export license. (In the rare case where non-encryption software would require an export license for all countries, compliance procedures to prevent all foreign downloading should be implemented. Such procedures can be similar to those described for encryption software.) To determine country restrictions applicable to a specific software product, the exporter must classifythe product under the CCL. That classification will identify what country-based restrictions apply. There are two general groupings of country-based restrictions.

 

Software Eligible for Export without a License: Most non-encryption software may be exported to all countries except Cuba,Iran, Iraq, Libya, and North Korea without an export license as NLR, "No License Required." (Depending on the software, Sudan and Syria may needto be added to this list of prohibited countries.) For such software, procedures should be implemented to ensure no parties in these prohibited countries obtain the software. This would involve requiring potential downloaders to fill out on-line forms in which they provide their name, address, Internet address and other information needed to make such a determination. Once provided, a system must be established to screen all this information to determine whether any such information indicates that the potential downloader may be in one of the prohibited countries. If the downloader is in a prohibited country, it must be prevented from obtaining the software.

 

Once a party in a prohibited country has been denied access to software, the exporter may want to consider taking steps toprevent that party from re-attempting to obtain the software in the future by providing a false country address. Such steps could included,for example, automated procedures to permanently block its name andc redit card number. (This could be integrated with the procedure for screening for prohibited parties described below.)

 

Software Eligible for License Exception Technical Software Restricted (TSR): Software that falls in this category may be exported to Country Group B (as defined in Supplement No. 1 to EAR Part740) without a license provided the exporter obtains a TSR written assurance from the foreign recipient prior to export. Thus, the two compliance tasks are 1) ensuring that foreign parties in Country Group B provide a written assurance prior to obtaining the software; and 2) ensuring that no foreign party outside of Country Group B obtains the software. The Peoples Republic of China is not in Country Group B.

 

Obtaining the written assurance may be as simple as requiring that the recipient read the written assurance on-line and click an on-line icon to indicate it accepts the terms. The exporter should set up its Internet software distribution site so that thesoftware may not be downloaded unless a Country Group B recipient first clicks its acceptance.

 

The second element is to ensure that no foreign partyoutside of Country Group B obtains the software. This would be done in a manner discussed above for preventing access by parties in prohibited countries except that access would be prohibited from all countries notin Country Group B.

 

4. Prohibited Party Restrictions

 

No software may be exported to a prohibited party(i.e., a party on the DPL or SDN list). Therefore, all names and addresses received from a potential downloader should be screened against these lists before allowing software to be downloaded. If a match is found, then the party should be prevented from obtaining software and steps should be taken to block its credit card and other information to prevent a future attempt to obtain the software using a false name and address.

 

In addition to the specific procedures for screening transactions, compliance procedures for non-encryption software could also include two elements required by the EAR for encryption software:

 

Provide every requesting or receiving party with notice that the

transfer includes or would include software subject to EAA export

controls and that anyone receiving the transfer may not export the

software without a license, if required; and

 

Require that every party requesting or receiving a transfer of

such software acknowledge affirmatively that he or she understands that

the software is subject to EAA export controls and that anyone receiving

the transfer may not export the software without a license, if required.

 

IV. Conclusion [top]

 

While relatively uniform standards of care for export compliance for traditional physical shipments of software have evolved, no such uniform procedures have developed for Internet software exports. Lacking guidance from the government, companies have implemented varying levels of compliance measures. Many companies making software available over the Internet have not likely implemented the export compliance procedures required by the December 31, 1996 amendments. The EAR requirements may be difficult to implement, as a practical matter.While there are no controls for publicly available non-encryption software, requirements must be satisfied for other software. Given the severe potential penalties for export violations and the government's likely eagerness to make an example of someone who illegally "exports" software over the Internet, companies are well advised to implement prudent procedures to ensure they comply with export controls for their Internet software exports.

 

Please do not hesitate to contact us if you have any questions.

Copyright (c) 1997 Fenwick & West LLP. Permission is granted to distribute this article freely for educational and non-commercial purposes, provided that this copyright notice appears on all such copies distributed.

---

RECOMMENDED RELATED READING: Update on Current Status of U.S. Export Administration Regulations on Software Exports

Return to Fenwick & West New-Media Home Page

Fenwick & West New-Media Articles

WWW Multimedia Law Website