Bug#694657: closed by Reinhard Tartler <siretart at tauware.de> (Bug#694657: fixed in libav 6:9.1-1)

[Reinhard Tartler]

On Sat, Jan 12, 2013 at 11:26 PM, Francesco Poli
<invernomuto at paranoici.org> wrote:
> [Thanks for your fast reply, and sorry for my late reply...]
>
>
> On Thu, 10 Jan 2013 18:44:11 +0100 Reinhard Tartler wrote:
>
>> On Thu, Jan 10, 2013 at 6:30 PM, Francesco Poli
>> <invernomuto at paranoici.org> wrote:
>> > On Thu, 10 Jan 2013 09:55:12 +0100 Reinhard Tartler wrote:
>> >
>> > [...]
>> >> Oh I'm sorry, I mixed that up. There is no clear answer on that
>> >> because it depends. Most of the files are LGPL, but some hand-written
>> >> assembler optimizations are GPL-2+. The configure script offers an
>> >> --enable-gpl switch that includes those GPL-2+ sources. We do enable
>> >> this switch for all packages we produce in Debian.
>> >>
>> >> In theory, we could probably also provide an LGPL build of libavcodec.
>> >> Fortunately, nobody has requested that so far.
>> >
>> > Wait, are you saying that those few GPL-licensed files:
>> >
>> > [...]
>> > |  Files: libavdevice/x11grab.c
>> > |   libavfilter/yadif.h
>> > |   libavfilter/vf_blackframe.c
>> > |   libavfilter/vf_boxblur.c
>> > |   libavfilter/vf_cropdetect.c
>> > |   libavfilter/vf_delogo.c
>> > |   libavfilter/vf_hqdn3d.c
>> > |   libavfilter/vf_yadif.c
>> > |   libavfilter/x86/yadif.c
>> > |   libavfilter/x86/yadif_template.c
>> > [...]
>> > |  License: GPL-2+~Libav
>> > [...]
>> >
>> > are compiled into, or linked with, each shared object (*.so) shipped in
>> > all Debian binary packages built from the libav source package?
>>
>> yes.
>>
>> > In other words, are you saying that all binary packages built from
>> > the libav Debian source package are effectively under GPL-2+
>> > (except for libavcodec-extra-* and libav-dbg, which are effectively
>> > under GPL-3+)?
>>
>> yes.
>
> Ouch!
> This is not clear at all, by reading the debian/copyright file and/or
> by looking at the binary package long descriptions!

Well, strictly speaking, I believe that at least libavutil might still
end up as LGPL effectively. But definitively  not libavcodec, which is
what matters in all practical cases, including netgen.

>
> Without intimate knowledge of the libav package build process, I just
> thought that those GPL-licensed files only ended up into the binary
> packages named after the directories where they live...
> Without digging into all the dependencies, I hadn't noticed all the
> cross linking among the binary packages built from libav...
>
> In other words, I thought that only libavdevice and libavfilter were
> under GPL-2+ and all the other libraries were separated enough to be
> under LGPL-2.1+ !

Sorry, that's wrong, it's GPL. I thought that the old debian/copyright
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/copyright;h=9ce50341783655e90ddd3f340cc3fa324c6d4386;hb=HEAD
was pretty clear on that.

Also, this is really something upstream should be concerned about. The
upstream homepage points out this situation *very* prominently:
http://libav.org/ (see the 2nd light-green box at the top)

> Now I even notice that a number of binary packages built from libav
> depend on libavcodec-extra-54, and are therefore effectively under
> GPL-3+ !
>
> I think that this should be explicitly and clearly documented in the
> comment at the beginning of the debian/copyright file and, probably, in
> the binary package long descriptions, as well.

Well, maybe you can suggest new changes to the new debian/copyright
file? I'm really unsure how to express the situation less ambigously.
Especially as Jonas (and others) keep telling me that debian/copyright
is only about the source package.

I'm not a big fan of adding licence terms to the binary package description.


>>
>> > Isn't there any binary package effectively under LGPL-2.1+?
>>
>> Exactly, we currently do not produce any LGPL'ed binary packages in
>> Debian. In fact, we never did. Technically we could, but that would
>> require significant additional complexity that I would prefer to avoid
>> unless absolutely necessary.
>
> I understand that the additional complexity is not welcome, but I
> expect that a good number of people would have probably already
> requested these LGPL-licensed binary packages, if the current situation
> were more apparent.
>
> Make no mistake, I am perfectly fine with a GPL-licensed library.
> But:
>
>  A) I am definitely less fine with a GPL-2-incompatible library
>     (as you know, GPL-3+ is not compatible with GPL-2)

that's why the GPL-3+ stuff is in -extra. The non-extra variants stay
with GPL-2.

BTW: We even used to have (and in fact, we still have in ubuntu) an
extra source package libav-extra exactly for this purpose.

>  B) it looks like a bit specious, when the library is under the GPL,
>     just because of a few files

Maybe it would be clearer if we didn't talk about LGPL at all? But
that would be a false statement.

These "few" files do contain some important optimization and
functionality. We really do not want to miss them in high-profile
applications sich as vlc or mplayer.

> Hence, whenever the GPL-licensed files may be excluded and the linking
> with other GPL-licensed libraries may be avoided, it looks like a good
> idea to also provide an LGPL-licensed (reduced functionality) variant of
> the library.
>
> Sometimes you have a program under LGPL-2.1+ which links with libav* and
> with a DFSG-free, but GPL-incompatible, library.
> While you are trying hard to persuade the copyright holders of the
> latter library to re-license under GPL-compatible terms, it would be
> useful to link the program with the LGPL-licensed (reduced
> functionality) variant of libav* packages, if at all possible...
>
> Please note that this is _not_ a theoretical example: see bug #618968.

Okay, I thought that this might happen at some point, but I did not
actively look for such cases (sorry, I really have better things to
do). I guess that this bug is pretty serious, and I would agree that
this would make netgen unsuitable for release.

Fixing this on the libav package side will not be easy. I'll elaborate
when I see the corresponding wishlist bug on that.

>
>>
>> > Please clarify, since this may heavily affect the resolution of
>> > licensing issues for other packages!
>>
>> I imagine. I hope this mail clarifies the situation!
>
> It does clarify, but I think the clarification should be visible to all
> the interested users, not just those who happen to read this bug log.
>
> I am therefore going to file a bug report suggesting you to clearly
> document this situation.
>

Excellent, thanks!


-- 
regards,
    Reinhard