[FFmpeg-devel] [PATCH] G722 decoder

[Baptiste Coudurier]

On 3/24/2009 12:31 PM, Diego Biurrun wrote:
> On Tue, Mar 24, 2009 at 11:05:48AM -0700, Baptiste Coudurier wrote:
>> 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: 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.
> 
> This is not correct, it does.  With the or later clause you have a 
> choice of applying the terms of LGPL v2.1 or v3, without it you can
> only use v2.1.  This is a restriction and it applies to all of
> FFmpeg, not just that single file.

How can this apply to all of FFmpeg ? Can you please point exactly the
terms where it does state so ?

>> I _might_ cause problem if someone decides to relicense our code
>> in another license.
> 
> What problems do you intend to cause and who do you think would 
> relicense?



>>>>> 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.
> 
> We accept MIT/ISC/BSD-like because they are more liberal than LGPL
> and completely compatible with all versions of LGPL.  The issue of
> GPL code is quite contentious.  There is considerable effort going on
> to change the parts we have into LGPL, especially parts that are not 
> optimizations.  Even accepting GPL optimizations is controversial.

Converting license to GPL is controversial, however accepting GPL
optimizations is perfectly fine with me, and many others.

>>>>> 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.
> 
> I don't have that amount of time available.
> 
> Also, this is not about just the time I invested, you continue
> misquoting me.  Kostya reimplemented parts of libswscale, Justin just
> reimplemented a part of the AC-3 decoder to make them fully LGPL,
> just to name two recent examples.  It's rather you who should back up
> your claim that this was less work than cleaning up the G.722 patch.

Did I claim anything regarding time ? I don't recall doing so, however
you did, and I'd like you to backup your claims.

> As a sidenote, your disregard (sometimes bordering on contempt) for 
> non-coding parts of the work done on this project is not constructive
> at all.

How is so ? Can you please again backup your claims, by pointing to
something I might have said ? I don't recall disregarding work regarding
documentation, release packaging, extensive testing system (FATE), did I ?

Why am I trying to package the win32 mingw build ?
Why do you think I want 3 months releases ? Why do you think I'd like
the most stable state possible for the release, to avoid throwing
garbage to users ?

> We have no shortage of people working on format support.

I believe we are always short on people working on format support.
Any help is really welcome.

> But the needs of the project are multifaceted and require different
> people with different kinds of skills and interests.  What makes us
> strong is the combination of our efforts.

Here I definitely agree with you.

> A few things (just a selection, not a complete list) receiving far
> too little credit that I would like to highlight are Stefano's
> diligent work on smoothing API and documentation oddities and Rob
> website redesign, Compn's hunt for bugs and weird samples, the love
> roundup is receiving from Carl Eugen and the great work Mike is doing
> on FATE.

I again definitely agree with you, and I'd like to thank them for their
efforts.

> None of this is format support, but we could rather cope with the
> loss of the last few formats that were added than their efforts.

I don't agree at all, this is not about choosing something over
something else. This is about accepting more things than we do
currently, without removing anything.

>>>> 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.
> 
> Call it what you wish, the effect is the same.  Licensing issues are 
> always a touchy topic, just look at the size of this thread and the
> heat of the discussion.  It is best to check these things up front to
> avoid such complications.  This is the trap/issue/whatever that
> Kenan encountered.  And encounter it he surely did.

Again, that is only your opinion, it is not mine.
And I think it is time to state license acceptance for the FFmpeg
project, so we can all be on the same page.

>>> 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.
> 
> You will have to forgive me for resenting your flaming about this
> topic so late in the game, though.  If this had been an issue you
> really cared about, I would expect you to have noticed earlier.

I should have raised them sooner, indeed. However this is not really a
reason to stay quiet now. This issue is raised once again, and this time
I feel the need to express my wishes. I hope you are trying to quiet me
because you are not agreeing with me.

>>> 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.
> 
> We completely agree that this is the overarching main goal.  However,
> we clearly do not pursue this goal at all costs.  We have very
> strict criteria for accepting contributions and many patches linger
> outside of FFmpeg even though they would extend our format support if
> applied.
>
> Clearly, there is a tradeoff to be made here.  Ignoring licensing
> issues is very tempting in the short term, but you pay dearly down
> the road. It is not a good idea to go down that path.  We have to
> keep the long term well-being and success of FFmpeg in mind.

Again you are illustrating _technical_ reasons. I don't recall any patch
refused because of the license except this one, however I'm only in the
project since 3 years and I might have missed some, can you please point
me to other cases ? Thanks.

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