[FFmpeg-devel] [RFC/PATCH 1/8] tidsp: add skeleton

[Martin Storsjö]

On Mon, 6 Sep 2010, Felipe Contreras wrote:

> On Mon, Sep 6, 2010 at 1:22 PM, Martin Storsj? <martin at martin.st> wrote:
> > On Mon, 6 Sep 2010, Felipe Contreras wrote:
> >
> >> +/*
> >> + * MPEG-4 / H.263 HW decode acceleration through TI DSP
> >> + *
> >> + * This file is part of FFmpeg.
> >> + *
> >> + * This file may be used under the terms of the GNU Lesser General Public
> >> + * License version 2.1, a copy of which is found in COPYING.LGPLv2.1 included
> >> + * in the packaging of this file.
> >> + */
> >
> > Please use a license header similar to the ones in the other files.
> 
> Ok, although I think such big text is overkill.
> 
> > Also,
> > is it possible to license the code (mainly the reused parts) as LGPL2.1+,
> > that is, including the "any later version" clause? The rest of the ffmpeg
> > LGPL codebase uses this version. If you aren't able to license it that
> > way, some configure magic to disable this code if compiling for LGPL3
> > would be needed, as far as I know.
> 
> I'm not sure what you mean by "reused parts", if I understand
> correctly, you mean the 'tidsp' directory, which code is similar to
> gst-dsp's.

Yes, that's what I meant.

> If so, no, I don't think we can change that to LGPLv2.1+,
> or at least not that easily (and I wouldn't want to). However, as Mans
> suggested, that code wouldn't be able to fit FFmpeg without changing
> the code-style, which I'm not willing to do, so that code would have
> to be a separate library, like libtidsp-ng.

Ok, if it's a separate library, it's at least easier to keep track of, 
although I'm unsure of the legal implications, if we should or shouldn't 
be allowed to link to that in a LGPL3 build.

> For the rest of the code that is truly specific to FFmpeg, and would
> be a client of the libtidsp-ng library, I don't have any problems
> changing to LGPLv2.1+.

Ok, that's good - the fewer the license variations within the codebase, 
the better.

// Martin