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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
