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

[Andreas Cadhalpun]

On 12.12.2015 01:46, Philip Langdale wrote:
> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>>> My point is that so far several people have said that if nvenc
>>> is a system library there is no issue (and I fully agree). I
>>> didn't see a mail (and even less a patch with a commit message
>>> that says so) that claims nvenc is a system library (only that
>>> it "should" be one).
>>
>> So let's ask: Is someone here who claims that nvenc is a system
>> library and can explain why?
> 
> I'm not going to claim it's a system library.

Interesting...

> I'm, instead, going to
> ask why we're having this conversation about nvenc, when the qsx/mfx
> situation is exactly the same.

We have this conversation, because someone sent a patch to enable it
by default, together with including the header and removing the
'die_license_disabled nonfree nvenc' line.

> The functionality is provided by a
> proprietary set of modules that are part of the intel driver on windows
> and a separate (almost undiscoverable) download on linux (actually,
> that's worse than nvenc where the functionality is shipped with the
> driver in both cases). The only structural difference is that ffmpeg
> links against a wrapper library for mfx and dlopens in the nvenc
> case, but because of your following statement, that cannot make any
> difference.

Since this requires the mfx wrapper to link, it is not enabled by
default. As the license situation seems similar, it might be a good idea
to add a 'die_license_disabled nonfree libmfx' line. But these don't have
any effect on the legal situation anyway, they are just a help
for our users.

>>> I am glad we agree that there is no difference (license-wise) if
>>> a library is linked statically, dynamically or via dynamic
>>> loading;-)
>>
>> There is that, at least. ;-)
> 
> Oh, and do you know what's funny - I just realised that the primary ffmpeg
> code base is LGPL and not GPL, so this whole conversation is slighlty
> pointless.

No, it's not, because the LGPL and GPL are very similar in terms of the
requirements about distributing object code of (L)GPL-ed source code.

> Combining ffmpeg with proprietary libraries is covered under section 6 and
> section 7,

These sections only cover "work that uses the Library" (defined in section 5),
not the Library itself.

> so even if building the nvenc codec is considered to combine
> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
> is that the LGPL covered parts can be rebuilt and modified as desired, and
> that is certainly true.
> 
> These sections are generally thought of as enabling a larger proprietary
> program to pull in an LGPL library, but the language is symmetric.

No, see section 4:
"You may copy and distribute the Library (or a portion or derivative of it,
under Section 2) in object code or executable form under the terms of Sections
1 and 2 above provided that you accompany it with the complete corresponding
machine-readable source code"

> Note that I actually don't believe with have a GPL problem here,

Why?

> but as a step forward, if we can all agree that the nvenc codec is a valid
> part of an lgpl build of ffmpeg, that's a step forward.

I don't agree with that interpretation, see above explanation.

Best regards,
Andreas