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 _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
