[RFC] Updating busybox config/build system to match current kernel system

Rob Landley rob at landley.net
Thu Aug 31 21:21:10 UTC 2006


On Thursday 31 August 2006 4:54 pm, Sam Ravnborg wrote:
> On Thu, Aug 31, 2006 at 04:06:32PM -0400, Rob Landley wrote:
> > 
> > One thing that I thought of when you first mentioned this is "hang on, the 
> > kernel code is GPLv2 only!"  But we've been using their menuconfig all 
along.  
> > I _think_ we can use their GPLv2 build infrastructure to build a GPLv2 or 
> > later binary, but this certainly guarantees that we're never dropping 
GPLv2 
> > from our list of licenses, doesn't it?  (Not that we want to, but if we 
did 
> > we couldn't.)
> 
> How much effort is need to be able to claim copyright and to
> decide for a wider license when in-kernel?

Rewriting it from scratch, more or less.

The problem is it doesn't work that way.  You can't add stuff to remove a 
copyright, you have to remove stuff to remove a copyright.

If you have two (or more) copyrights on a work, then they must _both_ be 
licensed under compatible license terms in order to distribute the result.  
One common non-software case of this happening is music: one person composes, 
another sings the piece.  If the singer didn't have a license to the sheet 
music they can't sell the records.  If the composer doesn't get a release 
from the singer, they can't sell copies of that recording.  Now think about 
an entire orchestra.  That's Linux.

We can't add work to the kernel stuff in a way that takes away existing 
copyrights.  All we can do is add our own copyright.  We would have to 
completely rewrite what they did, and remove all their copyrighted code, in 
order to remove their copyright.

Now a copyright and a license are two different things.  A license is a 
permission grant letting you use someone else's copyright.  One copyright can 
have many different licenses, and the different conditional permission grants 
can have different terms.

With kernel code, the only license we have to their copyright (and thus the 
only terms under which we can distribute the result) is the GPL.  And the GPL 
is explicit that the only compatible terms with the GPL is the whole 
document, it's not severable and you can't add to it either.  So a non-GPL 
license may be convertible into the GPL (it doesn't require anything the GPL 
doesn't, so if you merge the two you can distribute the result under the 
terms of the GPL without violating any of the component copyrights).  But the 
GPL isn't convertible into anything else, the license text is fairly explicit 
about that.

> I have touched a good precentage of the relevant code lines (except
> for fixdep.c) so one could argue that it I could claim some 
> copyright. But there is obvious other contributors also so I really
> do not know what I can do in that respect.

Alas, touching isn't good enough unless you threw the old one out and wrote a 
new one in the process.  Copyright licensing works like &&, not like ||.  You 
need to satisfy the conditions of every copyright to distribute a work with 
multiple copyrights.

As a copyright holder, you can issue another license to your contributions at 
will (just give people permission), but your permission grant doesn't apply 
to other people's copyrights.

> In my personal opinion I have no problems changing from GPLv2 to something
> a bit broader if that can help other users.

We have no intention of dropping GPLv2.  The question is should we drop GPLv3?

BusyBox's license has always been is "GPLv2 or later" (I.E. the boilerplate 
allowing people to chose later versions of GPL issued by the FSF).  This is 
essentially a dual license: GPLv2 is one license and "future versions of GPL" 
is another license.

Recently, I've been pondering dropping the second license (the "or later" 
part) and just admitting that GPLv2 is the only license that has every really 
mattered for busybox.  It's easy to drop a dual license (such as by merging 
GPLv2 only code), but hard to get it back (you need every copyright holder to 
give you a new permission grant.  It's not something the maintainer can do 
unilaterally if they didn't write all the code.  Even the maintainer is just 
using the code under license, although they layer their own compilation 
copyright on top of the pile when they merge.  Actually transferring 
copyrights isn't trivial and requires an "explicit written instrument of 
conveyance" (I.E. has to be in writing, generally on paper and signed, 
listing the copyrights to be transferred), and can't be done at all in 
certain european countries that have the legal concept of "author's rights").

Anyway, the "hard to get back" is the only reason we've been holding off.  
Nobody's been able to come up with a concrete advantage of GPLv3 yet.  And we 
have no plans to drop GPLv2 anyway, because it's not broken.

There was previous discussion on the BusyBox list, this was just the issue 
cropping up again.  The "status quo" answer is "wait until a GPLv3 draft 
ships so we can reject something specific"...

> 	Sam - kbuild maintainer

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list