[Ffmpeg-devel] Re: uninstall target

Måns Rullgård mru
Thu Aug 25 15:21:39 CEST 2005

Michel Bardiaux said:
> M?ns Rullg?rd wrote:
>> Michel Bardiaux said:
>>>M?ns Rullg?rd wrote:
>>>>Michel Bardiaux said:
>>>>>Rich Felker wrote:
>>>>>>On Thu, Aug 25, 2005 at 12:39:56AM +0000, Burkhard Plaum wrote:
>>>>>>>Reimar D?ffinger <Reimar.Doeffinger <at> stud.uni-karlsruhe.de> writes:
>>>>>>>>Maybe, though my guess is that installing only makes sense when you
>>>>>>>>build a dynamic libavcodec, which is not well supported in an aspect...
>>>>>>>It's gotten MUCH better. pkg-config support and the fixes of some
>>>>>>Fixing memleaks isn't very useful when every upgrade breaks abi or
>>>>>>even api...! lavc just is not intended for use as a shared lib at this
>>>>>But it is licensed as LGPL which means it is *supposed* to have a stable
>>>>Huh?  Licenses imply nothing whatsoever about API or ABI stability, or any
>>>>other usability factors.  Did you ever read the "as is" disclaimer?
>>>How is one supposed to use lavc while complying with LGPL? (rhetorical
>>>question) The answers one finds all over the web are
>>>(1) dynalink to lavc.so so that users of your app can enjoy successive
>>>releases of lavc by simply replacing the dso. This of course requires a
>>>stable ABI.
>>>(2) Statically link your app to lavc.a but distribute relocatable
>>>binaries of your app so that users blah blah by simply relinking your
>>>app. This of course requires a stable ABI.
>>>(3) Distribute your app with source. But then its no longer LGPL but GPL.
>>>In other words, LGPL without a stable ABI is a scam: you cant comply
>>>with it without acting as if it were GPL.
>> Have you read the LGPL?  It doesn't require that your an app using an
>> LGPL library must work with later releases of the library.  All that is
>> required is that whoever receives the application also can obtain the
>> source code of the library, and relink the application after possibly
>> modifying the library sources.  This is not the same as the application
>> working with any arbitrary modifications to the library.
> OOOOOkay, so it is enough to release our apps with relocatable binaries
> and a notice "compatible with ffmpeg cvs as of yyyymmdd"?

It would be enough to distribute the apps together with a copy of the ffmpeg
tree used to build them.  Simply pointing to the ffmpeg cvs repository is
not enough, since you cannot guarantee that it will be available for the
duration of the required three years.

> Mind you, my 3 points above may not be the *right* interpretation of the
> LGPL, but they're really what is implied by the vast majority of pages
> purporting to explain the LGPL.

The idea of the (L)GPL is that the user should be able to make modifications
to the program, and distribute these modifications to others.  Releasing
code under the (L)GPL is in no way a promise that future versions will
remain compatible.  Anyone suggesting something like that is wrong.

M?ns Rullg?rd
mru at inprovide.com

More information about the ffmpeg-devel mailing list