Return-Path: <push>
Return-Path: owner-openssl-dev@openssl.org
Received: from opensource.ee.ethz.ch (opensource-01.ee.ethz.ch [129.132.7.153])
	by brev.stacken.kth.se (8.9.3/8.9.3) with ESMTP id TAA02649
	for <levitte@stacken.kth.se>; Thu, 16 Mar 2000 19:56:46 +0100 (MET)
Received: by en5.engelschall.com (Sendmail 8.9.2) for openssl-dev-L
	id TAA12208; Thu, 16 Mar 2000 19:38:36 +0100 (MET)
Received: by en5.engelschall.com (Sendmail 8.9.2) via ESMTP for <openssl-dev@openssl.org>
	from drawbridge.eu.c2.net id TAA12183; Thu, 16 Mar 2000 19:38:26 +0100 (MET)
Received: from toilet.localnet ([192.168.2.37] helo=toilet)
	by drawbridge.eu.c2.net with smtp (Exim 1.92 #3)
	for openssl-dev@openssl.org
	id 12Vczn-00039V-00; Thu, 16 Mar 2000 16:19:35 +0000
Message-Id: <3.0.6.32.20000316183949.007ecc70@spectacle.co.nz>
X-Sender: geoff@spectacle.co.nz
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 16 Mar 2000 18:39:49 +0000
To: openssl-dev@openssl.org
From: Geoff Thorpe <geoff@geoffthorpe.net>
Subject: Re: [Eben Moglen <moglen@columbia.edu>] Re: US crypto export 
  restrictionsand GNU (fwd)
In-Reply-To: <38D12499.99A3BA88@certplus.com>
References: <Pine.WNT.4.21.0003090021290.-31249-110000@vaio.php.net>
 <38CDFEEC.9C9159BD@algroup.co.uk>
 <200003150456.VAA29971@aztec.santafe.edu>
 <E12V7R4-0002c0-00@old.law.columbia.edu>
 <38CFC136.8B8873FE@algroup.co.uk>
 <E12VIgR-00030m-00@old.law.columbia.edu>
 <20000316014140.A604@rho>
 <E12VUq1-000371-00@old.law.columbia.edu>
 <38D112C4.D3CD6897@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-openssl-dev@openssl.org
Precedence: bulk
Reply-To: openssl-dev@openssl.org
X-Sender: Geoff Thorpe <geoff@geoffthorpe.net>
X-List-Manager: OpenSSL Majordomo [version 1.94.4]
X-List-Name: openssl-dev

At 07:14 PM 3/16/00 +0100, you wrote:
>Ben Laurie wrote:
>> 
>> Eben Moglen wrote:
>> > In the worst case analysis, components exported
>> > now might subsequently become non-exportable in the event that
>
>> Perhaps I'm failing to understand here ... you say "No code not
>> originally developed in the US would be subject to..." but sure we're
>> talking about code that _was_ developed inside the US.
>
>Indeed. 
>If some code in open source project has been developed in the USA, then
>we must keep a trace of where it is to be able to remove it later in
>case the regulation in the US become more restrictive.
>
>So it does not propagate in the meaning that the european code never
>becomes unexportable, but in order to take advantage of that, we need to
>be able to "clean" it and remove all the american code in it at the
>moment we need to.

This effectively makes US supplied code unusable for OpenSSL except in the
form of "optional modules" that are, by nature, removable. The point seems
to be that US citizens can not involve themselves in regular development
for international development projects without infecting the projects with
US (re)exportation jurisdiction and controls. (Well exportation goes
without saying, but re-exportation is the relevant bit here I think - if
I've not missed the point by too far).

Please correct me if I've got it all mangled up ... :-)

Cheers,
Geoff



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majordomo@openssl.org