Should we drop the "or later" after GPLv2?

Rob Landley rob at landley.net
Sat Aug 19 04:30:34 UTC 2006


Bernhard and Erik: what do you think about dropping the "or later" from the 
BusyBox license and going to straight v2?

So the backstory is that Erik modified DietHotplug 0.5 to read modules map 
files at runtime rather than compiling them in (thus it builds without kernel
sources), and asked me if the resulting busyboxified hotplug should be merged 
into BusyBox, ala:

href=http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/package/
hotplug/diethotplug-0.5.tar?rev=15796&view=markup

I pointed out that DietHotplug is under gplv2 only, so we decided to ask Greg 
if we could get an "or later" for his hotplug code, and Greg replied:</p>

> No.  The hotplug stuff is Version 2 only for now, and unless version 3
> radically changes by the time it is final, it will stay that way.  There
> are way too many bad things about version 3 in it's current form for me
> to want to change to allow the code to be used that way just yet.

So for the moment, we're leaving Erik's hotplug as a separate package in the 
Buildroot repository, but the bigger question is what do we do about current 
BusyBox dual license situation?

Busybox IS currently dual licensed, and always has been.  GPLv2 "or later" 
means we're under GPL, plus one or more licenses from the FSF that haven't 
shipped yet.  This means that we can only take similarly dual licensed code: 
if somebody submits GPLv3 only code, we can't take it, and if somebody 
submits GPLv2 only code, we can't take it.

We're never leaving GPLv2 behind, so the question is what is the _advantage_ 
of GPLv3?  Right now, it seems to be "we can't take code from the Linux 
kernel, or Linux utilities under the same license as the kernel".  This even 
means that block copying in kernel header file bits (ala loop.c) is kinda 
questionable, isn't it?  (It's probably 

This wasn't really an issue before GPLv3 drafts came out, but seeing it 
neither Erik nor I are are particularly thrilled with it.  So I thought I'd 
get the issue out there: given that we're never dropping GPLv2, what's the 
downside of having 1.3.0 be GPLv2 only and dropping the "or later"?  (The 
immediate upside is we could take the diethotplug patch.)

So far we've taken a "wait and see" attitude (waiting to make this decision 
until the final GPLv3 text ships so that we can reject something _specific_), 
but the Linux kernel developers have already rejected it.  I'm generally in 
favor of BusyBox writing its own version of whatever it is and when there's a 
license conflict I think we should just write a new one (if it's too big to 
do that, then we shouldn't HAVE it), but what's the actual benefit of being 
dual licensed as GPLv3?  If v2 can be exploited to do things we don't want, 
we're already screwed anyway (and so is the Linux kernel).  If we're dual 
licensed, any additional restrictions in GPLv3 are probably irrelevant 
because they can say they're using it under GPLv2 instead (and we probably 
don't WANT additional restrictions anyway, which is why we're keeping 
GPLv2)...

Anyone have any opinions on this?  "Hold off until gplv3 ships" would be the 
status quo answer, and if we drop the "or later" we can't get it _back_.  But 
we've now seen the first real-world downside from it, and there will be 
more...

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list