[FFmpeg-devel] [PATCH] G722 decoder

Baptiste Coudurier baptiste.coudurier
Tue Mar 24 18:02:07 CET 2009

On 3/24/2009 6:41 AM, Diego Biurrun wrote:
> On Mon, Mar 23, 2009 at 10:19:04PM +0100, Benjamin Larsson wrote:
>> Ronald S. Bultje wrote:
>>> On Mon, Mar 23, 2009 at 4:58 PM, Benjamin Larsson <banan at ludd.ltu.se> wrote:
>>>> Sure but I'm just trying to compromise so we just don't let this code go
>>>> to waste. Until we re license (when pigs fly or whatever) the code would
>>>> still be under LGPL.
>>> Yeah, it's true. The thing is, if ffmpeg is LGPL2.1 (or later) and the
>>> code is LGPL2.1, then requiring --enable-gpl for it to be compiled is
>>> funny.
>>> anyway, in the end yes I support your idea of not letting it bitrot.
>> We could add a --enable-lgpl2.1_but_not_later but I think that this is
>> an acceptable compromise.
> This means moving down a very slippery slope.
> Right now we have at least the following license types in FFmpeg:
> GPL v2 or later
> LGPL v2.1 or later
> BSD-type license variants
> MPEG proprietary
> libjpeg license
> This is off the top of my head, I might have overlooked some.  The
> intricacies of license compatibility can get arbitrarily complex and
> with every license or license variant you add, complying their terms
> becomes more difficult.
> As sad as it is to have to say this, I would be surprised if more than
> a handful of developers have read those licenses, not to speak of being
> familiar with their terms.  This thread clearly shows quite a bit of
> ignorance from core developers.

AFAIK, you are not a lawyer, are you ?

> Can you say if somebody has to be credited in printed FFmpeg manuals and
> if so, who and under what conditions?[1]  If you don't know the answer
> or don't even know how to find the answer, think twice about
> complicating things further.
> I hate to be forced to reject perfectly working code at least as much as
> the next guy, but we also want people to respect our licensing terms.
> Making them arbitrarily complex does not help.

Well, I'm sorry to have to say this, but you also got to respect other
developpers' choice. It a consensus cannot be reached, I'm afraid we
will have to vote.

I already stated my opinion here. I won't refuse any code under LGPL 2.1

> We have also put considerable effort into simplifying the licensing
> situation and we have come a long way.  libswscale now works in LGPL
> mode and our AC-3 decoder probably will soon.

Yes, LGPL is preferred. However there is no reason to be a license
zealot. Coding is fun, and our goal was always to support as many
formats as it exists in the world. Your fight is bringing us away from
our main goal.

> I have worked on getting people to relicense some parts of our code and
> addressed all complaints about FFmpeg licensing being vague and full of
> hidden mines that make people queasy about using FFmpeg.

Yes, I thank you for this. However if people does not want to relicense,
you got to respect this, and our choice to use their code conforming to
their choice of license, if we choose to do that.

> The work that went into licensing issues is far larger than the amount
> it took to implement this decoder and it should not be flushed down the
> toilet without even a second thought.

Why don't you step up to implement then if you claim it would take less
time ? Kenan is quite generous to step up implementing/adapting the
code, I don't see why we should refrain him.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list