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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
