On 10.12.2015 17:42, Matt Oliver wrote: >> >>>>>> 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.
The GPL defines a system library only in the context of a specific operating system. So what is a system library differs from one OS to another. Therefore one can't just claim something is a system library and thus it's fine to use it, unless specifying the specific OS one talks about. > 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). That's not correct, because Debian does have wine. ;) > So I dont believe that just because > some systems dont have it doesnt stop it from being a system library. You're treating being a system library as something OS-agnostic, which it isn't. A library can be a system library on Windows, but not on Android. > 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. But distributors of compiled nvenc still have to comply with the GPL. >>> 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. Linking via ld.so or dlopen isn't really different from a license point of view. > 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. And again: including the header is not the problem. >>> 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. However, running most of the generated object code from nvenc.c requires the non-free blobs. And the GPL specifically also requires the source code for libraries only required at run-time. > 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. Yes. > 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 ;) Whether or not it's a system library on Windows doesn't matter for any other OS. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
