Features Download
From: Rob Landley <rob <at> landley.net>
Subject: Re: Move GPLv2 vs v3 fun...
Newsgroups: gmane.linux.busybox
Date: Saturday 9th September 2006 23:49:58 UTC (over 11 years ago)
On Friday 08 September 2006 7:04 pm, Aurelien Jacobs wrote:
> > or should we just admit that the BusyBox license is GPLv2 only?
> I don't understand very well your reflexion about GPL.
>  - You dislike GPLv3 because it reduce some liberties
>  - You propose to remove the "or latter", IOW to remove a liberty
> Isn't there a contradiction ? Or did I misunderstood your position ?

Don't invent a straw man argument please.  I consider licensing BusyBox
GPLv3 to be useless, unnecessary, overcomplicated, and confusing, and in 
addition to that it has actual downsides.

1) Useless: We're never dropping GPLv2.  Therefore, nobody can enforce any
the new clauses of the GPLv3 on busybox code because people can continue to

use it under the terms of GPLv2 which don't require them.  So the new
is unenforceable on BusyBox code anyway, all it could possibly do to
is relax the terms, not tighten them.

2) Unnecessary: There's nothing wrong with GPLv2 that I'm aware of, and if 
something did crop up the Linux kernel would be screwed and that's big
business for some large corporate entities to lobby to change the law to 
unscrew it.  GPLv2 is 15 years old and it's been scrutinized by everybody 
from Microsoft to SCO.  What reason is there for replacing it other than a 
cry for attention on the part of Richard Stallman?  What exactly was wrong 
with GPLv2?

3) Overcomplicated: I'm not talking about the text of GPLv3, I'm talking
why would BusyBox need two licenses?  We've been under GPLv2 all this time,

that's the ONLY license we've ever had, and I'd like it to _stay_ the only 
license.  I dowanna add unnecessary complexity to the project's licensing
more than I want to add unnecessary complexity to the project's code.

4) Unmotivated:   Our current dual license was at first an afterthought,
is now an inconvenience.  The GPLv3 did not _exist_ when BusyBox first 
shipped (and technically still doesn't), we just used the standard GPLv2 
boilerplate which had the "or later" in it.  This is not something we ever 
put any effort into, or placed any value on.  It was a purely theoretical 
issue up until the FSF decided it had to do something to regain relevance. 

The "or later" clause is something I am now having to put effort into 
preserving and policing, and I really don't see any benefit from doing so.

5) Confusing: I hate having to point out the need for an "or later" clause
people when it's absent.  Right now they can license code GPLv2 or "GPLv2
later", and it's a subtle enough distinction that I keep having to point it

out and ask "can we get an 'or later'" and it annoys me.  GPLv2 and GPLv3
clearly two different licenses, GPLv2 or later is a vague implicit dual 
license that's way too easily overlooked, and probably has been in the
We didn't track this closely back when it was a purely theoretical issue, 
it's quite possible we sucked code from GPLv2-only projects, since at the 
time we just checked that it _was_ GPLv2.  (We know we took some code from 
the Linux kernel, for example.  The question is how much and where.  You 
wanna do the audit?)

I really like having the same license as the Linux kernel, and being able
take code from the Linux kernel without asking questions.  I hate having to

ask questions BEYOND "Is this code licensed under GPLv2?", and I really
having to explain to people why GPLv2 isn't good enough to merge a patch.

6) Costly: To preserve the "or later" we can't use GPLv2 only code, which 
exists today.  We had to pass on the diethotplug patch already.  We're 
bending things a bit to continue to use the kernel's menuconfig.  (Is it,
is it not part of the BusyBox source code?  It's GPLv2 only.)  Or how about

the section of the kernel header files we sucked into libbb/loop.c?  (That 
might or might not be scenes a' faire.)  This is not going to improve with 

7) Divisive: GPLv2 and GPLv3 aren't compatible, and BusyBox's current dual 
license is quite compatible with either of them.  Although we can' donate 
code to projects under either license, we can't TAKE code from projects
any of those licenses.  This means that the only people who might possibly 
benefit from our code being dual licensed those who want to suck BusyBox
into other GPLv3-only projects.  (Not use us as a package, but use code 
snippets, or bolt our applets onto other things.)

Except that if they do that, we can't take patches back from them.  If they

glue a GPLv3-only applet onto BusyBox, they can only distribute that
version of BusyBox under GPLv3 only.  We can't take that applet back into
the main BusyBox distro any more than we can currently take Greg's 
diethotplug code.

I.E. the dual license encourages people to fork the project, in such a way 
that even if we get their code back, we can't integrate it.  The only 
possible "benefit" of the dual license is making such a fork possible.

Today there's 15 years worth of code under GPLv2, and not a line of code
GPLv3.  I see absolutely no benefit from BusyBox being dual licensed under
license that doesn't even exist yet, a number of real and potential 
downsides, and I expect that the situation will only get worse as time goes

on, because their are two possible scenarios:

A) GPLv3 is successful.  We get more GPLv3 only code submissions, greater 
amount of code we can't use because it isn't dual licensed under GPLv2.

B) GPLv3 fails.  We get more GPLv2 only submissions, which again we can't

Everybody complained about the CDDL being pointless and divisive, but
they think the "or later" clause was universally adopted and thus this 
doesn't apply to GPLv3.

Apparently they weren't paying attention when Linus Torvalds made it clear
YEARS ago that the "or later" clause had never applied to the Linux kernel
the first place:


And this is a very clear explicit statement which predates the current
effort by a number of years.  They were hoping to browbeat him into
his mind (despite the fact he's not the only copyright holder to the
as he himself made clear when the browbeating started: 

The FSF has also been trying to browbeat other projects that haven't got 
an "or later" clause into adding one:


And so far, the response has been a resounding "meh", with wait and see
as positive as it gets.

GPLv2 is not going away.  There's no reason for it to.  So what exactly is
purpose of GPLv3?

Never bet against the cheap plastic solution.
CD: 4ms