[FFmpeg-devel] [RFC] Libfaac not LGPL?

[Jai Menon]

On 4/29/09, Diego Biurrun <diego at biurrun.de> wrote:
> On Tue, Apr 28, 2009 at 04:45:58PM +1200, Paul Kendall wrote:
>
> > On Tuesday 28 April 2009 12:48:50 pm Michael Niedermayer wrote:
>  > > On Mon, Apr 27, 2009 at 04:45:37PM -0700, Jason Garrett-Glaser wrote:
>  > > > We had some discussions on #ffmpeg-devel and I asked the folks at #gnu
>  > > > about this:
>  > > >
>  > > > http://faac.cvs.sourceforge.net/viewvc/faac/faac/libfaac/tns.c?r1=1.8&r2=
>  > > >1.9
>  > > >
>  > > > It appears that libfaac, despite declaring itself LGPL2.1, contains
>  > > > quite a few licenses... many of which are completely incompatible with
>  > > > the LGPL, such as the above.
>  > > >
>  > > > In theory, it still may be legal to distribute, as the LGPL linking
>  > > > exception *may* cover the linking of .c files with non-free licenses
>  > > > with .c files that have free licenses.  However, either way, this
>  > > > places FAAC squarely under non-GPL territory... such that ffmpeg
>  > > > should require --enable-nonfree to link to it.
>  > > >
>  > > > Thoughts?
>  > >
>  > > moving it under non free is a good idea, droping it is a good idea too
>  > > but i guess people wont like it being droped.
>  > >
>  > > [...]
>  > Please, no, don't drop it! Until ffaac can do HE-AACv2 it is needed by
>  > folk that have DVB-T streams. More and more countries are using this
>  > format for their digital broadcasts.
>
>
> You are talking about libfaaD, the decoder, not the encoder.
>
>  But if many people need and use it, dropping it should speed up the
>  process of getting a replacement by leaps and bounds...

I _seriously_ doubt whether this kind of reverse psychology will work,
but thats just my opinion.

-- 
Regards,

Jai