Bug#658084: libav-extra: Really necessary?

[Reinhard Tartler]

On Di, Jan 31, 2012 at 10:37:23 (CET), Fabian Greffrath wrote:

> I'd like to start a discussion about this package by means of this bug report.
> Honestly, I do not see the purpose of this package and while I appreciate the
> work Reinhard has done with it, am not sure where it will bring us.
>
> First, as pointed out in 653451, this package offers merely two additional
> codecs compared to the regular libav packages. One is a (redundant?) AAC
> encoder and the other one is an AMR-WB encoder. Quite exotic if you are asking
> me. I'd say, if you really need these codecs, rebuild the libav package - it's
> all in the archive.

Well, I strongly disagree that both are exotic or fringe codecs.  The
ffaac (the internal AAC encoder) is still not in a shape that you really
would want to encoder your music collection (quality wise), and AMR is
widely used on mobiles. I strongly disagree to tell users to rebuild
their libav packages. They would rather go to dmo and notice later that
their installation get messed up.

> Second, the reason why these codecs are not enabled in the standard libav
> package is AFAIUI their licensing, which would require the GPL-v3 to apply for
> the whole of the libav libraries - in contrast to GPL-v2+ without these codecs.
> This might lead to some legal problems when linking with software licensed
> under GPL-v3-incompatible terms (right?).

That's correct.

> However, I think what we are doing with libav-extra is a bit insincere. We
> pretend to play fair by only building packages against the GPL-v2+ libav
> libraries but then offer the possibly license-incompatible GPL-v3 libraries
> from the libav-extra packages for runtime linking.

So why is that insincere? What's the problem with that?

> TL;DR I think we should either enable the additional codecs in the regular
> libav package, accept the license bump and analyze the license problems that
> might occur with other packages.

Feel free to go ahead with that analysis; merging or dropping libav is
not a blocker for this.

Btw, Andres suggested that we could build additional GPLv3 flavors from
the libav package. I feel uncomfortable with this as well, as a) this
will *double* build times (all existing flavors have to be built twice,
one time with GPLv3 packages enabled and disabled) and b) libav-extra
has an additional purpose in Ubuntu, which lacks some additional library
packages in main:

https://launchpad.net/ubuntu/precise/+localpackagediffs?field.name_filter=libav&field.package_type=all&field.package_type-empty-marker=1

The libav-extra package brings here all additional, missing codecs,
which may or may not be GPLv3.

> Or we should accept the fact that there are potential license problems
> and disable these two offending codecs altogether.  The current
> solution with two libav* packages is not a stright line IMHO.

I still fail to see what the problem is. I understand that you don't
like the approach, but maybe you can elaborate on the 'insencere' or
'not straight' part.

Cheers,
Reinhard
-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4