[FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
andreas.cadhalpun at googlemail.com
Thu Dec 10 16:25:22 CET 2015
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.
> 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.
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 :
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
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.
Why should that not apply to the dynamically linked libcuda/libnvidia-encode?
More information about the ffmpeg-devel