[FFmpeg-devel] Apache licensed AMR library, patches

Reimar Döffinger Reimar.Doeffinger
Wed Apr 15 20:30:01 CEST 2009


On Wed, Apr 15, 2009 at 07:57:09PM +0200, Diego Biurrun wrote:
> On Wed, Apr 15, 2009 at 07:55:34PM +0200, Reimar D?ffinger wrote:
> > On Wed, Apr 15, 2009 at 07:35:54PM +0300, Martin Storsj? wrote:
> > > - The license of the codec code is Apache 2.0, which unfortunately isn't
> > >   (L)GPL2 compatible, afaik. It is compatible with (L)GPL3 though, and
> > >   it's at least legally redistributable, in contrast to the current
> > >   libamr-nb/wb.
> > 
> > Does it matter much? We would only be linking against those, so the only
> > case where I can see it matter is distributing a GPL v2-only application
> > together with libamr libraries.
> > I admit that there might be a bit of a problem if the AMR code could be
> > unintentionally linked in statically, but otherwise it would only be a
> > conflict between libamr and some other non-FFmpeg code and only if
> > distributed together, so does it concern us?
> > I admit this argument would have applied to the current libamr code,
> > too...
> > Of course it would also be possible to ask if the code be dual-licensed
> > as GPLv2+Apache or not...
> 
> You have the widespread but confused opinion that static or dynamic
> linking makes a difference.  It does not.

It does. If you distribute libavcodec.so statically linked against
AMR code you are distributing AMR code.
If you are distributing libavcodec.so dynamically linked you aren't.
Which might mean at least one group of people less who could sue.
It might also mean the difference between considering this a license
problem between libavcodec and an application (our problem) or one
between the AMR code and an application (not our problem).
Also while it has no relevance in this case, you statement in its
broadness is simply wrong, see clause 6b of the LGPL.



More information about the ffmpeg-devel mailing list