[FFmpeg-devel] [PATCH] G722 decoder

[Baptiste Coudurier]

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:
>>> 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.
> 
> 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". As
long as we distribute under LGPL v2.1, and that is what we do, we can
distribute LGPL v2.1 only code.

Do you mean that a LGPLv3 project cannot "link" against FFmpeg LGPL v2.1
only ?

>>>>> 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".
> 
> I have not said what my opinion about GPL optimizations is.
> 
>> 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.
> 
> Ronald is another that comes to mind and Michel as well.

Well, if you say so, but what do "they" say ?

> There is a difference between optimizations and baseline code.  Most
> people can accept that the LGPL version has the same set of features,
> albeit it runs a bit slower.

Some code under GPL might provide very useful features, AFAIK libx264 is
one. I will accept a killing feature GPL only, for sure.

But again this has to be stated once and for all, and you seem to hardly
fight against stating this.

>>> - 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.
>> 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_.
> 
> You can call it a trap, an unexpected incident, a surprise or whatever
> you wish.   No matter what color you paint this wordshed, the end result
> remains the same.  Kenan's actions had consequences that he neither
> expected nore welcomed.  End of story.

Yes, consequences, however doesn't every act has consequences ?
I'm sorry but I insist on _not_ calling it a trap. It is not a incident
either, not a suprise either. I don't mind LGPL v2.1 only code.

Others might and it's allright with me, but can we please state this
once and for all ? Will you insist on avoiding expressing opinions
through a vote ? I don't mind if I'm alone to want this, but at least
people expressed their opinion, and this can be written and end this
discussion in a democratic way.

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

However, on my side, we have a G722 decoder, on your side we don't.

You are being stubborn not realizing this.

> The flexibility to combine it with LGPL v3 code is lost, the end result
> is less, not more flexibility.  Plus the added disadvantage of increased
> licensing complication.

Again, what do you mean by "combine" ? Do you mean linking ? Does it
mean LGPL v3 code cannot _link_ against LGPL v2.1 code ?

If by "combine" you mean "copy", well they can "copy" all files under
the LGPL v2.1 or later, but not this one, like they cannot "copy" files
under GPL.

> Yes, it's a tradeoff of course.  You gain nothing right now, since the
> discussion about this particular decoder may be moot anyway.  You lose
> license combination possibilities, reducing the number of contexts in
> which FFmpeg can be used.  And you get increased license complication in
> the first place.  This could lead to further FFmpeg configuration
> fragmentation when everybody configures it in a different way.  This is
> less, not more flexibility overall.
>
> You have a hard enough time understanding all the intricacies of the
> current licensing situation.  Do you really want to inflict further
> complications upon us and our users?

You loose copying on this specific file under the terms of the LGPL v3,
yes. Can we please specific ? You claim to have knowledge but you do not
even make the distinction between "copying" and "distributing".

And you say I have a hard enough time understanding ?

Besides, users can _still_ _use_ (use as in link against) the code under
LGPL v2.1 _unless_ LGPL v3 forbids linking against LGPL v2.1 only. Is it
the case ?

> Don't forget that we expect people to respect our licensing terms.  We
> should not make this harder than necessary.
>
>> Well, the author accepted another license that's fine and great I'd say.
>> Did we say we would refuse ?
> 
> You mean if the author had declined our request to use a compatible
> license?  With bleeding hearts we would have had to decline I assume.

I would be opposed to decline, like I am now.

[...]

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