[FFmpeg-user] Applying the LGPL to ffmpeg usage
Carl Eugen Hoyos
ceffmpeg at gmail.com
Sun Nov 8 00:03:03 EET 2020
Am Di., 3. Nov. 2020 um 19:02 Uhr schrieb Carl Zwanzig <cpz at tuunq.com>:
> (changed the subject line)
> On 11/1/2020 12:07 PM, Carl Eugen Hoyos wrote:
> > If the question is "am I allowed to distribute a binary based on (L)GPL
> > software" then the answer does not depend on static or dynamic linking.
> That's not clear (to me), please point me to the relevant section of the
> LGPL and describe how it applies.
You are claiming that it would make a difference (which would make
no sense), I believe proving the opposite without understanding why
you believe that this is the case would be very difficult for me.
If you distribute binaries based on FFmpeg source, your obligations
may be different depending on the question if you distribute a statically
linked or dynamically linked binary.
But the general question if there is a way to produce a legal distribution
does not depend on the linking.
> > Am Mo., 26. Okt. 2020 um 06:44 Uhr schrieb Carl Zwanzig <cpz at tuunq.com>:
> >> There are cases where you can share a dynamic build (no GPL parts) that
> >> links to non-free libraries but not a static build. (I think building with
> >> BMD Decklink support is in that catagory.)
> > No.
> That is not clear what it refers to.
The question if you are allowed to distribute a certain build does not
depend on static vs. dynamic compilation.
> > Decklink is not GPL-compatible.
> We know that the BMD code itself is not _GPL_ compatible (although the
> headers & api appear to be), but when ffmpeg is built with NO GPL the LGPL
> would apply. By my understanding of that license, you can both dynamically
> link -to- LGPL code from proprietary code and link -from- the LGPL code to
> proprietary*. The only questions is whether ffmpeg's CLI front-end is
> considered a "library" for the purposes of the license and how the
> proprietary parts are distributed.
> *Note- that does not, and should not, imply that the libraries are being
> _distributed_ together.
I am not sure what you are trying to say.
(It sounds as if you might be arguing that as long as you don't distribute
them "together" it doesn't matter against which libraries you link your
FFmpeg-based binary, this would not be correct.)
> It would certainly be compliant to write one's own code and dynamically link
> to both LGPL and proprietary libraries (and to distribute the result), and
> that appears to be commonly accepted by other opensource projects (e.g OBS,
> CasparCG, MLT, etc; they have plugins for both BMD and NewTek NDI).
My argumentation above was that Decklink is not GPL-compatible,
I did not claim that any library (including Decklink) is not LGPL-compatible.
If you believe that my comment above does not really match the question
asked, this is absolutely possible: After all, I didn't understand your
original claim (that linking would make a difference), so I may have
misunderstood the relation to building with Decklink support.
I appear to originally have read that you argue that linking something
(Decklink?) dynamically somehow makes it GPL-compatible. We seem
to agree that this is not the case.
If you originally wanted to argue that you have to link dynamically to fulfill
the obligations of the LGPL when linking FFmpeg against Decklink then
this is also not correct (but fulfilling the obligations can be more difficult
for static distributions).
More information about the ffmpeg-user