[FFmpeg-devel] [PATCH] G722 decoder
Wed Mar 25 16:41:01 CET 2009
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
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
More information about the ffmpeg-devel