[FFmpeg-devel] [PATCH] G722 decoder

[Diego Biurrun]

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.

> 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.

> >>> 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.

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.

We have no shortage of people working on format support.  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.

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.

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.

> >> 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.

> > 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.

> > 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.

Diego