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

[Andreas Cadhalpun]

On 10.12.2015 17:42, Matt Oliver wrote:
>>
>>>>>> 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.
>>>>>
>>
> 
> Im not sure that Debian not including libcuda is a valid argument for it
> not being a system library as thats just one OS.

The GPL defines a system library only in the context of a specific
operating system. So what is a system library differs from one OS to another.
Therefore one can't just claim something is a system library and thus it's
fine to use it, unless specifying the specific OS one talks about.

> To me thats the same as
> saying that win32 stuff is not part of a system library because Debian
> doesnt have it (for obvious reasons).

That's not correct, because Debian does have wine. ;)

> So I dont believe that just because
> some systems dont have it doesnt stop it from being a system library.

You're treating being a system library as something OS-agnostic, which
it isn't. A library can be a system library on Windows, but not on Android.

> And
> if a system doesnt have the required propriety libs then they wont be
> loaded at runtime and therefore no proprietary code is ever used at all.

But distributors of compiled nvenc still have to comply with the GPL.

>>> 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.
>>
> 
> In this case thats not what is being said as we are not actually linking
> against anything.

Linking via ld.so or dlopen isn't really different from a license point of
view.

> As if we did link against a propriety lib then you would
> be correct and this would brake GPL but that is not the case as the nvenc
> binaries are only accessed at runtime. All were doing here is including a
> single header file.

And again: including the header is not the problem.

>>> 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 object code from nvenc.c is written using LGPL and just includes
> declarations (no actual code definitions) from a MIT header file which to
> me suggests that the part of ffmpeg that would be distributed is still GPL
> compliant. At no point during the entire compilation and linking stage is
> any proprietary component touched so I dont see how this brakes anything.

However, running most of the generated object code from nvenc.c requires
the non-free blobs. And the GPL specifically also requires the source
code for libraries only required at run-time.

> So sorry for being verbose (and potential just stating the obvious) but the
> only argument here is whether we can consider the libs accessed at runtime
> as system libs or not.

Yes.

> To use windows as a further example all the actual binary code required for
> nvenc to work is part of the graphics drivers. So the only time anything
> not GPL compliant is ever used is when the dll's are loaded at runtime from
> the driver. This definitely puts it in the category of a system component
> in my mind. If drivers are not considered system libs then we have far more
> serious problems than nvenc ;)

Whether or not it's a system library on Windows doesn't matter for any other OS.

Best regards,
Andreas