[FFmpeg-devel] [PATCH] G722 decoder

[Diego Biurrun]

On Tue, Mar 24, 2009 at 10:02:07AM -0700, Baptiste Coudurier wrote:
> On 3/24/2009 6:41 AM, Diego Biurrun wrote:
> > On Mon, Mar 23, 2009 at 10:19:04PM +0100, Benjamin Larsson wrote:
> >> Ronald S. Bultje wrote:
> >>> On Mon, Mar 23, 2009 at 4:58 PM, Benjamin Larsson <banan at ludd.ltu.se> wrote:
> >>>> Sure but I'm just trying to compromise so we just don't let this code go
> >>>> to waste. Until we re license (when pigs fly or whatever) the code would
> >>>> still be under LGPL.
> >>> Yeah, it's true. The thing is, if ffmpeg is LGPL2.1 (or later) and the
> >>> code is LGPL2.1, then requiring --enable-gpl for it to be compiled is
> >>> funny.
> >>>
> >>> anyway, in the end yes I support your idea of not letting it bitrot.
> >> We could add a --enable-lgpl2.1_but_not_later but I think that this is
> >> an acceptable compromise.
> > 
> > This means moving down a very slippery slope.
> > 
> > Right now we have at least the following license types in FFmpeg:
> > 
> > GPL v2 or later
> > LGPL v2.1 or later
> > MIT
> > ISC
> > BSD-type license variants
> > MPEG proprietary
> > libjpeg license
> > 
> > This is off the top of my head, I might have overlooked some.  The
> > intricacies of license compatibility can get arbitrarily complex and
> > with every license or license variant you add, complying their terms
> > becomes more difficult.
> > 
> > As sad as it is to have to say this, I would be surprised if more than
> > a handful of developers have read those licenses, not to speak of being
> > familiar with their terms.  This thread clearly shows quite a bit of
> > ignorance from core developers.
> 
> AFAIK, you are not a lawyer, are you ?

No.  How does this relates to what I 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.

> > We have also put considerable effort into simplifying the licensing
> > situation and we have come a long way.  libswscale now works in LGPL
> > mode and our AC-3 decoder probably will soon.
> 
> Yes, LGPL is preferred. However there is no reason to be a license
> zealot. Coding is fun, and our goal was always to support as many
> formats as it exists in the world. Your fight is bringing us away from
> our main goal.

Our main goal is not to support as many formats as possible *at all
costs*.  There are many functional patches that have not passed review
for a multitude of reasons.  Just have a look at the list of interesting
patches on the wiki.  Many of these are entirely functional.

> > I have worked on getting people to relicense some parts of our code and
> > addressed all complaints about FFmpeg licensing being vague and full of
> > hidden mines that make people queasy about using FFmpeg.
> 
> Yes, I thank you for this. However if people does not want to relicense,
> you got to respect this, and our choice to use their code conforming to
> their choice of license, if we choose to do that.

I have the utmost respect for other people's licensing choices.  It is
their choice alone under what terms they release their code.  However,
it is our choice alone to accept those terms or not.

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

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


Now there are two more things I would like to say:

If you do not wish to care about licensing issues, fine.  But then you
should aim for maximum license compatibility and licensing simplicity.
This means applying consistent licensing terms throughout and being as
liberal as possible.  LGPL v2.1 or later is compatible with LGPL v3,
while strict LGPL v2.1 is not.  Having the or later clause allows FFmpeg
to be used in combination with LGPL v3 software as well.  Widespread use
is surely one of our goals.

It is too late in the game to go back on our licensing terms.  FFmpeg
has been LGPL v2.1 or later for years and everybody has implicitly
agreed to this by licensing their contributions in this way.  Licensing
terms are a kind of promise and we have built up the expectation that
FFmpeg is LGPL v2.1 or later already.  This is very much unlike Linux
where any "or later" clause was explicitly denied from the outset.

Diego