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

[Phil Turmel]

Hi Lucas,

On 06/07/2011 10:49 AM, Soltic Lucas wrote:
> Hi Phil,
> 
> Actually I thought rule #2 was to avoid the license 'contamination' and give
> clear rules. If FFmpeg's HAS to be linked dynamically, why is it possible to
> build static libraries?

The checklist's introduction includes the statement "It is not the only way to comply with the license, but we think it is the easiest."

It is possible to comply with the LGPL in other ways, but you take it upon yourself to cross every legal 't' and dot every legal 'i'.

> The purpose here is to avoid having loads of dlls. Initially I was linking
> the static libraries to my own product. But I got issues with Visual Studio
> and wanted to give a try with dynamic linking. However I don't want the user
> to have to care about 5 dlls when he would actually need only one (and zero
> with the initial all-statically-linked-in-my-product setup).

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.

Why does the LGPL require this, you might ask?  *You* cannot distribute your app with GPL or non-free portions of FFmpeg.  Your end-user is not *distributing* your app, they are *using* it.  They are entitled to compile their own DLL with GPL or non-free codecs, insert that into your app, and uses those codecs with your app.  If your app queries the library for available codecs, and offers them to the user, all is well.

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.

In any case, if you want to go by the checklist, you need to keep the FFmpeg library in its own DLLs.

Again, IANAL.

HTH,

Phil