home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / c / 13647 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  4.0 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!ogicse!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!news
  2. From: scs@adam.mit.edu (Steve Summit)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: 1992 International Obfuscated C Code Contest winners
  5. Summary: U.S. export control nonsense
  6. Message-ID: <1992Sep14.164438.26697@athena.mit.edu>
  7. Date: 14 Sep 92 16:44:38 GMT
  8. Article-I.D.: athena.1992Sep14.164438.26697
  9. References: <268@talgras.UUCP> <18rk9eINNhcu@early-bird.think.com> <shrchin.716270955@reading>
  10. Sender: news@athena.mit.edu (News system)
  11. Followup-To: somewhere else
  12. Organization: none, at the moment
  13. Lines: 65
  14. Nntp-Posting-Host: adam.mit.edu
  15.  
  16. In article <shrchin.716270955@reading>, shrchin@csug.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
  17. > barmar@think.com (Barry Margolin) says:
  18. >> In article <268@talgras.UUCP> david@talgras.UUCP (David Hoopes) writes:
  19. >>> In article <1992Sep10.135002.25527@wraxall.inmos.co.uk> nathan@elberton (Nathan Sidwell) writes:
  20. >>>> As chongo stated, my entry can't be posted from the USA.
  21. >>> Why couldn't your program be posted from the U.S?
  22. >> I haven't examined it, but I'll bet... that posting it from the US...
  23. >> would be a violation of export control laws regarding munitions.
  24. > So what happens now that it has (I assume) entered the US via news?
  25.  
  26. It's my understanding, based on occasional reading in other
  27. groups (see below), that the U.S. export control laws regarding
  28. munitions are universally regarded as ludicrous by almost
  29. everyone who understands the issues, with the possible exception
  30. of the hypothesized high-level "spooks" in the NSA and elsewhere
  31. who perpetuate them.
  32.  
  33. Cryptographic software is still defined as a "munition," and
  34. export of munitions is very tightly regulated.  I think there's
  35. an exception in the case of cryptographic software which is
  36. already widely available internationally, but the exception is
  37. not enforced consistently, and I have heard of U.S. authors of
  38. intended-to-be public-domain cryptographic software finding
  39. themselves under the heavy boots of humorless "authorities" who
  40. weren't at all interested in the author's claims that what he was
  41. doing was legal.  Stupid as it sounds, the difference between
  42. chongo receiving some software from Nathan via private e-mail
  43. and then posting it (which chongo didn't do) and Nathan posting
  44. it from the U.K. whence it entered and then again left the U.S.
  45. (which Nathan did do) might well be significant.  Furthermore,
  46. now that Nathan has posted it, Americans might not even have to
  47. worry about distributing it (including via manual means).
  48.  
  49. Now, I thoroughly agree that it's hard to imagine some G-man
  50. monitoring comp.lang.c and arresting chongo over the IOCCC.
  51. But being under those heavy boots is excessively and
  52. excruciatingly unpleasant, so if Nathan's program really is
  53. "cryptographic software," I don't blame chongo a bit for being
  54. wary, especially since Nathan can post it with impunity.
  55.  
  56. Unfortunately, in between the people who'd like to see these
  57. things changed, and the people (the aforementioned spooks) who
  58. are apparently in a position to keep them in place, sits a
  59. government, and a public which it represents, both of which for
  60. the most part don't really understand and don't really care, so
  61. I'm pessimistic about the prospects for any real change soon.
  62. (The NSA is allegedly working hard to control the quality of
  63. publicly-available cryptographic software entirely within the
  64. U.S., and by "control the quality" I do not mean "assure that it
  65. is unquestionably of the highest quality possible.")
  66.  
  67. This obviously has nothing to do with comp.lang.c; I'd encourage
  68. anyone who is curious about these issues to check out a few
  69. groups such as comp.risks, comp.soc.privacy, misc.int-property,
  70. gnu.misc.discuss, sci.crypt, or alt.privacy.  (Don't just
  71. redirect followups to one of these groups; it's an old and
  72. somewhat tired debate there (just as e.g. null pointers are
  73. here)).
  74.  
  75.                     Steve Summit
  76.                     scs@adam.mit.edu
  77.  
  78. P.S. Please don't take any of my comments above on cryptographic
  79. software and/or munitions export controls as gospel; I'm hardly
  80. an authority on these matters.
  81.