[FFmpeg-devel] some licensing issues

[Diego Biurrun]

On Sat, Jul 14, 2007 at 05:20:36PM +0200, Michael Niedermayer wrote:
> 
> On Sat, Jul 14, 2007 at 04:37:02PM +0200, Diego Biurrun wrote:
> > On Thu, Jul 12, 2007 at 02:35:23AM +0200, Diego Biurrun wrote:
> > > On Tue, Jul 10, 2007 at 06:00:14PM +0200, Diego Biurrun wrote:
> > > > On Tue, Jul 10, 2007 at 02:41:43PM +0200, Michael Niedermayer wrote:
> > > > > 
> > > > > On Tue, Jul 10, 2007 at 12:01:02PM +0200, Diego Biurrun wrote:
> > > > > > On Mon, Jul 09, 2007 at 04:18:25PM +0100, M?ns Rullg?rd wrote:
> > > > > > > 
> > > > > > > Diego Biurrun wrote:
> > > > > > > > I've stumbled across a few more licensing issues/nitpicks:
> > > > > > > >
> > > > > > > > The following files contain the words "All rights reserved" in the
> > > > > > > > licensing header:
> > > > > > > >
> > > > > > > > libswscale/yuv2rgb.c
> > > > > > > > libswscale/yuv2rgb_mlib.c
> > > > > > > > libswscale/yuv2rgb_template.c
> > > > > > > > libavcodec/alac.c
> > > > > > > > libavcodec/armv4l/simple_idct_arm.S
> > > > > > > >
> > > > > > > > This wording with a subsequent grant of rights through the (L)GPL is
> > > > > > > > meaningless, but I'm afraid the term is one that easily raises red flags
> > > > > > > > when people stumble across it.  Thus I would like to remove it.
> > > > > > > 
> > > > > > > The "All rights reserved" tag is required under one of the many
> > > > > > > international copyright conventions (I forget which one) for copyright
> > > > > > > in the work to be recognised at all.  However, since a few years, all
> > > > > > > signatories of this particular one have also signed the Berne
> > > > > > > convention, thus making this requirement moot.
> > > > > > > 
> > > > > > > As for "All rights reserved" being present in conjunction with the LGPL,
> > > > > > > I see it as an initial (redundant) initialiser, with specific grants
> > > > > > > then given by the following text.  Hence, I don't perceive this as an
> > > > > > > inconsistency.  Then again, I am not a lawyer...
> > > > > > 
> > > > > > That's interesting to hear.
> > > > > > 
> > > > > > I'm still of the opinion that our license headers should be complete
> > > > > > consistent and as identical as possible so as not to create confusion or
> > > > > > doubt.  Thus I'll remove this text from the few headers where we have it
> > > > > > unless somebody objects.
> > > > > 
> > > > > as i said, you should ask the authors before changing the license
> > > > > headers, likely they will be fine with the change but if not you will not
> > > > > change them
> > > > 
> > > > That's 2 out of 5 file headers.  I did not intend to change those before
> > > > asking Walken anyway.
> > > > 
> > > > I think the main question is how much mpeg2dec code remains in those
> > > > files.  I'm looking at yuv2rgb_mlib.c and AFAICT all the code was
> > > > rewritten by Michael.  The following 'svn annotate' is quite telling,
> > > > revision 2733 is the initial import, 9477 is a rewrite by Michael:
> > > > 
> > > > http://svn.mplayerhq.hu/mplayer/trunk/libswscale/yuv2rgb_mlib.c?annotate=9477
> > > > 
> > > > Basically only the license header, a few braces and #includes remain.
> > > > 
> > > > IMO we should drop the mpeg2dec license header from that file and
> > > > replace it with an FFmpeg one.  Of course we can add a note to the
> > > > effect that this was once inspired by mpeg2dec.
> > > 
> > > My proposition is to replace the mpeg2dec header with an FFmpeg one.
> > > Opinions?  Objections?  Otherwise I intend to do this by the end of next
> > > week.
> > 
> > Michael, since this is your code: GPL or LGPL?
> 
> yuv2rgb_mlib.c ?
> 
> under what license is mlib actually? i didnt find any source and my attempt
> to download it ended at a "data mining" registration form from sun
> 
> if its not GPL compatible we should drop mlib support, but even if it is
> i am in favor of droping support for it, the advantages are small and i
> dont want to support these (sorry i cant translate the term from german)
> for whom (free == we will sell your personal data)

I do not disagree, but the question whether or not to make this GPL or
LGPL remains and is orthogonal to your point...

Diego