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

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

<br>
<br>
<br>
>>> I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible<br>
>>> with the packages since I have no packages requiring it nor use-cases<br>
>>> as a user requiring it, but I prefer the choice provided by by current<br>
>>> libav packaging.<br>
>><br>
>> Thanks for the support!<br>
>><br>
>>> Would it be hard to patch the build system?<br>
>><br>
>> To do what exactly?<br>
><br>
> To implement this in a dh7-style debian/rules file.<br>
<br><p dir="ltr">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.<br>
</p>
<p dir="ltr"><br>
</p>
<p dir="ltr">>> The current libav packaging already implements<br>
>> this in a way that the user can choose what packages to install.<br>
>><br>
>> On a personal note: The libav packaging can surely be improved and<br>
>> simplified. But throwing away years of work just because, and knowing<br>
>> about the regressions for the sake of simplicity feels wrong.<br>
><br>
> The main modernization would be a rewrite of the debian/rules file<br>
> in dh7-style. This naturally replaces the previous one.<br>
> The rest of the packaging is mainly declarative and can't be varied<br>
> that much anyway.<br>
><br>
> Not having the libavcodec-extra flavor is not only a regression<br>
> (having no AMR encoder), but also an improvement (simpler debian/rules,<br>
> no license incompatibility to worry about, faster build, ...).<br>
> I happen to think the improvement factor is bigger than the regression<br>
> factor, but others may disagree.<br>
</p>
<p dir="ltr"><br>
As Fabian points out, it is not only AMR, but (currently) also libvo-aacenc.<br>
</p>
<p dir="ltr"><br>
</p>
<p dir="ltr">--<br>
regards,<br>
    Reinhard</p>