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

Sun Jan 13 11:41:38 UTC 2013

On Sun, 13 Jan 2013 08:25:29 +0100 Reinhard Tartler wrote:

> On Sat, Jan 12, 2013 at 11:26 PM, Francesco Poli
> <invernomuto at paranoici.org> wrote:
[...]
> > 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.

Well, actually it didn't say so explicitly, either...
It listed some GPL-licensed files and then it stated that the rest was
LGPL-licensed.
At the end there was that comment about libavcodec-extra-53, which
however seemed to only warn readers about that particular binary
package...

> 
> 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)

It's good that the upstream project web site points out this situation,
but, of course, it does not (and should not) say anything about the
packages in Debian.

> 
> > 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.

I think that the comment at the beginning of the debian/copyright file
should clearly explain the effective licensing status for each binary
package and the corresponding reasons.
If I find the time, I'll try to propose some precise phrasing, but I am
not sure when I'll be able to do so... Sorry about that.

> Especially as Jonas (and others) keep telling me that debian/copyright
> is only about the source package.

They are indeed right, generally speaking.

But when the effective license of binary package(s) is more restrictive
than it would seem to be by just looking at the debian/copyright file,
I think that a big warning should be put in a prominent place in order
to point out the situation.

What better place than the debian/copyright file to warn users about
some "surprising" licensing of binary packages?

Suppose I am the maintainer of another Debian package and I have to
assess whether it is legally possible to distribute that package linked
with some libav libraries.
The first things to check would be the libav library binary package
descriptions and the libav debian/copyright file.
Most people would stop there, without studying the libav build process
in detail and without recursively checking the debian/copyright files
and build processes of all the direct and indirect dependencies of the
libav libraries! 

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

I can understand, but in some "surprising" cases it maybe makes sense.
Especially when multiple binary packages built from the same source
package end up having different effective licenses...

[...]
> > 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.

Unless they depend on libavcodec-extra-* in their turn!
In that case they are also (indirectly) linked with Apache-2.0-licensed
stuff, and they also end up being effectively under GPL-3+ ...

[...]
> >  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.

No, no, I think that the source licensing should be clearly documented
(Debian Policy also mandates it).

> 
> 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.

So it's important to keep them enabled for those packages that do not
have any (licensing) problem in using them.

> 
> > 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.

Thanks for taking a look at the netgen bug report.
I'll try to followup there soon.

[...]
> > 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!

You're welcome.

I see that you followed up, copying debian-legal and netgen Debian
package maintainers.

Good, let's see if some other debian-legal regular has useful
suggestions (I am myself a debian-legal regular, but I have already
expressed my opinions on this issue; let's see what others have to say).

Bye and thanks again.

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20130113/92ebecf8/attachment-0001.pgp>