IRCd-Hybrid with OpenSSL support in Debian: licences conflictresolution

[Alan LeVee]

Aurélien GÉRÔME wrote:
> On Sun, Sep 03, 2006 at 11:27:45AM -0400, Jon Lusky wrote:
>   
>> Changing the license is much easier said than done.  There are many
>> copyright holders in IRCD-Hybrid, many that predate the Hybrid project, and
>> changing the license would require approval by all of them.
>>     
>
> I guess you are right, IRCD-Hybrid GPL cannot be altered. It is pure
> GPL'ed, period. :)
>
> The only valid option which remains is to modify IRCD-Hybrid to use
> GNUTLS. Easier said than done too, but nearer to the reality. If
> everything is GPL'ed, there is no issue. I was exploring the "no
> coding" option, before starting to think of a GNUTLS port...
>
>   
>> The simplest solution is for Debian to include OpenSSL as part of their base
>> operating system, then there would be no licensing conflict if users linked
>> against OpenSSL. However, if someone would like to volunteer to modify
>> ircd-hybrid so that it can use either OpenSSL or GNUTLS, that would be
>> great.  
>>     
>
> OpenSSL is included in Debian, it is not the issue at hand. What is
> problematic is that we cannot legally link IRCD-Hybrid with OpenSSL,
> because of the pure GPL and OpenSSL Licence conflict. Debian is strict
> with licensing and I find it natural.
>
> Therefore, the Debian package will stay as-is with no SSL support by
> default, till someone or I start to port IRCD-Hybrid on GNUTLS. ;)
>
> Cheers,
>   
Aurélien; Jon:

I'm going to just sneak into this conversation here for a bit. I agree 
with the hindrances that the use of OpenSSL causes on the Debian 
distribution as I'm a Debian user myself and helped develop the client 
SSL implementation to the IRCD-Hybrid 7.x branch however GnuTLS would 
not be a viable option Client <-> Server even though it is for Server 
<-> Server because the problem is the few IRC clients that do exist that 
support SSL, use the OpenSSL libraries for their implementation and 
given that GnuTLS is rather particular about it's handshaking methods I 
ran into problems getting them both to behave properly (though this may 
have changed).

Plus GnuTLS requires a large unhealthy amount of the entropy pool which 
can cause problems for people running servers that have no input device 
hookups (on kernel 2.6 which lacks entropy sources and they sit in a 
server cage) and lack a hardware RNG which is why I chose OpenSSL for 
the Client <-> Server implementation so if they needed more secure 
entropy they could use an EGD.

I would support however the move to add the appropriate legal licensing 
marks but as for GnuTLS on a Client <-> Server level I don't think that 
will be realistically possible for awhile until all known SSL IRC 
clients (which some link against OpenSSL) can be effectively tested to 
see if they can handshake with GnuTLS and when the problems with kernel 
2.6 are resolved that created the severe entropy problems that GnuTLS 
doesn't handle well.

Alan


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-4, 09/01/2006
Tested on: 9/3/2006 12:54:18 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com