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