18 February 2000: Link to BXA response.

2 January 2000
Source: Cindy Cohn, lead Bernstein counsel in Bernstein v. Dept. of Justice, et. al.

See EFF's Bernstein case files: http://www.eff.org/bernstein/

[McGlashan & Sarrail letterhead]

January 16, 2000

Mr. James Lewis
Office of Strategic Trade and Foreign Policy Controls
Room 2628
Bureau of Export Administration
Department of Commerce
14^th & Constitution
Washington, DC 20230

Re: Bernstein v. Dept. of Justice, et. al.

Dear Mr. Lewis:

Pursuant to the discussions between our offices and Mr. Anthony Coppolino of the Justice Department, this letter requests an official advisory opinion concerning the new encryption export regulations issued by your offices on January 14, 2000 (hereinafter "EI regulations").

Our overall concern is that the EI regulations continue to interfere strongly with Professor Bernstein's planned scientific activities. First, the EI regulations continue to maintain unconstitutional and pointless distinctions between print and electronic communications media. Second, while we recognize that your agency intended to reduce significantly the burden on Prof. Bernstein and others who communicate encryption software, the EI regulations remain so complex and ambiguous that Prof. Bernstein cannot be sure whether many of his normal scientific activities would be lawful.

Given that this matter is currently in litigation on a facial challenge, we have three suggestions that we believe will assist both parties as well as the general public in reviewing and relying on the matters discussed in the Opinion.

First, we request that the Opinion be made publicly available by BXA. Specifically, we request that it be posted on the BXA web site along with the other encryption-related materials there. This will ensure that the understandings that it conveys are available to all persons who may wish to understand your interpretation of the new regulations. As you know, one of our chief concerns is that the regulations continue to be quite complex and difficult to understand for trained professionals, much less lay people. Since Professor Bernstein's case is a facial challenge, making these interpretations available to persons other than Professor Bernstein seems a reasonable way for BXA to minimize any misunderstandings about the new regulations that may occur.

Second, in order to make this process as fruitful to both parties as possible, we would hope that you and your colleagues would feel free to contact us with draft language of the opinion and other issues. We are pleased that BXA has recently been open to a more interactive relationship with those who are regulated by it, and hope that this can continue throughout the advisory opinion process.

Third, as you know, the 9^th Circuit has ordered supplemental briefs concerning the new regulations that are due 21 days from the date of issuance of the regulations. Since the regulations were issued on January 14, 2000, the supplemental briefs are due on February 4, 2000. Oral argument is set for March 21, 2000. We have discussed this schedule with Mr. Coppolino and we both believe the court would agree to a request to move the date for the supplemental briefings somewhat in order to allow such briefing to occur after the advisory opinion is issued. We believe it is less likely, however, that the court will agree to move the hearing date again. Thus, we suggest the following schedule for your response and our subsequent briefings:

Advisory Opinion: February 7, 2000.

Supplemental Briefs: March 1, 2000.

Hearing date remains: March 21, 2000

If you agree to this schedule, we will join in a request with the Justice Department to modify the briefing schedule.

Questions for Advisory Opinion

These questions reflect our review of the regulations issued on January 14, 2000. However, most of these issues were also raised during the process leading up to the issuance of the regulations, specifically during our meeting with you on November 30, 1999, and in the sample "Frequently Asked Questions" submitted to you thereafter by John Gilmore. Please feel free to refer to that document or to contact us if you require further explanation of our concerns.

1. Distinctions Between Source Code on Paper and Source Code in Electronic Form.

As you know, one of the cornerstones of our Constitutional arguments in this case has been the fact that the regulations treat software communicated in electronic form differently from software communicated on paper. We believe this distinction is inconsistent with the Supreme Court's decision in Reno v. ACLU, which rejected such distinctions and held that the Internet is a fully protected medium of expression for purposes of First Amendment analysis. We believe the regulations remain inconsistent with this precedent in several ways.

A. Prohibition on Electronic Publication or Communication of Source Code if One Has "Knowledge" that Persons from Restricted Countries will Receive the Code.

As you know, since 1990, Professor Bernstein has wished to publish encryption source code through the Internet. In particular, he wishes to publish it on web pages, on mailing lists, and on the Usenet newsgroup sci.crypt. Assume Professor Bernstein knows that some of the readers are residents of Iran. He knows this from review of his log files and review of the postings to the newsgroups, or he knows that a computer in Iran receives a feed that includes sci.crypt. His actions are therefore appear prohibited by section 740.13(e)(2). These actions would not be prohibited if the source code were communicated to these persons on paper, since such publication or communication is not subject to the EAR or EI controls.

Draft 740.13(e)(3) states, inter alia, that the mere fact of Internet publication would not "establish'' knowledge of an export to Iran. Further, question 14 states that this includes newsgroups. But none of these appear to protect Professor Bernstein if he already has the knowledge that persons from the restricted countries either 1) subscribe to the newsgroup or 2) regularly review his web page. Please advise as to whether you interpret these regulations to prohibit publication under these circumstances and explain why or why not.

Next, we note that the regulations add two additional countries to the prohibited list, Serbia and Taliban Afghanistan. What is the duty of an "exporter" to know which countries (or portions of countries in the case of Afghanistan) are on the prohibited list at any given time? Similarly, what are the duties of an "exporter" to check the Denied Persons List?

B. Simultaneous Notification of BXA and NSA Upon Publication.

The requirement that Professor Bernstein and others simultaneously notify both BXA and NSA at the time of electronic publication of source code, when no such notification is required for publication or communication of such code on paper, is another Constitutional problem.

Although the Supplementary Information section states that only the initial export is subject to the notification requirement, it is still not clear how this regulation would apply to persons who run "mirror" sites or archive sites on the Internet. Many such sites automatically copy web pages from one location and make them available in another. These sites are not reviewed for content; indeed such review would be so onerous as to prevent the sites from carrying any sites that might contain encryption source code. Would notification of BXA and NSA by the initial publisher be sufficient? If the initial publisher fails to make the required notification, would there be liability for the mirror or archive sites?

Also, is a subsequent notification required for every update or bug fix made to an encryption program? Many open source programs are developed on Listservs and through other mechanisms wherein the source is constantly evolving. What is the threshold for subsequent notifications?

Finally, the chain of liability for failure to make such notifications is not specified in the regulations. In the case of source code that is developed interactively among many persons, and hosted on computers owned by others, who is responsible to ensure that notification occurs? What about in the instance of university-owned computers that host web sites where students can post software? Is the university liable if the student fails in his/her duties under the new regulations? Is the university responsible for monitoring all postings made on its system by students to ensure that no encryption software is posted without notification to BXA and NSA? Can a university or other party simply send you a general notification that encryption software might be posted on its site (for instance, www.berkeley.edu) and thereby fulfill its requirements?

C. Reporting Requirements for ENC Software

The regulations require that those publishing software that is categorized as ENC (except if it is transferred to a subsidiary) present bi-annual reports to the agency about certain recipients of the code. No such requirement is applied to source code published on paper. It is also not required for source code published under TSU. The First Amendment makes no applicable distinction between speech that is sold and speech that is given away; we see no constitutional basis for applying more onerous restrictions on publication of speech that is to be sold or is subject to a licensing or royalty fee than speech that is not. Does this reporting requirement apply to ENC software?

D. Definition Issues in the Distinction Between Paper and Electronic Media

The EI regulations continue to distinguish "encryption source code in electronic form or media (e.g., computer diskette or CD ROM)" from encryption source code set forth in "printed material." 15 C.F.R. Sec. 734.3, Note to paragraphs (b)(2) and (b)(3). The distinction appears to be based on "scannability." 61 Fed. Reg. 68572, at 68575 (Dec. 30, 1996).

Yet this distinction is confusing for a host of items that are not clearly paper or electronic, or that can shift between the two. Please classify each of the following proposed export situations into whether the export is of "printed material" or of material "in electronic form or media":

i. A person prints encryption source code on paper and then faxes it overseas?

ii. A person writes source code on a computer and uses a fax-modem to fax it overseas?

iii. Does it matter whether the recipient receives the source code on a fax machine that prints it on paper or on a fax-modem where no paper is produced?

iv. Does it matter if a person uses an electronic medium to transmit source code not as a text file but as an electronic "picture" (e.g., as a GIF, JPEG, or Postscript file) that would have to be processed by character-recognition software into text before it could be understood by a computer, is that export considered to be "print" or "electronic"?

v. A person gives a presentation that features encryption source code that is broadcast or Webcast around the world. Does it matter whether the broadcast is analog or digital network such as DirecTV or streaming images on the Internet? (Note: this what happens now with many lectures at Stanford University, which operates an "instructional TV" network). Does it matter if Professor Bernstein knows that the network can be seen in Iran?

vi. Does it matter if the presentation is made on a blackboard, overhead projector laptop, or Powerpoint slides?

Finally, we remain concerned that even as to encryption source code set forth in "printed material," the government "reserves the option to impose export controls on such software for national security and foreign policy reasons." 61 Fed. Reg. 68572, at 68575.

2. Technical Assistance

A. Object Code

We are also unclear on how TSU and technical assistance intersect with object code. Professor Bernstein regularly engages in public and private communication to help people use his software. He writes web pages explaining how to compile and run his software. If he receives email with further questions, he responds to the email, and sometimes adds the same information to a public list of "Frequently Asked Questions" on his web pages. He provides similar information in person to students in class and to colleagues at conferences.

Professor Bernstein intends to do the same for his encryption software. Do you interpret helping a foreign person create compiled encryption software from source code exported under TSU constitute "technical assistance" if the compiled software, i.e., object code, remains controlled as ECCN 5D002?

We note that, for all other software, the public availability exemption provides that if the source code is publicly available, so is the object code.

See question G(1) in Supplement No. 1 to Part 734:Question G(1): Is the export or reexport of software in machine readable code subject to the EAR when the source code for such software is publicly available?

Answer: If the source code of a software program is publicly available, then the machine readable code compiled from the source code is software that is publicly available and therefore not subject to the EAR.

B. Extent of Coverage

The Supplementary Information section of the EI regulations states that 15 C.F.R. Sec. 744.9 does not apply when those who use TSU "provid[e] assistance to foreign persons working with such source code." What does "working with" mean? Does it include "working with" the foreign person to modify the source code in any way? Does it include "working with" the foreign person to compile the source code into object code? Does it include assistance with writing new software, not derived from the TSU software, which is intended to "plug into" TSU software or intended to interoperate with TSU software?

C. Scienter

The technical assistance "scienter" provision remains vague. This has been a problem throughout this litigation that does not appear to be solved by the new EI regulations. Would assistance in the compilation of source code to make object code, such as instructions on a web page, be included? What if the web page was added at the request of a foreign person? What about informal discussions at conferences or otherwise, as opposed to formal papers presented that seem to be covered by the TSU exception? What about private consulting that Professor Bernstein might do to further develop his publicly available source code and object code for a private party or at the request of a foreign colleague?

If 744.9 does not apply to general situations of "working with" foreign persons, what about foreign persons in the terrorist nations? This situation can easily arise if a person in Iran downloads Prof. Bernstein's TSU-published source code and then sends him e-mail about it. Assuming he had acted in accordance with TSU when he put his source code on the Web, and thus did not "knowingly export" the source code to Iran, is he in any way hampered in "working with" the Iranian person, so long as he does not provide "encryption source code"?

Please note that these are not theoretical questions; all of these questions have faced Professor Bernstein in the past or face him currently.

3. Definitions

A. "Express agreement for the payment of a licensing fee or royalty for the commercial production or sale of any product developed using the source code."

Professor Bernstein intends to publish encryption source code in traditional scientific journals and books, including journals and books that are available through the Internet. Traditional scientific publishing houses require that authors transfer copyrights for source code, and all other works, to the publishers. Under those copyrights, one cannot sell software derived from the source code without paying royalties to the publisher.

EI Section 740.13(e)(1) does not provide any relief for source code ``subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed with the source code.''

This phrase is extremely unclear and, although 740.13(e)(1) and question 16 provide that this phrase is not triggered by "intellectual property protection, such as a copyright, by itself," it is not at all clear what would trigger this clause. It is especially unclear since copyright protection itself sets up a situation where a person would have to pay a licensing fee or royalty for further use of the source code.

i. What does "subject to an express agreement'' mean "where a contract has been offered,'' or "where a contract has already been formed''? Does this mean that the publication itself would trigger the clause, or that the clause would only be triggered when the royalties were negotiated? When the royalties were due? What if the copyright notice contains the royalty provisions, as some shareware notices do?

ii. What does "product'' mean? Does this mean object code? Does it include republication of the source code in a database or compilation? Suppose one has a contract with a publisher for a book about cryptography containing encryption source code, and it provides for book royalties?

iii. What does "commercial'' mean?

iv. Can liability under this clause be traced back to the author of the source code if the copyright has been assigned and the royalty goes to the publisher?

v. Can liability under this clause be traced back to the author of the source code if he retains some form of copyright under his agreement with the publisher and, for instance, shares in any royalties or licensing fees paid?

Under most interpretations, this phrase, perhaps inadvertently, appears to cover the standard scientific publishing situation described above. Scientific publishing houses will continue to be subject to heavy civil and criminal penalties for making encryption source code available through the Internet. Professor Bernstein is concerned that publishers will turn down encryption source code rather than risk prosecution.

B. Source Code vs. Object Code

The EI regulations generally distinguish source code from object code, which apparently turns on the "level" of language in which the software is written. Programming languages, however, exist at more than just "high" and "low" levels. For instance, software for human reading and study is often written in assembly language or other "intermediate" languages. [insert Dan's example] Is such software treated as source code?

Furthermore, many common programming languages, like Perl and LISP, are interpretive languages that do not divide into source and object code levels; strictly speaking, software written in such languages is not "compiled" but rather "interpreted." See 15 C.F.R. Part 772, Encryption object code ("Computer programs containing an encryption source code that has been compiled . . . . ). Are interpretive languages and other types of programs that do not fit the regular source/object model treated as source code or object code?

C. Knowledge

We are concerned about the definition of "knowledge." The EAR defines this term as encompassing "know," "reason to know," or "reason to believe". We assume that this definition was crafted primarily for general exports. For Internet speech and thus for First Amendment purposes, however, we believe that "awareness of a high probability" of a condition's "existence or future occurrence . . . . inferred from a person's willful avoidance of facts" sweeps far too broadly. Your Question and Answer section states that knowing means "i.e. direct transfer or e-mail" (question 15) which seems to be narrower than the general EAR definition. Do you interpret the term "knowledge" under the new regulations to encompass the definition of the term used elsewhere in the EAR? If not, please explain the differences.

D. Open Cryptographic Interface

The EI regulations now define "open cryptographic interface." ("OCI"). However, the definition seems to sweep in all source code programs, at least under interpretations previously made by BXA (that all source code is "modifiable by the user", and thus that source code is "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" under the definition). Now, section 740.17(f) states that this restriction is not applicable to "publicly available" source code, but source code that is not "publicly available" is still protected expression under the First Amendment. What distinguishes encryption source code programs that are OCIs from those that are not? Is a library that provides functions related to encryption, such as RSA's BSAFE or SSLeay, always an OCI?

E. ENC issues

15 C.F.R. Sec. 740.17(a)(5)(iv) states that foreign products developed for commercial sale using ENC source code or general purpose toolkits are subject to reporting under (g)(3). Who has the duty to report? There also appears to be a scienter conflict in ENC. 15 C.F.R. Sec. 740.17(a)(5)(i) prohibits "knowing[] export" of ENC source code to terrorist nations, while 15 C.F.R. Sec. 740.17(a)(3)(iii) ("retail") permits "free or anonymous downloads." But 15 C.F.R. Sec. 740.17(b) states that "[n]o encryption item(s) may be exported or reexported under this license exception to" the terrorist nations without making allowances for these provisions.

F. Recapture

Suppose a person publishes encryption source code on a Web site under TSU and a foreign person produces a "product" containing that source code or a modification thereof. Does the first publisher have any duties as a result of the foreign person's conduct? Is there anything that the foreign person could do on his own that would cause the first publisher to be liable?

G. Intersection With General Public Availability

TSU provides that encryption source code published under TSU is "released from 'EI' controls." Once the source code has been so released, it would seem that the source code is no longer ECCN 5D002. Does that mean it is eligible for true public availability such that it is release?

4. Discretionary Prepublication Licensing Scheme Remains for Much Source Code

The EI regulations continue to require licenses for much protected speech (source code that is not "publicly available"; source code that qualifies as an "open cryptographic interface"; and various forms of object code) without the procedural safeguards required by Freedman v. Maryland and City of Lakewood v. Plain Dealer and as described by both the 9^th Circuit panel and the District Court in this case.

For example, encryption source code that is not publicly available is covered under license exception ENC can be "exported" 30 days after receipt by BXA if BXA does nothing. But BXA can extend the prior restraint indefinitely simply by "otherwise notif[ying]" the "exporter" during the 30 day period. 15 C.F.R. Sec. 740.17(e)(1). We note that a 30-day review period is a prior restraint period that is significantly longer than those accepted by the courts under Freedman. Most are no longer than 4-7 days.

Further, nothing in the regulations limits either the duration of the prior restraint or agency discretion to impose it; once it is imposed it is unclear when, if ever, the restraint will be reviewed by a court. The regulations do not require the government to go to court. Also, judicial review of licensing decisions is available today only because the EAA expired and the EAR are authorized under IEEPA; should the EAA be reauthorized, the constitutional problems will be even worse.

* * * * *

We recognize that this is a fairly long set of questions. However, we believe this is the result of your decision to promulgate extremely complex regulations that create many new categories and sub-categories of treatment for encryption items. We were hopeful that, instead, the Administration would chose to simplify regulation of encryption items, such as by treating them as all other software regulated under the EAR, or by simply deregulating them entirely. Nonetheless, we do appreciate the efforts you've made to liberalize the EI controls.

We have tried to organize these questions to give you the opportunity to address sets of issues together and, we hope, to clarify them, both for our client and for the many others affected by them. As always, please do not hesitate to contact me with any questions or concerns.

Sincerely,

McGLASHAN & SARRAIL
Professional Corporation

CINDY A. COHN

cc:
Anthony J. Coppolino [Department of Justice]
Scott R. McIntosh [Department of Justice]
Daniel J. Bernstein

HTML by Cryptome.

Please send any questions or comments to webmaster@eff.org