Subject: Re: Exporting Crypto in Practice
From: Frank Hecker <frank@collab.net>
Date: Wed, 06 Dec 2000 12:49:23 -0500

"Jonathan S. Shapiro" wrote:
> You do not need to wait for classification under the TSU exception, and
> you do not need to build enforcement into the code or the web site.

My apologies for coming in late on this, but I wanted to confirm what
Jonathan wrote. Software which consists _only_ of open source code can
be exported from the U.S. with minimal restrictions and no need for
formal classification by BXA. We have been doing this in the Mozilla
project for quite some time; see

http://www.mozilla.org/crypto-faq.html

for the gory details. (Well, the details prior to the latest update to
the regulations in October.)

There are a couple of points that I wanted to add to Jonathan's
discussion:

First, IMO the "safe harbor" provided by 740.13(e)(4) fully applies only
if you're putting up software for anonymous download ("... where it may
be downloaded by anyone ..."). If you have a scheme where people have to
explicitly register in order to download open source software then
arguably you might need to include some sort of additional procedure to
screen people. The same applies in cases where you send software to
people via email or any other mechanism where you address a person
individually.

Note also that in that case you might have obligations beyond just
preventing people from proscribed countries from accessing the software.
You might also have to worry about access by people outside those
countries who are nonetheless on the "denied persons list" maintained by
the US government:

http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:dpl.pdf

If so, you might want to have people answer a "yes/no" question to
affirm their eligibility to receive the code, as opposed to just doing a
DNS screen.

Second, there's a minor ambiguity relating to the notification
requirements of 740.13(e)(1): If you modify the software that you put up
for download, does that constitute a new act of exporting and require
another notification to be sent to BXA? This is especially relevant for
projects maintaining active CVS repositories containing source code.

In the Mozilla project we set up a special mailing list
"mozilla-crypto-checkins" and a corresponding newsgroup

news://news.mozilla.org/netscape.public.mozilla.crypto.checkins

to which a custom script will automatically generate a message for every
CVS checkin that is made to certain source directories deemed to be
crypto-related. The URL for the newsgroup was then provided to BXA as
part of the original notification. This may be overkill in terms of what
is required "in theory", but it was relatively easy to set up and
maintain.

In general the way the Mozilla project handles crypto-related stuff may
be a good model for other US-based open source projects. The people
doing the crypto stuff had already had extensive experience with dealing
with BXA and NSA on export of Netscape Communicator and related
products, we (Netscape and mozilla.org) did a lot of additional research
on the implications of the new (January 2000) regulations for the
Mozilla project, and in general I'm pretty comfortable that the Mozilla
project is "clean" with regard to US export control issues.

(There are other aspects to consider as well, incidentally. For example,
you might want to have people checking in code to your repository sign
an agreement with a clause relating to handling of crypto code.)

Now having written all that, I should add that I am not a lawyer and the
above is not legal advice; you should consult your own lawyer if you
want true legal advice. However note that even lawyers who have
experience with US export control issues are typically used to dealing
only with proprietary software, and are not necessarily well-versed in
how export control works with regard to open source software. Therefore
I recommend that you read the relevant regulations and commentary
yourself, so that you can ask intelligent questions and point your
lawyer in certain directions where appropriate.

Frank
-- 
Frank Hecker            work: http://www.collab.net/
frank@collab.net        home: http://www.hecker.org/