Bugzilla Bug 202381

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 an attachment (id=141383) [details]
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...