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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel