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

[Philip Langdale]

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:

The GPL controls distribution of the work and derived works because 
that's
what the licence can control. The nvidia cuda and nvenc libraries are 
clearly
not derived works of ffmpeg and the nvEncodeAPI.h is also clearly not a 
derived
work. The ffmpeg binary that results from including nvEncodeAPI.h is GPL
compatible because nvEncodeAPI.h is MIT licenced. 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.

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.

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.

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.

--phil