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

[Robert Swain]

2009/4/29 Diego Biurrun <diego at biurrun.de>:
> 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.

Sounds reasonable.

> But dropping libfaac support might be a better idea. ?Does anybody need
> it for internal development? ?Kostya, Rob?

I haven't touched the AAC encoder yet so it's up to Kostya and Alex in
my opinion. I have used it to generate streams for benchmarking in the
past, but I can just as well use the FAAC CLI. It would be more of an
annoyance for converting to h.264 + AAC in mp4 really.

If we drop it, I'm sure it will wreak havoc in #ffmpeg and we'll
either have to tell them to use a specific revision or use 0.5. We're
already telling people to use 0.5 for vhook because libavfilter isn't
done yet.

So I'm not keen on dropping it until a replacement is ready, because
it is heavily used. Maybe it depends on how close our encoder is to
being ready for trunk and whether dropping FAAC will actually bring
about any incentive to the developers working on the AAC encoder. I
somehow doubt it will affect Kostya that scores of people in #ffmpeg
and on FFmpeg-user are wondering why libfaac support has disappeared.
:)

Regards,
Rob