[FFmpeg-devel] [PATCH] G722 decoder

[Baptiste Coudurier]

On 3/24/2009 5:05 PM, Diego Biurrun wrote:
> 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.

I definitely agree with this, but how does this relate to our problem
here ? We are definitely distributing under LGPL v2.1 according to the
README and COPYING.LGPL.

Besides, license in each file applies to the file when "copying",
copying _one_ file which has its _own_ license.

What I propose is to accept LGPL v2.1 only contributions, if someone
wants to copy this file he can copy it under "LGPL v2.1 only" if he wants.

Are we planning to relicense to LGPL v3 ? This means explicitly changing
COPYING.LGPL to v3.

Until we aren't planning to change COPYING.LGPL, there is _no_ reason to
not accept LGPL v2.1 only contributions IMHO.

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

Well, that makes one plus you, besides "not liking" is not "refusing".
Who accepts GPL optimizations ? Michael, Jason, Loren, and me so far.

That would mean 2 vs 4 for now. Let's count, and vote :)
Like I said, maybe more people does not want GPL optimizations, I'd just
like to make this clear once and for all.

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

I'm quoting you:
"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."

"implement this decoder" this would imply starting from scratch of course.
How much time do you estimate this work would take ?

How much time do you estimate work on relicensing ? Reimplementation is
relicensing, yes.

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

That's right.

> - Licensing problems can be avoided by checking before starting to code.

That's right. I'd like to point that I paid attention last time code was
ported from Xine to mov demuxer.

> - Kenan just saw what can happen when you do it the other way around.

But how does these arguments prove that this _is_ "a trap" ?

I suppose Kenan checked that license is LGPL, and therefore thought it
was ok, and YES it is ok _for me_ but NOT _for _you_.

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

Well, first what is the history of this policy ?

Then did I explicitly agreed to this policy ? I don't recall doing so
explicitly, of course that does not mean I doesn't agree with it.
I just checked the mail when I got my cvs account, michael did not
request this back in these days, now he does that is true.

In all ways, I might still try to change this one line of the policy, to
be more flexible regarding license.

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

I hope you are not trying to quiet me because you are not agreeing with
me. Sorry for the bad english.

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

Well, the author accepted another license that's fine and great I'd say.
Did we say we would refuse ?

In any case that makes two, and I should have indeed, jumped in this time.

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