[FFmpeg-devel] [PATCH] G722 decoder

Diego Biurrun diego
Wed Mar 25 01:05:18 CET 2009


On Tue, Mar 24, 2009 at 01:16:05PM -0700, Baptiste Coudurier wrote:
> 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 ?

When you combine a program from differently licensed parts and
redistribute it, you have to comply with all licenses.  If you have 100
GPL v3 files and one file that is "redistribution forbidden", then you
cannot redistribute it.

If we have one LGPL v2.1 only file in FFmpeg and 500 v2.1+ files, we
similarly have to obey the licenses of all of them.  Since different
LGPL versions are incompatible, the only way to satisfy the requirements
is to use v2.1.  Thus the licensing terms of a single term effectively
apply to and limit the licensing terms of all of FFmpeg.

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

There are many who do not like GPL even for optimizations, the most
prominent example being Mans.

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

Kostya libswscale, Justin AC-3, Diego relicensing efforts + some others
that I don't remember offhand right now.  This is quite obviously more
work than cleaning up the G.722 decoder patch.

But this is not a constructive branch of discussion, let's drop it.

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

This is a misunderstanding then.  Sorry.

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

This is not my opinion, it is a statement of facts, namely

- Licensing issues are always a touchy topic.
- Licensing problems can be avoided by checking before starting to code.
- Kenan just saw what can happen when you do it the other way around.

> And I think it is time to state license acceptance for the FFmpeg
> project, so we can all be on the same page.

It has been stated quite clearly as point 1 of the development
guidelines:

http://www.ffmpeg.org/general.html#SEC27

You just choose to ignore this.

> I hope you are trying to quiet me because you are not agreeing with me.

I what?  This sentence does not make sense to 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.

See the history of the file libavcodec/x86/vc1dsp_mmx.c and the related
discussions on the mailing list.  If memory serves me right, it was
first proposed without an "or later" clause.  I cannot find the mail in
the online archives right now (did they get damaged), but the original
commit message contains some clues:

  add VC-1 MMX DSP functions, under MIT license.
  patch by Christophe GISQUET %christophe P gisquet A free P fr%
  original thread:
  date: Jul 7, 2007 12:52 PM
  subject: [FFmpeg-devel] [PATCH] VC-1 MMX DSP functions

Diego



More information about the ffmpeg-devel mailing list