On 2015-12-12 00:03, Andreas Cadhalpun wrote:
On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
Well, the problem is that the answer may depend on the system.
If Nvidia offers Graphics Driver for download on its ftp server
for multiple operating systems, they are either system libraries
or not, I really don't see how this can depend on the operating
system.
For reference, here is the system library exception from LGPL-2.1 [1]:
"However, as a special exception, the materials to be distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable."
So in general, there can be operating systems were Nvidia's blobs
are normally distributed together with e.g. the kernel and others
were this is not the case.
I don't see any reason why the fact that these drivers
have to (or can) be downloaded by the user does not make them
system libraries.
When running ffmpeg on Debian (main), where these Nvidia blobs
are not present and not needed (because nouveau is used as driver),
no component of the operating system, major or not,
has been distributed with Nvidia's blobs, so the system library
exception does not apply.
I'm not sure about the situation for Windows.
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. I'm, instead, going to
ask why we're having this conversation about nvenc, when the qsx/mfx
situation is exactly the same. 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.
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.
Combining ffmpeg with proprietary libraries is covered under section 6
and
section 7, 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.
Note that I actually don't believe with have a GPL problem here, 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.
--phil
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
