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

[Kostya]

On Wed, Apr 29, 2009 at 08:28:52PM +0530, Jai Menon wrote:
> On Wed, Apr 29, 2009 at 8:23 PM, Diego Biurrun <diego at biurrun.de> 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?
> >
> > It's no different than AMR, so we should require --enable-nonfree.
> >
> > But dropping libfaac support might be a better idea.
> 
> Dropping aac encoding support without having any roadmap or plan
> regarding when/how the native code will be merged doesnt seem like a
> good idea IMHO. Even then, iirc libfaac is one of the more complete
> implementations available now so dropping should be considered when
> ffaacenc has reached a certain maturity.
 
I agree. Current encoder is simply working - no good model or rate
control yet. Also the lack of SBR and proper multichannel support
make my encoder not even a stub replacement. Look at native Vorbis
encoder - who uses it?

I am in favour of dropping faaD2 support though. Our decoder should
become more feature-complete and looks like nobody cares for now.
 
> -- 
> Regards,
> 
> Jai