[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: [CHRPM]

From: Petr Baudis
Subject: Re: lynx-dev Re: [CHRPM]
Date: Tue, 19 Nov 2002 21:51:10 +0100
User-agent: Mutt/1.4i

FYI, there _are_ some tiny notices about that in doc/README.ssl ;-).

Dear diary, on Sun, Nov 17, 2002 at 04:50:33PM CET, I got a letter,
where "Frédéric L. W. Meunier" <address@hidden> told me, that...
> BTW, from ELinks:
> "!BEWARE!  If you _distribute_ a binary of ELinks with OpenSSL
> linked to it, and the OpenSSL library is not part of your base
> system, you are VIOLATING THE GPL (although I believe that for
> this absurd case no ELinks copyright holder will sue you, and
> it's not a problem for the OpenSSL people as well, as they have
> explicitly told me).  So, people who are making ELinks binaries
> for systems with no OpenSSL in the base system and who decided
> to link OpenSSL against the ELinks binary may wish NOT to
> publish or distribute such a binary, as it's breaking GPL 2(b),
> if they like to have everything legally perfect (like Debian
> people ;).  As a semi-solution to this for those people, GNUTLS
> support was introduced; if you want to distribute ELinks
> binaries with HTTPS support, compile ELinks with the
> --with-gnutls configure option (assuming that you have GNUTLS
> 0.5.0 or later [tested with 0.5.4] installed).  However, as
> GNUTLS is not yet 100% stable and its support in ELinks is not
> so well tested yet, it's recommended for users to give a strong
> preference to OpenSSL whenever possible."
> What about Lynx ? I and a few people distribute SSL binaries
> for Windows / Cygwin.

Well that paragraph is maybe a little overhysterical about this. I had some
discussion with various people about this, let me summarize the points..

It's not illegal to distribute software source just referencing OpenSSL headers
and calling OpenSSL functions. It's not illegal to build such a software. It's
illegal to distribute software built in such a way - I understand it as it
already contains the stuff from the headers, which is under different license
(too restrictive for GPL in some ways).

Mostly you don't care, but it can be a problem and the main reason for me to
fix this was Debian - it's a no-go for them (they didn't care for a long time
as well, but recently they became much more picky about licenses) to distribute
such a thing ordinarily (basically, they'd spread it as "non-free"), and I
didn't want that ;-).

So, I added support for GnuTLS into ELinks, as it seemed totally unrealistic to
contact everyone who ever touched Links or ELinks. Sure, it's not as good as
OpenSSL (the library nor the support ;-), I just thought that people wanting
the cake would use OpenSSL, while those who wanted to be legally clean and
distribute ELinks binaries would just use GnuTLS. It's not ideal, but it was
the only reasonable solution I thought of.

Note that at the morning after night spent by implementing GnuTLS support they
announced OpenSSL wrapper for GnuTLS, so you should be able to link OpenSSL
programs against GnuTLS anyway. And I bet that at least Debian already links
lynx against GnuTLS ;-).

(Oh, BTW, I happen to maintain ELinks and I wrote that pararaph; after one
night of GnuTLS hacking..)

                                Petr "Pasky" Baudis
weapon, n.:
        An index of the lack of development of a culture.
Public PGP key && geekcode && homepage:

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]