[FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 10.12.2015 15:18, Philip Langdale wrote:
>> On 2015-12-10 06:05, Andreas Cadhalpun wrote:
>>> On 09.12.2015 17:38, Hendrik Leppkes wrote:
>>>> On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler <timo at rothenpieler.org> wrote:
>>>>> If I understand carl right, the question is not about the header, but
>>>>> about if dlopen'ing a non-free library, the CUDA and NVENC ones in this
>>>>> case, makes ffmpeg non-free, or if they are system libraries and thus
>>>>> it's ok to link against them.
>>>>>
>>>>
>>>> The generated binary contains no non-free code, not even used a
>>>> non-free header, nor does it depend on any non-free binary to run.
>>>
>>> Well, most of the binary code generated from nvenc.c requires the
>>> non-free libcuda.so and libnvidia-encode.so.1 blobs to run.
>>>
>>>> And even if you want to cite that particular rule - if drivers are not
>>>> considered part of the system, then I don't know what is.
>>>
>>> What is a system library depends on the system.
>>> For example, Debian (main) does not even include libcuda or
>>> libnvidia-encode, so they certainly cannot be system libraries there.
>>
>> I am not a lawyer, etc, so make of this what you will, but:
>
> Neither am I and I'm not giving any legal advice here.
> I just wanted to point out that the system library exception obviously
> doesn't apply and since your rationale below doesn't mention it,
> I think you agree.
>
>> The GPL controls distribution of the work and derived works because that's
>> what the licence can control.
>
> Agreed.
>
>> The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg
>> and the nvEncodeAPI.h is also clearly not a derived work.
>
> True.
>
>> The ffmpeg binary that results from including nvEncodeAPI.h is GPL
>> compatible because nvEncodeAPI.h is MIT licenced.
>
> I'm not sure it's that easy. If that were correct, it would become
> GPL-compatible to distribute a GPL-licensed program linked with a
> proprietary library by simply inserting a MIT licensed header in the middle.
>
>> The only time the GPL ffmpeg and the proprietary licenced nvidia libraries
>> are combined is on the end user system so no distribution occurs, so the
>> GPL language doesn't apply at that stage.
>
> However, the object code compiled from nvenc.c would get distributed as part of
> the ffmpeg binaries, which is governed by the GPL.
>
>> The whole deal with proprietary drivers for the linux kernel is controversial
>> because the proprietary driver can be considered a derived work of the kernel
>> because it implements kernel interfaces and uses kernel code and is intended
>> for use with the kernel. Clearly the nvenc library and API have no relationship
>> with ffmpeg - they are independently developed works with other consumers and
>> using them from ffmpeg does not change this fact.
>
> That's unrelated to the problem at hand.
>
>> Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to
>> modify or replace any part of ffmpeg as they wish, including modifying it to
>> no longer have anything to do with nvenc.
>
> Including nvEncodeAPI.h is not causing the license problem, distributing the
> object code generated from nvenc.c is.
>
>> So really, I'm not sure what the rationale is for thinking it's a GPL violation
>> to include the MIT licenced nvEncodeAPI.h and to distribute a binary with nvenc
>> support in it. I'd be interested to hear the reasoning.
>
> The GPL-3 requires that the 'Corresponding Source' of the distributed object code
> is also distributed. This is defined as [1]:
> The “Corresponding Source” for a work in object code form means all the source
> code needed to generate, install, and (for an executable work) run the object
> code[...]
> For example, Corresponding Source includes [...] the source code for [...]
> dynamically linked subprograms that the work is specifically designed to require,
> such as by intimate data communication or control flow between those subprograms
> and other parts of the work.
>

This rule does not apply to system libraries, which I still am quite
sure a hardware driver would fall under (and we can argue about that
all day, you won't get any "proof" either way)
If a particular system does not actually package this particular
library, then their distribution of FFmpeg should probably just not
enable nvenc, its of no use without the library anyway.

You could argue the same thing for QuickSync, the only difference is
that it depends on some sort of "dispatcher" library that sits between
FFmpeg and the closed-source library.
Does the existence of a tiny dispatcher library suddenly "fix" these
rules? That would be silly. Yet it is widely accepted that linking
against libmfx for qsv is fine.

- Hendrik