[Libav-user] Question about the libraries' naming and rule #16

[Soltic Lucas]

Le 7 juin 2011 à 17:29, Phil Turmel a écrit :
> Admirable intent, but you must make it possible for your users to substitute their own compilation of FFmpeg into your application.  Dynamic linking is the simplest way to satify that requirement of the LGPL.

What does LGPL exactly says about this point? I'm asking this because users CAN replace my static FFmpeg's libraries with their own, but they would need to recompile the library. Thus it's not the simplest way, but it's possible.

> Another case:  If your app hard-codes a specific codec, and the end-user wants a different one, they could modify their personal copy of FFmpeg to change codec IDs, and trick your app into using the alternate.  That's why you are obligated to permit reverse engineering of *your* code.

I do provide the source code of my library and the script used to build it. With this script the developer can exactly choose which decoders he/she wants to enable. If he/she ever wanted to modify the FFmpeg sources he can too. If he/she ever wanted to change the FFmpeg's version being used, it's possible too. There is nothing against changing the supported codecs, but at build time only. Once it's built, it's built.


Le 7 juin 2011 à 17:30, Alex Cohn a écrit :

> Kirill, it's no cheating to link all libav* static libraries
> (including swscale) into single dynamic library. That's exactly what
> rockplayer did for Android. It is an easy and clean way to avoid LGPL
> troubles.
> 
> Alex

From what you say, I suppose I shouldn't even care for that kind of issue, and should statically link my library against FFmpeg, as LGPL is not a problem to me. Actually I'm getting a bit lost between those who say it's possible, and those who say it's not (easily).

Lucas Soltic