[FFmpeg-devel] [PATCH] G722 decoder

[Baptiste Coudurier]

On 3/24/2009 10:51 AM, Diego Biurrun wrote:
> On Tue, Mar 24, 2009 at 10:02:07AM -0700, Baptiste Coudurier wrote:
>> 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 MIT ISC 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 ?
> 
> No.  How does this relates to what I wrote?

Your arrogance regarding knowledge relates.

>> I already stated my opinion here. I won't refuse any code under
>> LGPL 2.1 only.
> 
> The main problem is that the lowest common denominator is what
> counts. If we use a single v2.1 file, the or later clause of all the
> others is voided.
> 
> FFmpeg is a few hundred thousand lines of code, this G.722 decoder is
> a few hundred lines of code.  It is unfair for one small piece of
> code to restrict the licensing terms for the whole project.

It does not restrict the licensing terms of the whole project. I _might_
cause problem if someone decides to relicense our code in another license.

>>> 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.
> 
> Our main goal is not to support as many formats as possible *at all 
> costs*.  There are many functional patches that have not passed
> review for a multitude of reasons.  Just have a look at the list of
> interesting patches on the wiki.  Many of these are entirely
> functional.

And IMHO technical reasons are valid, license ones are _not_ (we accept
GPL/MIT/BSD) code, unless we _all_ agree so. I suggest we vote if you
are not satisfied with this.

>>> 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.
> 
> I have the utmost respect for other people's licensing choices.  It
> is their choice alone under what terms they release their code.
> However, it is our choice alone to accept those terms or not.

Yes, and I do accept the code as LGPL v2.1 only, now you don't, so let's
vote, please ?

>>> 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 ?
> 
> I have claimed no such thing.
> 
> I said that the combined time that I and others put into licensing 
> issues is larger than the time it must have taken Kenan to adapt
> this patch.  Throwing this work out of the window is not a good
> choice IMO. Neither will it help FFmpeg in the long run, nor motivate
> people to keep working on licensing issues.

How is this different that:
"The work that went into licensing issues is far larger than the amount
it took to implement this decoder"

You, again, claim it, so please step up and implement the g722 decoder,
in order to get valid proof to backup your claims, otherwise, please
stay quiet about time taken to implement things.

>> Kenan is quite generous to step up implementing/adapting the code,
>> I don't see why we should refrain him.
> 
> Kenan's efforts are welcome.  It is very unfortunate that he fell
> into a trap.  I wish he had checked the situation more closely up
> front and avoided the issue.

He did not fell into a trap, he may have fallen in something _you_ and
maybe others, consider a trap, I don't consider it a trap.

> Now there are two more things I would like to say:
> 
> If you do not wish to care about licensing issues, fine.

I try to care about licensing issues, that is why I raised my concern
about the "or later", this is a bit late, right, but I still have tools
to protect the future. Late is always better than never.

> But then you should aim for maximum license compatibility and
> licensing simplicity.

I aim the main goal of FFmpeg, that is the more features and the more
codecs and formats we support the better it is. License problems are
secondary issues for me.

[...]

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