[FFmpeg-devel] [PATCH] G722 decoder
Tue Mar 24 21:16:05 CET 2009
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
>>>> 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
>> 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
>>>>> 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
>>>> 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
>>>> 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
>> 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
> 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
> 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
> 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
More information about the ffmpeg-devel