Select provider of libav* libraries

[Reinhard Tartler]

On Sat, Jun 6, 2015 at 3:05 PM, Andreas Cadhalpun <
andreas.cadhalpun at googlemail.com> wrote:
> Hi Reinhard,
>
> On 06.06.2015 20:30, Reinhard Tartler wrote:
>> On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey <balint at balintreczey.hu>
wrote:
>>>> The problem is that Debian users must be allowed to redistribute it,
>>>> but as far as I understand it, it is not allowed to distribute e.g.
>>>> a live DVD with hedgewars and libavcodec-extra installed.
>>>> I also pointed this out in the previous discussion [1].
>>> I'm not absolutely sure, but IMO yes, such Live DVD-s would not be
>>> allowed, but it is a problem of live DVD makers to care about. Package
>>> maintainers can't and should not prevent this usage.
>>
>> Why would you think that distributing the packages libavcodec-extra
>> and hedgewars on the same Live media would create a derived work that
>> must fulfill all licenses?
>>
>> I fail to spot the problem here.
>
> The problem I see is run-time linking a GPLv2-only program with a GPLv3+
> library. I think this makes such a Live DVD undistributable, because the
> licenses are not compatible.

The problem is that neither of the involved licenses talk about "run-time"
nor "compile-time" linking. The point is the creation of a derived work.

You are right that in this situation, it is not clear at all of the live cd
is a derived work, or a compilation of independent works. The former would
be rather problematic, but my understanding is that a live cd is rather the
latter.


>> If you want to be extra careful, just install the regular GPLv2+
>> libavcodec package, which according to the dependencies of the
>> hedgewars package should work just fine.
>
> This wouldn't work if you also want to install devede, which depends
> on libavcodec-extra. (This dependency should probably be a recommends
> at most, anyway.)

I tend to agree.



>>> I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible
>>> with the packages since I have no packages requiring it nor use-cases
>>> as a user requiring it, but I prefer the choice provided by by current
>>> libav packaging.
>>
>> Thanks for the support!
>>
>>> Would it be hard to patch the build system?
>>
>> To do what exactly?
>
> To implement this in a dh7-style debian/rules file.

I do appreciate the dh7-style brevity for simple packages. But for complex
packages, such as libav that makes use of multiple compilation passes, I
found the provided abstractions that make it so attractive to use get
quickly in the way.


 >> The current libav packaging already implements
>> this in a way that the user can choose what packages to install.
>>
>> On a personal note: The libav packaging can surely be improved and
>> simplified. But throwing away years of work just because, and knowing
>> about the regressions for the sake of simplicity feels wrong.
>
> The main modernization would be a rewrite of the debian/rules file
> in dh7-style. This naturally replaces the previous one.
> The rest of the packaging is mainly declarative and can't be varied
> that much anyway.
>
> Not having the libavcodec-extra flavor is not only a regression
> (having no AMR encoder), but also an improvement (simpler debian/rules,
> no license incompatibility to worry about, faster build, ...).
> I happen to think the improvement factor is bigger than the regression
> factor, but others may disagree.


As Fabian points out, it is not only AMR, but (currently) also libvo-aacenc.


 --
regards,
    Reinhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150607/a866cb71/attachment.html>