On 12.12.2015 10:50, Hendrik Leppkes wrote: > On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun > <andreas.cadhal...@googlemail.com> wrote: >> 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. >> > > We should just add an exception into the license to explicitly allow > using it with the NVIDIA CUDA library and be done with this debate for > ever.
That would be an option. > You know that Open-Source has failed when the project itself is > arguing days and days for including a feature on license reasons that > any closed-source app would just write, enable and offer to its users > without a second thought. Please try to take a step back. The "nvenc" feature is already included in FFmpeg, just not enabled by default. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
