Hello,

it has come to my attention that libktorrent trunk started linking to OpenSSL directly. Unfortunately, GPL is incompatible with OpenSSL license. I don't know the reason behind your choice of using OpenSSL directly instead of via QCA plugin infrastructure, but the change implies the following complications for distributors:

• libktorrent license is still GPL. It must at least be changed to GPL+OpenSSL exception or it won't be distributable.
• Likewise, everything that links to libktorrent (ktorrent and kget bittorrentfactory) can no longer be licensed under GPL (regardless of the libktorrent license). The license must at least be GPL+OpenSSL exception or software won't be distributable.

Therefore, as you see this change complicates distribution of kget bittorrentfactory (provided you can relicense ktorrent/libktorrent easily enough). My recommendation would be to either revert the change or talk to developers of applications using libktorrent about relicensing (which might not be very easy to do due to diverse copyrights).

Me too. Just when DHT was no longer a problem, this comes along.
As well as the problems Modax points out, directly linking openssl raises a package's profile to export control review, so it would be frozen earlier in a distribution release process. This is a problem for any distribution of the software by US based organisations.

kget bittorrentfactory plugin links to GPL'ed libkgetcore as well so the latter will need to be relicensed to GPL+OpenSSL exception too.

Nobody expects the license inquisition

Let me get this straight, if I use openssl indirectly via some sort of plugin loading mechanism, it's no problem at all. But if I just link directly, pandemonium ensues.

George wrote:Let me get this straight, if I use openssl indirectly via some sort of plugin loading mechanism, it's no problem at all. But if I just link directly, pandemonium ensues.

That's in fact an interesting question which has been bugging me for some time. George, what I can tell you for sure is that directly linking GPL (without exception) software with OpenSSL is really a license conflict. I'll try gathering more opinions inside Debian about libraries-plugins (dlopen() type) and reply to you. wstephenson, what do SUSE lawyers think about situation when GPL software loads a GPL incompatible library directly and/or indirectly via plugin?

In the meantime, George, could you tell us why you decided to dump QCA? According to QCA homepage, it has built-in support for SHA1 hash algorithm. If performance was the key, did you consider alternatives like GnuTLS or Mozilla's NSS which licensing have no problems with respect to GPL software?

I guess it must be fine, since Qt is doing it and QCA is doing it as well, and every other KDE app does it via these. I expect Qt's GPL contains an openssl exception clause.

wstephenson wrote:I guess it must be fine, since Qt is doing it and QCA is doing it as well, and every other KDE app does it via these. I expect Qt's GPL contains an openssl exception clause.

Yeah, but (lib)ktorrent GPL doesn't have an exception. As soon as there is at least one strict GPL in the chain, it does not matter if all other GPL components have the exception and/or if OpenSSL comes via LGPL or other more permissive license. Such a resulting bundle can't be distributed anyway. So the question here is if loading a library as a plugin or some other indirect way breaks "the chain". FSF seems to have quite extreme POV on this. There are other opinions however.

MoDaX wrote:In the meantime, George, could you tell us why you decided to dump QCA? According to QCA homepage, it has built-in support for SHA1 hash algorithm. If performance was the key, did you consider alternatives like GnuTLS or Mozilla's NSS which licensing have no problems with respect to GPL software?

I had some bugs indicating that there were some problems with the RC4 encryption. Looking at my RC4 implementation, I decided it was time to stop reinventing the wheel and switched to openssl. Then it occured to me that I could also use openssl for SHA1, and ditch QCA in the process. Both GnuTLS and Mozilla's NSS, don't appear to support RC4.

I don't mind adding an OpenSSL exemption to libktorrent's license. Adding a few lines of text to a file, is not much work.

George wrote:I had some bugs indicating that there were some problems with the RC4 encryption. Looking at my RC4 implementation, I decided it was time to stop reinventing the wheel and switched to openssl. Then it occured to me that I could also use openssl for SHA1, and ditch QCA in the process.

Yeah, I understand.

George wrote:Both GnuTLS and Mozilla's NSS, don't appear to support RC4.

Are you sure? Let's take Libgcrypt which GnuTLS depends on for its crypto functions. According to this comparison sheet (Encoding algorithms), RC4 should be supported (by all toolkits by the way). So isn't GCRY_CIPHER_ARCFOUR algorithm what you need?

George wrote:I don't mind adding an OpenSSL exemption to libktorrent's license. Adding a few lines of text to a file, is not much work.

But have in mind what wstephenson said and that kget developers will also need to relicense their application if they want to use libktorrent. So in the end, I don't think OpenSSL is worth the trouble if you can make other crypto toolkit work for your needs.

OK I have switched to libgcrypt, so no licensing changes needed.