From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_20,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!nike!ucbcad!ucbvax!SIMTEL20.ARPA!RCONN From: RCONN@SIMTEL20.ARPA (Rick Conn) Newsgroups: net.lang.ada Subject: Export Control and the ASR Message-ID: <12223244946.13.RCONN@SIMTEL20.ARPA> Date: Wed, 16-Jul-86 19:29:52 EDT Article-I.D.: SIMTEL20.12223244946.13.RCONN Posted: Wed Jul 16 19:29:52 1986 Date-Received: Sun, 20-Jul-86 04:07:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: The following is a message from Chris McDonald, as addressed to Frank Wancho and myself (released with permission). It is only slighly edited: Gentlemen, I read all of the messages. I fell vindicated that I with your cooperation had anticipated a concern which both Doug and Sam have expressed. First, if we agree--as we did in the matter of releasing the repository to foreign nationals and to foreign governments--that the repository consists of "public domain" material, then it is difficult to envision how export control regulations will be applicable. By definition, the US government is attempting to control the export of "significant and critical" technology. If that technology is in the "public domain," it would seem contradictory to belive that one can either control it or would want to control it. For example, the algorithm on the Data Encryption Standard (DES), used for the protection of unclassified sensitive data, is in the public domain. The algorithm is available to foreign governments and to foreign nationals, regardless of any political relationship to the US. Hardware devices, which implement the software implementation of DES, are export controlled because the "device" is not in the "public domain" given that individual companies have established patents and copyrights on their own products. It is also difficult to envision that someone would at this late date want to classify ADA software as "significant and critical" given that the whole tenor of the development has been to maximize public distribution. Second, my copy of the list of items to be controlled-- contained very inconveniently in a classified document--addresses broad categories of technology. ADA is not even mentioned. Third, we have documented our current releases procedures on the ADA repository to the extent necessary to meet Army requirements which in turn implement DoD directives. Four, before we get hung up on ADA, consider DDN itself. Last year I asked the DDN Project Office to answer a simple question on export control directed against the network itself. Specifically, since foreign nationals and foreign hosts access DDN, what about export control, particularly when "ftp" anonymous accounts exist throughout the network? I followed up three times and never got an answer. I gave up in total frustration. My point is that we have at least addressed the issue for ADA. I would propose that this has not been done for the network itself as a whole. Five, originators have the decision to determine what is "significant and critical" within the context of broad guidelines. System administrators can question originators or security types like me can question--as I did in the case of the repository. But, when originiators do not perceive any requirement to impose restrictions, and when we as administrators/security types can determine no policy requirement to impose restrictions, one has reached a point where one can legitimately and with a clear conscience say "ENOUGH!" It is nice to see other individuals expressing a concern which I share. I would think that in this particular case there is not a problem. -------