[FFmpeg-devel] GPL version matter

Reimar Döffinger Reimar.Doeffinger
Sun Jul 1 10:32:25 CEST 2007

On Sun, Jul 01, 2007 at 01:22:48AM +0200, Michael Niedermayer wrote:
> On Sun, Jul 01, 2007 at 12:48:43AM +0200, Reimar D?ffinger wrote:
> > On Sat, Jun 30, 2007 at 10:53:20PM +0200, Michael Niedermayer wrote:
> > > On Sat, Jun 30, 2007 at 10:19:12PM +0200, Christophe GISQUET wrote:
> > > > Michael Niedermayer a ?crit :
> > > > > theres something you miss here, and that is the following part of the LGPL
> > > > > 2.1:
> > > > 
> > > > Indeed I missed it, thinking 2.1 was a matter of phraseology. I
> > > > generally don't make my choices on absolute confidence in a sunny
> > > > future, or more tersely, that I will like any GPL versions coming out
> > > > any day.
> > > > 
> > > > > so even without the "(at your option) any later version."
> > > > > anyone can take your LGPL 2.1 code and change it to GPL 12.3.4
> > > > 
> > > > Then let my obvious question after that obvious correction be:
> > > > Are contributions under the strictly version 2 GPL accepted?
> > > 
> > > yes, as long as its in seperate new file(s), under proper CONFIG_GPL2 and
> > > you first submit some patch to configure which does actually contain
> > > the needed CONFIG_GPL* setup code and this patch does get accepted by
> > > mans or diego
> > > (note, the changes to configure must be under LGPL of course)
> > 
> > I am not at all happy about fracturing ffmpeg even further down into
> > different license versions. With that there are then already 4 different
> > ffmpeg variants from a license standpoint... At least some arguments why
> > this is important enough to start down this messy road might be
> > appropriate, in my view it is "only" optimization after all (though that
> > is on the other hand a reason why I don't mind more "restrictive"
> > licenses in general here, it is just having yet something else).
> could you elaborate on what "down to earth" disadvantages the license
> fracturing has?

For those using precompiled ffmpeg libs it becomes more and more
difficult to see which features they will get and which obligations they
have under the license (or even to find out which license exactly
Like this we will get further and further away from having the "ffmpeg"
library and instead have lots of different ones.
But the possibly bigger concern seems to me in this case what will
happen if the next person asks for GPL3 (or a future LGPL3) only. Then
there would no longer be any full ffmpeg that is still distributable.
Would we even have to create two tarballs, one containing the GPL2 and
the other containing the GPL3 compatible code only?

> the license is the authors decission and rejecting code because its under
> (L)GPL X(+) / BSD / public domain seems to make no sense to me

In this special case I think allowing GPL2-only (LGPL2 only is not a
problem AFAICT) to my understanding would not allow any other authors in
the future to choose GPL3 only without us removing the GPL2-only code.
I personally feel that this is giving a single person a bit too much
influence for that amount of code, but I do not object to GPL2-only, I
just feel really uncomfortable with it and want everyone involved to
think about it.

> rejecting patches which make some existing code fall under more restrictive
> licenses is of course something different, but here its just optimizations
> under GPL2 or none, or me spending an hour rewriting the code but i dont
> have the motivaton to do that also i dont care about wmv at all unless i
> happen to want to watch one and my computer is too slow ;)

I agree. I just don't want this to be done without knowing what we get

> and last, IMHO the "or later" clauses are somewhat concerning so its not
> unreasonable if someone refuses to put his code under them
> the fsf is not that trustworthy, at least not anymore since the GFDL mess

I fully understand the sentiment - though for the time being v2 or v3
would be enough and in the case of GPL only depend on known licenses.
And again, I agree the author has the right to ask for any license they
want, but at the same time both we and he should know what the
consequences are.

Reimar D?ffinger

More information about the ffmpeg-devel mailing list