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

Re: Bug#485553: ITP: charybdis -- fast, scalable irc server


On Tue, 2008-06-10 at 11:21 +0200, Guus Sliepen wrote:
> On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote:
> > * URL             : http://www.ircd-charybdis.net
> > * License         : GPL
> > 
> > Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody
> > seems to care about that, I'm going to assume that it's OK.
> People DO care, and it is not OK. Linking with OpenSSL is only allowed
> if there is an exemption to the license of charybdis that explicitly
> allows linking to the OpenSSL. See for example this page which gives a
> nice summary and links to some related debian-legal emails:

It is likely impossible to add an exemption to most IRCd notable
exceptions include ngircd or inspircd, because some of the original
"ircd 2.8" contibutors are now dead.

Due to packet interception and logging, SSL support in IRC daemons is
becoming a hot topic. Without OpenSSL, packaging charybdis is pointless
for me, as the whole idea of packaging it would be to make it easier to
install on my systems. And without OpenSSL, it isn't easier for me to
install because I would have to rebuild the package with OpenSSL.

So, in a nutshell, nobody in the current IRCd development community
cares about perceived GPL+OpenSSL compatibility issues, so only Debian
does, which is "ok", but that's not so useful when Debian is already
shipping packages linked against OpenSSL with no exception (see below).

Here's some packages which are linked against OpenSSL and should not be
(this is not an all exhaustive list, you should grep-dctrl on a Sources
or something):

- epic4 (impossible to get an exception, dead contributors)
- inspircd would but I chose not to build that module because they ship
a gnutls one instead (charybdis is basically stuck with openssl due to
using libcrypto directly)
- oftc-hybrid (impossible to get an exception, dead contributors)
- openvpn (may or may not have exception, more checking needed)
- xchat (might be possible to get an exception, but author doesn't care
about GPL anyway, see also: Shareware XChat for win32)
- znc (status unknown, but i see no exception in the source)

So, in the grand scheme of things, I don't really think one more package
linked against OpenSSL is going to hurt anything.

If it makes you happy, I could bolt an exception on the code, but I
doubt it would hold water due to the fact that there are dead copyright
holders. But at the moment, porting to GnuTLS is really not an option,
as I would have to port to GCrypt too for the cert exchange, and that
couldn't be easily done with libgnutls-extra. I suppose using
libgnutls-extra and not supporting X.509 cert auth for gaining admin
access is an acceptable compromise provided that libgnutls-extra
implements enough of the OpenSSL API.


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: