[FFmpeg-devel] [RFC] Libfaac not LGPL?
Wed Apr 29 17:10:04 CEST 2009
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.
More information about the ffmpeg-devel