Select provider of libav* libraries

[Reinhard Tartler]

[short answer, I'm on the run]

On Thu, Jun 4, 2015 at 6:28 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> 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.

Reinhard