[FFmpeg-devel] [PATCH] News: Removal of libndi

Tobias Rapp t.rapp at noa-archive.com
Tue Mar 26 10:45:26 EET 2019


On 25.03.2019 18:02, Jean-Baptiste Kempf wrote:
> On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:
>>> Most of those hardware libraries are glorified ioctls around the driver and shipped with the drivers.
>>> And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, set param" there, release the C++ interface).
>>>
>>> Matrox seems to do something else, though, introducing a special library for FFmpeg consumption, and I doubt that feels like a driver...
>>
>> The GPL is mentioned a lot in this thread. Maybe it would make sense to
>> distinguish the two cases where FFmpeg is compiled with --enable-gpl and
>> without it -- as the LGPL applies in that case.
> 
> That does not change a thing, sorry.
> The section 6 of the LGPLv2.1 is similar to the section 3 of the GPL, and mentions exactly the same limitations and exceptions for major components of the OS.
> 
> The fact that you can combine the library with a 3rd party library inside your program does not allow you to ship non-LGPL-compatible code inside the library. (The library must be changeable + redistributable by the user).
> 
> I know that means that you can do more or less the same feature, but that means the architecture must be different.

I thought that section 7 would allow to combine a 3rd party library with 
a LGPL library to create a new library but now when reading it again I 
stumble over the word "side-by-side" which indicates that the two parts 
should not interact with each other.

So yes, your interpretation looks correct to me (IANAL).

Regards,
Tobias



More information about the ffmpeg-devel mailing list