> > > >>> What is a system library depends on the system. > > >>> For example, Debian (main) does not even include libcuda or > > >>> libnvidia-encode, so they certainly cannot be system libraries there. > > >> >
Im not sure that Debian not including libcuda is a valid argument for it not being a system library as thats just one OS. To me thats the same as saying that win32 stuff is not part of a system library because Debian doesnt have it (for obvious reasons). So I dont believe that just because some systems dont have it doesnt stop it from being a system library. And if a system doesnt have the required propriety libs then they wont be loaded at runtime and therefore no proprietary code is ever used at all. > > The ffmpeg binary that results from including nvEncodeAPI.h is GPL > > > compatible because nvEncodeAPI.h is MIT licenced. > > > > I'm not sure it's that easy. If that were correct, it would become > > GPL-compatible to distribute a GPL-licensed program linked with a > > proprietary library by simply inserting a MIT licensed header in the > middle. > In this case thats not what is being said as we are not actually linking against anything. As if we did link against a propriety lib then you would be correct and this would brake GPL but that is not the case as the nvenc binaries are only accessed at runtime. All were doing here is including a single header file. > > The only time the GPL ffmpeg and the proprietary licenced nvidia > libraries > > > are combined is on the end user system so no distribution occurs, so > the > > > GPL language doesn't apply at that stage. > > > > However, the object code compiled from nvenc.c would get distributed as > part of > > the ffmpeg binaries, which is governed by the GPL. > The object code from nvenc.c is written using LGPL and just includes declarations (no actual code definitions) from a MIT header file which to me suggests that the part of ffmpeg that would be distributed is still GPL compliant. At no point during the entire compilation and linking stage is any proprietary component touched so I dont see how this brakes anything. So sorry for being verbose (and potential just stating the obvious) but the only argument here is whether we can consider the libs accessed at runtime as system libs or not. To use windows as a further example all the actual binary code required for nvenc to work is part of the graphics drivers. So the only time anything not GPL compliant is ever used is when the dll's are loaded at runtime from the driver. This definitely puts it in the category of a system component in my mind. If drivers are not considered system libs then we have far more serious problems than nvenc ;) Admittedly, we are solving someone else's problem, but the header is > buried inside the SDK download which is hidden behind a click-through on > nvidia's web page. So it's not made available in a way that is readily > consumable by an end user or by a distribution vendor. > > With the new licencing, a distro vendor *could* take the header and package > it up themselves, but that's the sort of them that's exceptionally hard to > convince them to do. > > And in the case of windows (where nvenc works too), there is no distro > vendor > and nvidia certainly won't make the header more accessible than it already > is. I agree with Philip here as the nvEncodeApi header is not part of a cuda sdk install and requires a separate download. One which is not as easily accessible and one that requires a good 90MB download just to use 1 header file. Since the header is all that is needed and it is not part of a standard sdk then I think the inclusion of avisynths headers already sets a precedent to also include this one. Including it also allows ffmpeg to ensure that the correct newer MIT licensed version is the only one being used. Of course this does put the burden on ffmpeg to ensure that the header is kept up to date but as long as someone does that then I support its inclusion (I dont see an issue with keeping it up to date as anyone adding new features will inherently update it and any breakage would be a result of the interfaces changing which would brake ffmpeg anyway). So the updated patch looks good to me. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
