Hi, 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. William
Attachment:
signature.asc
Description: This is a digitally signed message part