GnuTLS's libgnutls-extra is released under the GPLv3 license since version 2.2.0, and thus cannot link against GPLv2-only liblzo2. Flameeyes suggested to disable lzo when USE="bindist". The license problem affects only >=lzo-2.02, because previous versions are licensed under "GPLv2 or later".
This is odd. The COPYING file of lzo package specify "and later" clause. The source banner does not... What is stronger?
alonbl: COPYING and COPYING.LIB are meant to be the verbatim GPL and LPGL, while the source banner in files says while license the given file is actually covered by.
I don't think people are expected to enter each individual file in order to figure out the license of a package, what if there are two files with conflict license linked in the same library? This sounds crazy! Package should contain exception clause or update the generic license. Anyway, we can use the internal lzo of gnutls... And end this one.
(In reply to comment #3) > Anyway, we can use the internal lzo of gnutls... And end this one. > What do you mean by "internal implementation"? Is it a different implementation of the lzo compression algorithm or is it simply an internal copy of liblzo?
* Change from GPLv2 to GPLv3 for command-line tools, libgnutls-extra, etc. Notice that liblzo2 2.02 is licensed under GPLv2 only. Earlier versions, such as 2.01 which is included with GnuTLS, is available under GPLv2 or later. If this incompatibility causes problems, we recommend you to disable LZO using --without-lzo. LZO compression is not a standard TLS compression algorithm, so the impact should be minimal. Btw, I just talked with Markus and he were going to release a new version of liblzo under GPLv2+GPLv3 early next year. Still, I'm not sure if it makes sense for GnuTLS to enable LZO compression by default any more. It is not a standard TLS compression algorithm. What do people think? It would also be interesting to compare it with LZMA, which has gained some popularity lately: http://www.7-zip.org/sdk.html http://tukaani.org/lzma/ Btw, liblzo* has rather few reverse dependencies on Debian, so except for gnutls liblzo isn't that widely used. Dropping it might save space on most installation. I suggest that we disable LZO by default in the next releases unless someone protests. It would still be a supported feature though.
Opps... Unclear.... comment#5 is from upstream.
(In reply to comment #5) > [...] Earlier > versions, such as 2.01 which is included with GnuTLS, is available under > GPLv2 or later. So, seems that it's an internal copy, which is not a good thing afaik... > > Btw, I just talked with Markus and he were going to release a new > version of liblzo under GPLv2+GPLv3 early next year. > Ok, a GPLv2+GPLv3 release would be the best solution. Meanwhile we can add a "bindist" USE flag that disables lzo compression even if the user has USE="lzo". What do you think? > > I suggest that we disable LZO by default in the next releases unless > someone protests. It would still be a supported feature though. > As far as I can see, lzo is already disabled by default on Gentoo.
Fixed in 2.2.1, thanks!
Created attachment 141383 [details, diff] gnutls-2.2.1.ebuild.diff Can we please handle this a bit more gracefully instead of making the ebuild die?
Reopen...
Well... OK, but you get a different system than what you intended to...
