[FFmpeg-devel] some licensing issues

Michael Niedermayer michaelni
Tue Jul 17 02:35:10 CEST 2007


Hi

On Mon, Jul 16, 2007 at 07:43:17PM +0200, Diego Biurrun wrote:
> 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...

i dont care about the license of yuv2rgb_mlib.c do whatever you want with
the code i wrote in it, public domain is fine with me

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070717/0c8346c6/attachment.pgp>



More information about the ffmpeg-devel mailing list