[FFmpeg-devel] [PATCH] G722 decoder

[Baptiste Coudurier]

On 3/25/2009 6:16 AM, Diego Biurrun wrote:
> On Tue, Mar 24, 2009 at 07:26:13PM -0700, Baptiste Coudurier wrote:
>> On 3/24/2009 6:28 PM, Diego Biurrun wrote:
>>> On Tue, Mar 24, 2009 at 05:37:24PM -0700, Baptiste Coudurier wrote:
>>>> On 3/24/2009 5:05 PM, Diego Biurrun wrote:
>>>>> 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.
>>> But we are distributing the option to upgrade the license to v3 as well
>>> at the moment.  If we accept v2.1-only contributions, we cease to give
>>> our users this flexibility.  They can no longer use FFmpeg with their
>>> LGPL v3 software.
>> I believe there is a difference between "copying" and "distributing".
> 
> I could guess what you mean, but I'd rather not, so please be more
> specific.

Distributing the library is pretty clear.

>> As long as we distribute under LGPL v2.1, and that is what we do,
>> we can distribute LGPL v2.1 only code.
> 
> We are most emphatically *not* distributing under LGPL v2.1.  We have an
> explicit "or later" clause in all files.

In all files, however the LGPL is pretty strict, mentioning the
"library", not "file" contained in the library.

>> Do you mean that a LGPLv3 project cannot "link" against FFmpeg LGPL v2.1
>> only ?
> 
> No, I mean that they cannot grab FFmpeg and make it part of their
> software, which is what most currently do. 

No, you are wrong, this is what _mplayer_ do. I know people use to tell
this in the past, to statically use on revision in their project, and
this was a mistake.

>>>> In all ways, I might still try to change this one line of the policy, to
>>>> be more flexible regarding license.
>>> And this is the central part of your misunderstanding of the issues at
>>> hand.  FFmpeg does *not* become more flexible by accepting LGPL v2.1
>>> only code, on the contrary.
>> "copying" of this _single_ file stays under the same terms as it _was_.
>> "copying" the rest of FFmpeg stays the _same_.
> 
> Again, I could try to guess the meaning you attach to the term
> "copying", but I'd rather not.

Copying FFmpeg into your own, you know pretty well it, considering
that's what Mplayer do, and I bet that's why you are stubborn.

>> However, on my side, we have a G722 decoder, on your side we don't.
>>
>> You are being stubborn not realizing this.e.  You are the
> one confused about the consequences of the different licen
> 
> Nonsense.  I know perfectly well what we have on each sidsing schemes.
> 
> On your side is nothing right now (G.722 will possibly be resolved
> shortly) and a big can of worms in the future as well as reduced license
> compatibility, i.e. reduced flexibility.
> 
> There will always be something that can be gotten from lowering your
> standards.  On the side of less stringent review requirements we would
> have everything from the interesting patches page, not just a single
> obscure audio decoder.  We could also start accepting nonfree code and
> merge AMR-NB/WB.  But we don't do this.  Instead we draw a line in the
> sand with our requirements and take whatever crosses that line and
> nothing else.

Can you please stop talking about technical reason ?

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