[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.



On Mon, Nov 17, 2014 at 5:53 PM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
> Hi,
>
> On 13.11.2014 15:12, Fabian Greffrath wrote:
>>
>> Right, I believe there are many libavcodec-using packages out there that
>> are licensed under GPLv3 or similar licenses, whereas we forcefully keep
>> the default library package at GPLv2. Are there any counter-examples?
>
>
> Several packages using libavcodec are GPL v2 only:
>  * dff [1]
>  * hedgewars [2]
>  * openjfx [3]
>  * visp [4]
>
> There are likely some more.

Thanks for the research, that's indeed helpful.

>
> All of them have an alternative dependency on libavcodec-extra-56, which is
> strictly speaking a license violation.
> Probably appropriate Conflicts relationships between them and
> libavcodec-extra-56 are necessary.

Well, I've heard some claims about that, but I am not absolutely sure.
Libavcodec-extra-NN was definitly not present at compilation/link time
of any of the packages above. We also don't require users to use the
affected binary packages against libavcodec-extra-NN packages.
Technically, I also don't see Debian violating any license by allowing
this alternative dependencies.

What could be considered problematic is that users technically do a
license violation by installing libavcodec-extra-NN together with
GPLv2 only packages. On might construct a situation where some Debian
user creates an appliance that uses one of the packages above and
install libavcodec-extra-NN. I could imagine that this situation might
be problematic for that user.

What can we do about this in Debian? Well, I don't really feel like
maintaining a list of packages that are GPLv2 only in debian/control.
Instead, I'd very much prefer those packages to install a shlibs.local
file that avoids the alternative dependency on the -extra- flavor.

> However, I wonder if the few additional codecs in the extra package are
> worth all the additional complexity. How many actually use these codecs?

We used to ship x264 in the -extra- package, which is very popular. I
suppose that many users are very interested in the AAC encoders,
because the native encore inside libavcodec is of rather poor quality.
Also, AMR seems also be rather popular if you own a device that
requires that codec. I would say that effort is very much worth it!


Reply to: