On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > 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. >
And not enabled on any distribution, hence 99% of all users don't see it or get to use it. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
