gnu@hoptoad.uucp (John Gilmore) (10/04/86)
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 ..."
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
May the Source be with you!tenney@well.UUCP (Glenn S. Tenney) (10/07/86)
In article <1176@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >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. I hope that this is a recent change. A friend of mine publishes a public domain FORTH system that has been sold in stores and on BBSs for years. He was told by the Feds (I don't remember which) that he could not export the system. He replied that anyone can walk into xyz store and buy it, but the answer was still no. It was my impression that SOME software is somehow considered a no-no for export. -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
henry@utzoo.UUCP (Henry Spencer) (10/09/86)
> I hope that this is a recent change. A friend of mine publishes a public > domain FORTH system... > He was told by the Feds (I don't remember which) that he could not export > the system... The Feds do not necessarily know and understand the details of the law. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
perley@vdsvax.uucp (perley donald p) (10/10/86)
Reply-To:chinet!steinmetz!vdsvax!perley (Don Perley) In article <1176@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >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. >........... > These general licenses are not > applicable to exports under the licensing jurisdiction of agencies > other than the Department of Commerce." > There's the rub! A company I worked for in 1979 (Software Solutions, Inc) could not export a DES based encryption package. The agency that had to approve (and didn't) was BATF (Bureau of Alchohol, Tobacco, & Firearms). Apparently encryption tools count as firearms. That was a few years ago, things may have changed. Don Perley chinet!steinmetz!vdsvax!perley (or so I'm told)
artm@phred.UUCP (Art Marriott) (10/10/86)
*** REPLACE THIS LINE WITH YOUR HARASSMENT ***
In relation to this, a year or two ago the IEEE sort of gave up and started
submitting drafts of the papers of vitrually all technical conferences it
sponsored to the Department of Defense for prior approval. Prior to this
they had to deal with DOD representatives arriving a day or two before a
conference and insisting on going through the proceedings and deleting any
items they thought might relate to "sensitive technology". Made for something
of a mad scramble to edit slides, speakers' notes and such, and in a few cases
made it hard to fill up the available time with what was left.
It seems that since the Reagan administration took office the military has
operated under the assumption that ALL scientific and technological develop-
ments in the US are potentially its property if they can possibly be used for
military purposes. I don't know if this has been challenged lately in court,
but most technical organizations either don't want to bother with it or are
aware that a substantial percentage of their membership work for the government
in one way or another.
What's regrettable is that this in fact tends to stifle development of tech-
nology. Eventually the boys in uniform won't have to worry about keeping our
great stuff from getting out of the country because we won't have anything that
anybody else would want.
Art Marriott
Physio-Control
tikal!phred!artm
...............................................................................
Opinions? Opinions? I don't see any opinions...jrc@ritcv.UUCP (James R. Carbin) (10/12/86)
In article <716@phred.UUCP> artm@phred.UUCP (Art Marriott) writes: > ................. >It seems that since the Reagan administration took office the military has >operated under the assumption that ALL scientific and technological develop- >ments in the US are potentially its property if they can possibly be used for >military purposes. I don't know if this has been challenged lately in court, >but most technical organizations either don't want to bother with it or are >aware that a substantial percentage of their membership work for the government >in one way or another. > >What's regrettable is that this in fact tends to stifle development of tech- >nology. Eventually the boys in uniform won't have to worry about keeping our >great stuff from getting out of the country because we won't have anything that >anybody else would want. > > Art Marriott > Physio-Control > tikal!phred!artm > Well said, Art! An anecdote: Three and one-half years ago I had the opportunity along with 79 others from around the U.S. to make a three-week visit to the People's Republic of China. Representing software engineering folks from around the States, we were supposedly expected to "open the doors" for further discussion with our Chinese counterparts. In retrospect, I was quite annoyed with the "powers that be" whether it be State or Defense or whomever, that in our pre-visit briefing, nothing was ever said with reference to what we could and could not discuss. I feel rather confident in stating that in all liklihood all 80 of us broke U.S. law at least once in discussing information which is considered sensitive and not in the pubic domain. (F.B.I. - come arrest me! :-) ) Quite seriously though, if you were in placed in a similar situation, would YOU know what you couldn't discuss. I sure as heck don't. j.r. {allegra,sesimo}!rochester!ritcv!jrc
klinner@sun.uucp (Kent Klinner) (10/17/86)
I just joined this conversation, so forgive me if you've already discussed this matter. Apparently there ARE export controls on public domain information. For example, the DES encryption algorithm is in the public domain, but the export of DES encryption programs is strictly forbidden, even to our friends in Great Britain. The products that my company, Sun Microsystems, ship overseas do not include des(1) or crypt(1). Crypt(1) has been a standard part of Unix for many years and methods for breaking it have been known for years. It provides minimal security. I was told that we are forbidden by the State Department to export those from the U.S. even though the algorithms are in the public domain. I could almost understand an export restriction on a DES chip since the fabrication of the chip itself might only be possible with technology that is restricted or if the performance of the chip exceeded that which is possible with existing "exportable" technology. But a program is just another way to express the algorithm that has already been published, albeit in a format that is machine readable. Besides, any one of our customers can reprogram the algorithm with the equipment that they are purchasing and with information that they can find in any descent library (here or abroad). If the DES algorithm had been published in C or Pascal, then one could imagine a situation in which we could export the source code, but not the object code. If I were really ambitious and smart enough then I could develop an expert system that could read the NBS description of the DES algorithm and "compile" it directly into 680X0 machine code. Then I would be confronted with a really ludicrous situation: I could export the NBS document and my expert system, but not the original binaries. I know, I know ... the State Department would restrict the export of my "specification compiler". So what's the deal? Is there any logic or reason to the export restrictions? Or do I have my facts wrong? Kent Klinner Sun Microsystems
henry@utzoo.UUCP (Henry Spencer) (10/17/86)
> So what's the deal? Is there any logic or reason to the export > restrictions? Or do I have my facts wrong? Not much reason or logic. The story I have heard is that the bozos at DEC were so incredibly stupid as to actually call the matter to the Feds' attention and ask them whether exporting crypt(1) and friends was all right. After a lot of confusion, the answer was -- predictably -- "no". -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
dyer@spdcc.UUCP (Steve Dyer) (10/20/86)
>Not much reason or logic. The story I have heard is that the bozos at DEC >were so incredibly stupid as to actually call the matter to the Feds' >attention and ask them whether exporting crypt(1) and friends was all right. >After a lot of confusion, the answer was -- predictably -- "no". I'm not sure whether this occurred before or after DEC's phone call, but all sites licensed for System V redistribution received a packet last year from AT&T with a letter from their legal staff describing the situation and listings of a new version of crypt(). -- Steve Dyer dyer@harvard.HARVARD.EDU {linus,wanginst,bbnccv,harvard,ima,ihnp4}!spdcc!dyer
dwl10@amdahl.UUCP (Dave Lowrey) (10/20/86)
In article <8251@sun.uucp> klinner@sun.uucp (Kent Klinner) writes: > I just joined this conversation, so forgive me if you've already > discussed this matter. > > Apparently there ARE export controls on public domain information. > For example, the DES encryption algorithm is in the public domain, > but the export of DES encryption programs is strictly forbidden, > even to our friends in Great Britain. > > The products that my company, Sun Microsystems, ship overseas do not > include des(1) or crypt(1). Crypt(1) has been a standard part of Unix > for many years and methods for breaking it have been known for years. > It provides minimal security. I was told that we are forbidden > by the State Department to export those from the U.S. even though > the algorithms are in the public domain. > The State Department forbid us to distribute the DES code in our UTS product to foreign countries. However, that restriction has now been lifted, and we send the same code to Europe, as we do to bour US customers. -- ------------------------------------------------------------------- Dave Lowrey "So it goes, so it goes, so it goes, so it goes. But where it's going, nobody knows" [Nick Lowe] ...!{ihnp4,cbosgd,hplabs}!amdahl!dwl10 [ The opinions expressed <may> be those of the author and not necessarily those of his most eminent employer. ]
karn@petrus.UUCP (Phil R. Karn) (10/21/86)
Just HOW is the government going to enforce export controls on machine readable information? Suppose I hop on a flight to London carrying a floppy disk. On this disk is the source to a DES program (substitute your favorite public-domain but "controlled" information here). However, reading it yields gibberish because I've encrypted it with a one-time-pad. The key disk is back home in a safe place (encrypted with a strong conventional cipher so the Feds can't read it should they raid my place). I won't take it across until the one I'm currently carrying makes it over safely. In such a situation, is it up to me to prove that the disk I'm carrying DOESN'T carry "controlled" information? Considering that lots of data must cross the Atlantic in many forms I can't imagine that Customs could demand to know the contents of every disk, tape or telephone call, for that matter. I would think that our government would take a lesson from the Communist countries and realize that "controlling" the flow of public information is impossible outside of a police state. The widespread ownership of personal computers by an informed public can represent a powerful safeguard against arbitrary government interference with personal communications; that's why the Soviet Union is scared to death of them. Phil
brecht@sask.UUCP (10/21/86)
> Apparently there ARE export controls on public domain information. > For example, the DES encryption algorithm is in the public domain, > but the export of DES encryption programs is strictly forbidden, > even to our friends in Great Britain. > > The products that my company, Sun Microsystems, ship overseas do not > include des(1) or crypt(1). Crypt(1) has been a standard part of Unix > for many years and methods for breaking it have been known for years. > It provides minimal security. I was told that we are forbidden > by the State Department to export those from the U.S. even though > the algorithms are in the public domain. > ... > So what's the deal? Is there any logic or reason to the export > restrictions? Or do I have my facts wrong? > > Kent Klinner > Sun Microsystems The restrictions are ludicrous. You can get the DES encryption document here in Canada -- I have it as an appendix in a computer science textbook of mine. If that is sufficient to write a DES encryptor, then any export controls on programs containing such an encryptor are futile. The restriction on exporting crypt is even more laughable. We've used it in Canada for years; the machine that I'm writing on has it. DES and crypt are *already* out of American hands. Export restrictions on those particular algorithms seem to be pointless hassling of American firms by the State Department. Jim Tubman (From the account of Tim Brecht) University of Saskatchewan Canada
henry@utzoo.UUCP (Henry Spencer) (10/21/86)
One is wasting one's time looking for sensible, reasonable explanations
for the US government's attitude to such things. There aren't any; the
government is paranoid about the issue, pure and simple. Trying to reason
with them about it is futile.
I recently read about one of the silliest examples yet. There was one
US experiment aboard one of the Soviet "Vega" Halley probes. It got there
through private cooperation between Soviet and US experimenters, not through
government initiatives, since things were pretty frosty at that time. The
funny part is that the Soviet scientists were puzzled about its lack of a
microprocessor. It was the only experiment aboard that didn't have its
own micro running it. The reason was that the US experimenter didn't want
to run afoul of US export bureaucrats at the last minute.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henrywegrzyn@cdx39.UUCP (Chuck Wegrzyn) (10/21/86)
While everyone has been discussing whether or not there are export controls, no one has forward the notion that it doesn't matter. Everyone has some amount of conscience, and it should come into play in determining what is done. Laws and policies that are stupid and useless ought to be violated. After all, the right of civil disobedience is an American right.
rwh@aesat.UUCP (Russ Herman) (10/22/86)
> Xref: watmath sci.crypt:11 net.sources.d:589 misc.legal:49 > In such a situation, is it up to me to prove that the disk I'm carrying > DOESN'T carry "controlled" information? Considering that lots of data must > cross the Atlantic in many forms I can't imagine that Customs could demand > to know the contents of every disk, tape or telephone call, for that matter. Let me add the point of view of a Canada Customs agent I encountered some years ago. I was bringing a 2400' reel of mag tape BACK to Canada. I had used it to transport a program to the U.S. When I got to customs, the agent there dutied me on the value of the tape. Now, technically he was correct, because there was no proof that I had in fact exported the tape. But in order to avoid this in the future, I attempted to find a way around this. The following conversation ensued. CC: We're dutying you on the value of the tape. We'd like to duty you on the value of the information, but we don't know that. Me: The tape has a serial # punched into the leader. If I register the tape before leaving the country, can I then bring it back duty-free? CC: No. It would have to be the same tape and the same information. The burden of proof is on you. Me (getting exasperated): Well, suppose I just transmit the data by telephone. CC (with a grin): When we figure out a way to duty that, we will. -- ______ Russ Herman / \ {allegra,ihnp4,pyramid,decvax}!utzoo!aesat!rwh @( ? ? )@ ( || ) The opinions above are strictly personal, and ( \__/ ) do not reflect those of my employer (or even \____/ possibly myself an hour from now.)
klr@hadron.UUCP (Kurt L. Reisler) (10/24/86)
You can go one step further. Why export what you can import?
I recently received a copy of a MS/PC-DOS Public Key Encryption
system that was written in Canada! We can't export the technology.
Why should we? If the outside world can't buy it from us, they
can just reinvent it and sell/give it to us.
--
Kurt L. Reisler
=============================================================================
UNISIG Chairman, DECUS US Chapter | Hadron, Inc.
..{seismo|sundc|rlgvax|dtix|decuac}!hadron!klr | 9990 Lee Highway
Sysop, Fido 109/74 The Bear's Den (703) 671-0598 | Suite 481
Sysop, Fido 109/483 Wash-A-RUG (703) 359-6549 | Fairfax, VA 22030
=============================================================================mdapoz@watrose.UUCP (Mark Dapoz) (10/26/86)
In article <597@hadron.UUCP> klr@hadron.UUCP (Kurt L. Reisler) writes: > > You can go one step further. Why export what you can import? > I recently received a copy of a MS/PC-DOS Public Key Encryption > system that was written in Canada! We can't export the technology. > Why should we? If the outside world can't buy it from us, they > can just reinvent it and sell/give it to us. This brings up a question I've been wondering about ever since this discussion started up. Everyone keeps talking about export controls on software distributed over the net. If someone over there (the US) decides that you shouldn't post a program to net.sources, does that mean I have to live by that decision here in Canada? As far as I know of (and I may be wrong), but there is no control over distrbution of a DES encryption program here in Canada. So what is there from stopping me from posting the program so that my fellow *Canadian* programers can use my work. You have to remember that this net also covers Canada, which is another county with many different laws than the USA. Just because my posting would spill over into the US shouldn't stop me from posting the program. Are there any laws for IMPORT control over the net? I sure hope not. Mark Dapoz mdapoz@watrose.UUCP
campbell@maynard.UUCP (Larry Campbell) (10/26/86)
I think all this worrying about whether to post DES code is a bit off
the mark. The relevant US export restrictions are stupid, repressive,
probably unenforceable on First Amendment grounds, and ought to be
violated at every chance. If the government were so obtuse as to
actually prosecute anyone for this, I would be glad to contribute
money to a legal defense fund; I suspect many other netters would be
too.
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
UUCP: {alliant,wjh12}!maynard!campbell 120 Fulton Street, Boston MA 02109
ARPA: campbell%maynard.uucp@harvisr.harvard.edu (617) 367-6846garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (10/28/86)
In a recent article karn@petrus.UUCP (Phil R. Karn) wrote: >Just HOW is the government going to enforce export controls on machine >readable information? By making threatening noises. Which will be sufficient to scare 99% of the computer companies in this country, judging by the postings about 'crypt'. If threatening noises aren't sufficient, public innuendo and name-dropping comes next (a la the Pornography Commission.) If *that* isn't sufficient, and if worse comes to worst, there's always selective and imaginative enforcement of the law. The bottom line is: if somebody in this country says "national security!", you jump. cynically, garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) (The opinions expressed above are indeed those of my company.)
jorgen@aahus.UUCP (Joergen Haegg) (10/30/86)
This is just a thought we came up with today:
It's legal to export an algorithm on DES, right?
Isn't the source code an algorithm that describes it
in a different form ? (And with no restrictions in export...)
Because you have to translate (read compile) this into a
machine readible form to make it run.
I know it sounds stupid, but is it really?
J|rgen H{gg jorgen@aahus.UUCPmatt@oddjob.UUCP (Matt Crawford) (10/30/86)
In article <7253@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >There was one US experiment aboard one of the Soviet "Vega" >Halley probes. ... It was the only experiment aboard that >didn't have its own micro running it. The reason was that the >US experimenter didn't want to run afoul of US export >bureaucrats at the last minute. It was built by U of Chicago physicist John Simpson, the foremost expert on dust-collection devices. He constrained himself to use ten-year-old technology throughout, in order to avoid any trouble with the state department. Oh well, at least one US experiment went to Halley! _____________________________________________________ Matt University crawford@anl-mcs.arpa Crawford of Chicago ihnp4!oddjob!matt
zeta@runx.OZ (Nick Andrew) (11/01/86)
> Perhaps somebody should simply post a copy of the source to the net and > then all the hassles will be over. I'm no lawyer, but as far as I'm aware, US laws don't apply to us here in Australia, and it appears the Canadians don't have any technology export laws either. I'm unsure of Australia's position on this, they'd probably lock them up for "endangering national security" [or some such bull] however I would not bet that the Russian's didn't already have the full text of both DES and crypt(1) methods, with 'C' source. In that case, the restriction is pointless. The average man in the street can't break the encryptions, so if I want to send steamy love letters to a girl in Boston via UUCP I consider it perfectly safe to use crypt(1). Neither the Russians nor the FBI would waste their time on it. For state or national secrets the Russians can simply send somebody to the USA to pick up the source code from any site with crypt(1) and a source license. You can find me at.... ACSnet: zeta@runx.oz UUCP: ...!{seismo,hplabs,mcvax,ukc,nttlab}!munnari!runx.oz!zeta Fidonet: Nick Andrew@[155/222] (Zeta), [155/213] (Sentry) Zeta: Sysop@zeta, (02) 627-4177, Zeta Rtrs, CCITT V21. Mail: P.O Box 177, Riverstone NSW 2765 Australia.
dik@mcvax.uucp (Dik T. Winter) (11/08/86)
In article <8221@watrose.UUCP> mdapoz@watrose.UUCP (Mark Dapoz) writes: >This brings up a question I've been wondering about ever since this discussion >started up. Everyone keeps talking about export controls on software >distributed over the net. If someone over there (the US) decides that >you shouldn't post a program to net.sources, does that mean I have to >live by that decision here in Canada? As far as I know of (and I may be >wrong), but there is no control over distrbution of a DES encryption program >here in Canada. So what is there from stopping me from posting the program >so that my fellow *Canadian* programers can use my work. You have to remember >that this net also covers Canada, which is another county with many >different laws than the USA. Just because my posting would spill over into >the US shouldn't stop me from posting the program. > I think the distribution 'not.usa' should be invented. -- dik t. winter, cwi, amsterdam, nederland UUCP: {seismo,decvax,philabs,okstate,garfield}!mcvax!dik or: dik@mcvax.uucp ARPA: dik%mcvax.uucp@seismo.css.gov