Select provider of libav* libraries

Reinhard Tartler siretart at
Sat Jun 6 00:07:15 UTC 2015

[short answer, I'm on the run]

On Thu, Jun 4, 2015 at 6:28 PM, Andreas Cadhalpun
<andreas.cadhalpun at> wrote:

>>> I had considered producing optimized flavors, but I came to the conclusion
>>> that it would complicate debian/rules without much benefit, because
>>> the flavors are mostly unnecessary:
>> That's not only because of optimization, but also for licensing
>> issues: The lib*-extra-* packages are licensed with GPLv3+, which is
>> not acceptable for the majority of applications in debian.
>> Note that it does not matter whether or not there are GPLv3+
>> applications in the archive. These -extra- package do provide
>> additional functionality that users do appreciate. However, we cannot
>> provide that in the "standard" libav* packages because we do have
>> GPLv2-only applications that we must not link against a GPLv3
>> libavcodec.
> The current implementation of the extra flavor doesn't prevent using it
> with a GPLv2-only program and thus is effectively nearly as bad as just
> enabling the GPLv3 code in the standard build.

The keyword in this sentence is "using". I do NOT think we need to
prevent users from doing stupid things, but we must ensure that Debian
as a (re-)distributor does not violate any licenses. The dependencies
are set up in a way that ensures that all packages build against the
GPLv2+ variants, and nowhere on the buildds or on any other Debian
machine we distribute a piece of software that would be in violation
here. And that was the point of this exercise.

> Adding a mechanism to prevent this would make the extra flavor even
> more complex.

I don't think this is necessary. I doubt that many users would find
such a check actually helpful.

> As you can see from above numbers, even in the uttermost worst case,
> that is if both Michael and the Libav developers stopped working on
> the codebase, FFmpeg would still have more commits than Libav
> currently does.

Comparing an individual developer with a development team seems
inappropriate to me. Also, the chosen development processes of both
projects significantly affect the rate of commits. That comparison
does not appear useful.


More information about the pkg-multimedia-maintainers mailing list