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

[Tomas Härdin]

tis 2019-03-26 klockan 09:45 +0100 skrev Tobias Rapp:
> 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.

You can include LGPL code in a proprietary library if you provide the
object files for the proprietary parts, such that you can modify the
LGPL part and still link together a functioning library. I don't think
I've ever seen that done however

/Tomas