Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!hoptoad.UUCP!gnu
From: gnu@hoptoad.UUCP (John Gilmore)
Newsgroups: comp.society.futures
Subject: Export control does *NOT* apply to publicly available software.
Message-ID: <8710270118.AA09965@hop.toad.com>
Date: Mon, 26-Oct-87 20:18:36 EST
Article-I.D.: hop.8710270118.AA09965
Posted: Mon Oct 26 20:18:36 1987
Date-Received: Thu, 29-Oct-87 04:42:16 EST
References: <8710222017.AA01466@hadron.UUCP> <276@ddsw1.UUCP>
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 362
I researched this topic pretty thoroughly last year, by going down to the
local Federal Building and wading through the rulebooks in Commerce Dept.
library. What prompted me to do it was that I had a PD DES, that I had
posted to comp.sources.unix, which a Canadian reader claimed was in
violation of export laws.
Rich $alz took the info I got and talked with the NSA (US National
Security Agency) and some Boston-area cryptographers. The upshot was
that NSA never came up with anything that contradicted the rules I
found, and Rich posted not only the DES code, for worldwide distribution,
but also the "crypt breaker's workbench" that decrypts the ancient Unix
"crypt" command.
Now, the way things wag with NSA is that if you ask them "Can I do this?"
the answer is almost always "No". What you have to say is "Show me the rules
that say I can't do this. I have some that say I can." The courts have
regularly ruled that the government cannot enforce a policy which is not
written down and equally applied to everyone (it's called "secret law").
So if what *is* written down supports you, they are stuck with it. They
can't secretly make new laws and tell you later that you broke them.
Since everyone else on this topic is shooting off their mouth without
having done any research (now we have *two* Canadians who are falsely telling
us what the US export law is -- thanks guys!), I figured I'd better post
my full references to make it credible. Save this message; if I ever leave
the net somebody had better have a copy to shout down the clowns again.
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.crypt,net.sources.d,net.legal
Subject: There are basically no export controls on public domain information.
Message-ID: <1176@hoptoad.uucp>
Date: 3 Oct 86 23:57:06 GMT
I got into a hassle last month for posting a DES program to mod.sources
because someone claimed that I was breaking the export control law.
I spent the afternoon down at the Federal Building and discovered that
export policy is in better shape than I thought. Basically, you can
export any technical data to any destination if it "has been made
generally available to the public in any form". This export is under
a "general license" which is available to everyone without any paperwork.
So, you should expect to see the DES posting again (it was canceled)
and to see Crypt Breaker's Workbench on mod.sources soon.
Here are the regs for all you policy hounds:
Export Administration Regulations, Part 370.2, Definitions.
"General License. A license established by the US Department
of Commerce for which no application is required and for which
no document is granted or issued. It is available for use by
all persons, except those listed in and prohibited by the
provisions of Supplement No. 1 to Part 388, and permits export
within the provisions thereof as prescribed in the Export
Administration Regulations. These general licenses are not
applicable to exports under the licensing jurisdiction of agencies
other than the Department of Commerce."
Part 379.1, Definitions.
"... All software is technical data."
Part 379.2, Licenses to Export.
"Except as provided in Part 370.3(a), an export of technical
data must be made under either a US Department of Commerce
general license or a validated export license. General
licenses GTDA and GTDR apply to specific types of exports of
technical data..."
Part 379.3, General license GTDA: Technical Data Available to all
Destinations.
"A General License designated GTDA is hereby established
authorizing the export to all destinations of technical data
described in 379.3(a), (b), or (c) below:
(a) Data Generally Available
Data that have been made generally available to the public in
any form, including--
(1) Data released orally or visually at open conferences,
lectures, trade shows, or other media open to the public; and
(2) Publications that may be purchased without restrictions
at a nominal cost, or obtained without costs, or are readily
available at libraries open to the public.
The term "nominal cost" as used in 379.3(a)(2) above, is intended
to reflect realistically only the cost of preparing and distributing
the publication and not the intrinsic value of the technical data.
If the cost is such as to prevent the technical data from being
generally available to the public, General License GTDA would not
be applicable.
(b) Scientific or Educational Data ...
(c) Patent Applications ..."
------ (end of first message)
John here, talking to info-futures again. Chris Lewis (the first
Canadian "expert") tried to pick the above to pieces, so I provided
more explanation by private mail, now revealed to the info-futures
readership for the first time ever!
Date: Sun, 12 Oct 86 16:57:06 PDT
From: gnu (John Gilmore)
Subject: Re: Export control revisited
Chris Lewis is still somewhat concerned about export control. I will
try to explain the things he mentioned in his message of 8 October.
>> "General License. A license established by the US Department
>> of Commerce for which no application is required and for which
>> no document is granted or issued. It is available for use by
>> all persons, except those listed in and prohibited by the
>> provisions of Supplement No. 1 to Part 388, and permits export
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> what is this section about?
It lists people who have abused the general license in circumstances
where it does not apply (eg shipping Vaxen to Russia). The idea is that
you are innocent until proven guilty with regards to general licenses.
I looked in the supplement and it was a 3-page list of names and cities.
I was not on it. :-)
>> within the provisions thereof as prescribed in the Export
>> Administration Regulations. These general licenses are not
>> applicable to exports under the licensing jurisdiction of agencies
>> other than the Department of Commerce."
> ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
> DOC is not the only agency involved.
I also got myself a copy of the regulations on cryptographic material
export, but I didn't include it in my posting since it did not apply.
It's listed under Part 399.1, supplement #1 (the Commodity Control
List), "ECCN 1527A". It mentions that computers when combined with
cryptographic software are covered under this ECCN, and says "Technical
Note: No technical data or software controlled under this ECCN may be
exported or reexported under General License GTDR." HOWEVER, we are
exporting under General License GTDA, not GTDR, and this is a valid
distinction. There is nothing in this ECCN section that precludes
shipping cryptographic technical data (e.g. software) under general
license GTDA. It also says, "Exporters requesting a VALIDATED LICENSE
from the Department of Commerce must provide a statement from the
Department of State, Office of Munitions Control, verifying that the
equipment intended for export is under the licensing jurisdiction of
the Department of Commerce." (emphasis mine) However, we are not
requesting a validated license, we are using the general license, so
this requirement does not apply either.
In summary, I believe that the provisions of ECCN 1527A do not apply to
public domain software, and we are OK. (I don't know of any other ECCN
sections that apply either.)
>> Part 379.3, General license GTDA: Technical Data Available to all
>> Destinations.
>> "A General License designated GTDA is hereby established
>> authorizing the export to all destinations of technical data
>> ....
>>
>> (1) Data released orally or visually at open conferences,
>> lectures, trade shows, or other media open to the public; and
>>
>> (2) Publications that may be purchased without restrictions
>> at a nominal cost, or obtained without costs, or are readily
>> available at libraries open to the public.
>
>This, in turn:
>
> 1) Has *this* DES program been formally published before?
> 2) Can it legally be? Journals are supposed to be reviewed prior
> to publication by one of the security agencies. We're a loophole.
> 3) From another tack: can you make a DES program PD?
(1) You elided the relevent section of the general license definition.
"(a) Data Generally Available: Data the have been made generally
available to the public IN ANY FORM, including... (1) and (2)...".
(emphasis mine.) If something has been placed into the public domain
and its location advertised to the Usenet community, or placed into
a publicly accessible bulletin board, or posted to the Usenet, I claim
that it has been made generally available to the public. (1) and (2)
are not the only ways something can be made available to the public;
they are just examples.
(2) You can't be expected to know how things work in the U.S., being
Canadian, but there is NO requirement that "journals are supposed to be
reviewed prior to publication". We have a free press here. They tried
to impose something like this and it didn't work. There is a
"voluntary" system whereby authors can submit manuscripts to the NSA
for review, but you are not even bound by the result -- they can only
make suggestions. Mostly this is so they can recommend that you delete
certain phrases that might give away what they are working on, and you
are supposed to feel patriotic enough to go along. Presumably they
could also try to go to court to stop you from publishing, but I don't
think that has happened to any paper that has been voluntarily
submitted under this program. (They did go to court against the
magazine that published the "how to build an atom bomb" article.)
You may be confused between mandatory review of journals and the
Defense Department's right to review articles by people who they fund.
If you are doing government-sponsored research, they can write the
contract such that they get to OK any release of information derived
from the sponsored research. But if I invent something on my own,
without gov't money, I can publish it.
(3) Public Domain-ness is a state of ownership. Since you can
certainly own a DES program (e.g. AMD owns the copyright of the 8068
DES chip; ATT owns crypt(1)), you can also renounce its ownership and
place it into the public domain.
>You didn't include anything from 370.3 (or is that a typo?) either.
It was not a typo. I don't have a copy of it here, but I don't think
it applies to us. It's part of the "General Policy on Exports" section.
>If this program were to be published in a technical magazine (presumably
>safest in a real journal, not necessarily BYTE), then I'd feel safe
>because they've already had approval. BYTE published one or two DES programs
>ages ago, but this was before the NBS standard was formalized. Presumably
>you could publish *that* program (6502 assembler), but not anything written
>since then. I haven't seen a DES program since (though, I don't read all
>that many journals...)
This objection is covered above -- there is no required government
review of publications here, and no government approval is required to
publish.
>I realize perfectly well that a court challenge on this would probably
>find in our favor - as in, is DES in software really DES? But, I want
>to ensure that we stay well clear of the shadow (if not the substance)
>of the law.
Actually, this is not relevant. The export control regs don't mention
DES at all. They say "cryptographic equipment...designed to ensure
secrecy of communications...or of stored information...and "software"...
performing the functions of such cryptographic equipment", and then
make a few exemptions for things like simple scrambled voice, video, or
fax.
>I can't help remembering the export restrictions on crypt (which, I believe
>are still in effect *even tho* Enigma has been declassified for years),
>AT&T's security package, Motorola and Intel's encryption boards etc.
>I remember seeing discussions in trade journals 2-4 years ago about DES
>export restrictions, code-breaking discussions, other more recent encryption
>methods, but I can't remember where.
None of the above stuff is "technical data generally available to the
public", so it cannot be exported under the GTDA general license. Note
that journal articles like the AT&T Tech Journal one on breaking crypt
are generally available to the public, and they are being exported
without trouble. Ditto for _Cryptologia_. It *DOES* take an export
license to export non-public technical data, e.g. the Unix crypt
command (licensed software), encryption boards (hardware, not
technical data), etc.
I must say that I felt the same way you do about this -- I had a general
feeling that exporting this stuff was illegal, even though I thought it
should be legal -- until I spent the time to research it. My opinion of
the people who wrote US export law has gone up significantly. They
really believe that if the US "public" can get it, it is exportable.
FYI, here is the definitive story on how the "export restrictions on
crypt" came about, from Dennis Ritchie himself. As you can see, no
government agency ever said it could not be exported; AT&T and DEC
simply decided that applying for an export license was too much trouble.
I've also included a message from Gordon Moffett who says that Amdahl
is now exporting Unix with the crypt command without trouble.
>From dmr@research.UUCP Mon Sep 17 22:15:46 1984
Path: CSL-Vax!decwrl!decvax!mcnc!unc!ulysses!allegra!alice!research!dmr
From: dmr@research.UUCP
Newsgroups: net.crypt
Subject: export controls
Message-ID: <1041@research.UUCP>
Date: 18 Sep 84 05:15:46 GMT
Posted: Mon Sep 17 22:15:46 1984
As has been said, there is indeed a special "International Edition"
of System V that differs from the ordinary system in that it
lacks the crypt command, the encrypting features of ed and vi, and the
encrypt entry of crypt (3). The crypt entry, which is used for
passwords, is there, as is the underlying DES algorithm.
Here's how it happened.
About a year ago, I got mail from Armando Stettner saying basically,
"Do you know of any problems with exporting crypt? Our lawyers
[at DEC] are worried about it." I replied that such worries were
utterly unfounded for a variety of sensible reasons.
Now, as it has turned out, DEC was very justified in worrying about
export controls in general; they have recently been fined (I think) $500,000
for the Vaxen that almost got sent to Russia. I conjecture that
the earliest stages of this or a similar incident were already in progress
and they were trying to be extra careful when they learned about crypt.
At any rate, the DEC lawyers communicated their fears to AT&T,
and the AT&T lawyers, equally cautious, sought government advice.
The problem, you see, is that cryptographic materials are under export
control. There is a thing called the Munitions Control Board that worries
not only about machine guns going to Libya, but also about the crypt
command going to England. In practice, the enforcement is done by the
Commerce department.
AT&T had a meeting with Commerce, the MCB, and NSA. The upshot was
that they decided it would be simplest all around just not to export
the crypt command. The gov't would almost certainly have granted
the license, but (probably wisely) AT&T decided it wasn't worth
the hassle.
In technical terms, the situation is ludicrous. The encrypt subroutine
is distinguished mainly by the excruciating care I took to make it
an exact transcription of the algorithm published in the Federal Register,
and by its slowness. NBS, the caretaker of DES standardization,
is explicit that software implementations cannot be certified, so in that
sense encrypt is not "real" DES. The underlying subroutine is still
there, only the simple command that uses it is missing. So there is
actually nothing to protect, and even if there were, it's not protected.
Nevertheless, in the present situation we officially don't need
an export license, whereas with the crypt command we would.
In political terms, AT&T probably could have done better. Conservative
and careful, they called a big meeting at which no one could possibly
have put forward anything but official positions about encryption
programs. Private checking with well-placed people in the appropriate
agencies might well have done the job. But who knows?
Dennis Ritchie
-----
In article <3140@amdahl.UUCP> Gordon Moffett writes:
Our Corporate legal advisor says that the restrictions against
exporting encryption stuff has been lifted. We used to have two
UTS's: one with the crypt(3) stuff for domestic customers, and one
without export. We no longer distiguish between the two -- we now ship
everything to non-USA customers just as to the USA sites.
I've already gotten one letter about this, asking me for further
confirmation that this is ``true''. First, PLEASE DON'T ASK ME! Talk
to *your* companies' legal advisors, or to the Federal Government
directly. Second, I am sure we would hear about it from the Federalees
if our Corporation were making a mistake ....
--
Gordon A. Moffett ...!{ihnp4,seismo,hplabs}!amdahl!gam
[Back to Chris's comments: -- gnu]
>The definitive answer would be to see whether the current listing of
>restricted items includes DES, and in what forms. I don't think excerpts
>from a different set of legislation is sufficient to answer this question.
>Further, there *may* be a difference between "legislation" and "regulation"
>here. DES restriction might *not* be enshrined in legislation, but come
>out of some other department's regulatory powers. The second paragraph
>I've quoted still leaves that whole question open.
I have spent the time researching it, and I think it's OK to export.
If you still think differently, please give details of the regulations
or laws involved. I'm not interested in "maybes"; I have an answer
that came straight from the rule books, and won't be swayed from it
by anything less definitive.