[FFmpeg-devel] [PATCH] G722 decoder

[Diego Biurrun]

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.

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

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.

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

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

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.

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?

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.

But notice that this has not been the case in the past nor do I expect
it in the future.  Whoever contributes code to us does so understanding
that licensing their code in a compatible way is a prerequisite.

Diego