[FFmpeg-devel] Licensing gray area

Justin Ruggles justinruggles
Mon Jul 16 23:31:17 CEST 2007

Michel Lespinasse wrote:
> On Fri, Jul 13, 2007 at 11:38:35PM -0400, Justin Ruggles wrote:
>> Diego Biurrun wrote:
>>> On Wed, Jul 11, 2007 at 09:47:07PM -0400, Justin Ruggles wrote:
>>>> I want to preserve the history in the SoC repository, but some of that 
>>>> history has a GPL violation.  Part of the code is copied near-enough 
>>>> verbatim from liba52, which is GPL, but is put under the LGPL header. 
>>>> My subsequent commits will change that portion, rewriting the 
>>>> problematic code, so the result will be okay.  But the violation would 
>>>> still be in the source history.  So I'm not really sure how to approach 
>>>> this.
> I was actually quite grumpy about that at the time, though I had not
> complained to the list. I'm quite glad you've noticed this and about
> the suggestions earlier in the thread.
> Note that the original SoC proposal had been to implement E-AC3
> which is a significant extension over the base AC3 format. If this
> had gotten done I would not mind about the LGPL license at all -
> I was only unhappy because the project did not go much farther than I had.
> If you get to E-AC3 first and want that to be under LGPL I'd be totally
> amenable to that (assuming there is still any of my code left at that point -
> if there is none then I would not have anything to say anyway :)

Great.  Most, if not all, of it will indeed be removed.  I did find a 
couple of other sections that appear to be derived from liba52, so I 
have planned to go through the code very closely before changing the 
license of that file back to LGPL.  I'm glad to hear that you're 
amenable to LGPL though.  If I find any minor things left which are from 
liba52 that I don't feel like rewriting I'll run them by you before 
proceeding with the license switch.

As far as E-AC3 goes, so far the bulk of the new code is bitstream 
parsing for the new format.  Implementation of the "enhanced" algorithms 
will come with new samples which actually use them.  Maybe some will be 
implemented as preliminary ideas, but will require testing with 
as-yet-undiscovered samples.


More information about the ffmpeg-devel mailing list