On Tue, Aug 5, 2008 at 7:16 PM, Sebastian Good <
sebastian_at_palladiumconsulting.com> wrote:

> Date: Tue, 5 Aug 2008 23:29:24 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> Subject: Re: libcurl encryption dependencies
> To: libcurl development <curl-library_at_cool.haxx.se>
> Message-ID: <alpine.LRH.1.10.0808052324120.25080_at_yvahk3.pbagnpgbe.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> >> Hello all. I am trying to determine, for US Export Control purposes,
> whether
> >> it is possible to build a version of libcurl which does not contain any
> code
> >> implementing encryption algorithms. I know we can compile (and even
> download
> >> pre-compiled) binaries which do not have SSL support. However I am less
> >> familiar with what libcurl-supplied encryption may exist in the many
> >> authentication options supported, e.g. NTLM, Kerberos etc.
> >
> >First, I don't even know what defines an "encryption algorithm" so I
> wouldn't
> >be able to answer the question very surely. For example we have an MD5
> >implementation included. Can that be seen as "encryption"?
>
> The Apache Foundation has a nice page discussing some export issues.
> Indeed digest algorithms such as MD5 are not "encryption" and so are not
> subject to export control. Are there any other implementations of
> cryptographic algorithms in libcurl?
>
> http://www.apache.org/dev/crypto.html
>
> > Then, if you really really want this information to be certain, can you
> really
> > just ask on a list on the internet and trust a random person who replies?
>
> Random people, perhaps not. The author of the package, yes. :-)
>
> > SSL (both HTTPS and FTPS) requires external SSL/TLS libs for encryption.
> NTLM
> > requires OpenSSL (or native Windows) for the crypto functions.
> Kerberos/GSS
> > requires external libs for the encryption. SFTP and SCP require external
> libs
> > for encryption...
>
> This is just about the only information that's needed for most software
> like
> curl to be classified for export control. If the code to implement
> encryption
> algorithms (with the exception, as noted above, of one-way digests) is not
> included in the source code, we should be able to link to it. That pushes
> the question of export control to the libraries which would be linked to,
> e.g.
> Kerberos, OpenSSL, etc.

Theoretically, you could link to libcurl as much as you like, as long as you
instruct non-USA customers to download the appropriate libraries from
someplace else. It wouldn't matter if libcurl does or does not include
encryption, because it originates, and is readily available, outside the
USA. If you don't export it, you wouldn't be violating export controls...

I'm not any kind of lawyer though, so consult one for real advice. :)

Ralph Mitchell
Received on 2008-08-06