BOUNCE eros-announce@eros-os.org: Approval required:

shapj@us.ibm.com shapj@us.ibm.com
Thu, 20 Jan 2000 22:16:08 -0500


Several people have asked about the export status of both E and EROS/B2+ on
this list under the new regulations.  I've now done a careful look at the
regs and had a lengthy conversation with the commerce department. What
follows are answers that I now believe are accurate enough to be given with
confidence.

My apologies for the length of this note; the answer is regrettably
complicated. The reader's digest synopsis is that both E and EROS/B2+
appear to be exportable in both source and binary form by virtue of being
open source, though an application to commerce is necessary for binary
export.

Prefatory notes:

1. I share the opinion of EFF that the regulations as written are an
unconstitutional violation of the first ammendment right to free speech.
Given this, discussion on whether to follow or violate the regulations is
appropriate. Let us keep the threads separate, and confine this thread to a
discussion of exactly what the regs *are*.

2. I will use the term "EROS/B2+" to identify a hypothetical EROS
derivative that would be certifiable at better than B2 under the orange
book. Note that Bill Frantz and several others quite wrong in what the
export regs control. Whether you certify or not, whether you do the
documentation or not, a system that incorporates any of the orange book
functionality specified above the B2 level is probably covered by export
regulations.  Last week, that meant that it was not exportable. This week
the answer is different, as I shall explain in detail.

3. The actual text of the official Federal Register publication may be
found at:

     http://www.bxa.doc.gov/Encryption/pdfs/Crypto.pdf

4. All references below are to the export control list as revised.

EXEGESIS:

The answer is different depending on whether we are discussing source code
or object code. Under the letter of the regulations, merely compiling the
source code to generate object code (or executable) moves the software into
a different category. This is pretty absurd, and commerce knows it. Don't
grumble until you have read the rest of this note.

Source code:

Under section 740.13 (e)(1), open source encryption source code may be
exported **or reexported** without a review, provided that the commerce
department is notified prior to posting, and that no charge is required for
redistribution.

While it is NOT obvious from the text, commerce has decided that any source
code incorporating encryption functionality is considered encryption source
code. All secure operating systems incorporate encryption functionality;
therefore, EROS/B2+ is also exportable under this provision. [This was
specifically covered in my discussion with them.]

You may post such code. While you may not knowingly ship it to one of the
T-7 terrorist countries, merely making it available for unrestricted
download on the web or an FTP site is *not* considered "knowledge" of a
prohibited export or reexport. [740.13 (e)(3)]  Further, there is no need
to prevent foreign governements from downloading the source code.

That is, you don't need to check the domain names, and no reporting of
download destinations is required.

Note that RE-export of source code also requires notification. In
particular, re-distributing Tyler's distribution from a US web site
requires notification to the commerce department.

Object code:

Object code is trickier. There are two cases for our purposes.

Case 1: Redistribution to US subsidiaries (for internal use) is permitted,
and does not require review or classification. This does not impact E, but
it probably does impact secure operating systems because of the cost of
certification and the consequent need to have the broadest possible
distribution.

Case 2: Retail software

Both E and EROS/B2+ binaries qualify for retail software treatment under
740.17 (a)(3). They satisfy requirement 740.17(a)(3)(i) because they are
"Specifically designed for individual consumer use and sold or transferred
through tangible or intangible means" and the satisfy 740.17(a)(3)(ii)(A)
because in binary form the cryptographic functionality cannot be easily
changed by the user. Note that this requirement would NOT be satisfied by
source code. Note also that programs with an open cryptographic interface
are another matter entirely.

Object code export remains controlled under category NS (national
security). To get the retail object code exemption requires that BXA review
the product and classify it as a retail product.

After some discussion with the folks at commerce, they said that (a) it is
there intention to be liberal here, and that (b) the binary resulting by
compiling open source code would in their view be classified as a retail
product. An application for this license is required (a 30 day process),
but once you get the classification made there are minimal constraints:

     You can't export to the T-7 terrorist countries

Cute suggestion from someone at work: you can bypass the object code crud
by shipping a self-compiling archive of the source code.

Reporting:

Per 740.17(g)(iv), you need not report export of retail products exported
to individual consumers. Per 740.17(g)(v) there is no requirement to report
exports made via free or anonymous download.

Advisory Opinions:

It is possible to obtain from commerce an advisory opinion before you
actually have a product. Unlike an advisory from DoD, there is some legal
binding character to such an opinion (not clear how much). Unless there is
a change in the regulations or a difference between what you described to
them and what you eventually tried to get reviewed, your expectation is
that the actual decision will be consistent with the advisory opinion.
[Also barring the outbreak of war, which could change everything.]


Reminder: I'm no lawyer.


Jonathan S. Shapiro, Ph. D.
Research Staff Member
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 6576