should all BB code be GPL?

[Rob Landley]

On Friday 28 July 2006 6:45 am, Glenn L McGrath wrote:
> > All busybox code _is_ GPL.  If it isn't, we can't ship it in a GPL
> > project. Some of it is dual licensed, although I'm pretty happy to
> > rip out the notice of the other license since the original authors
> > can make it available elsewhere under whatever license they like.
> > The _busybox_ version is GPL.
> 
> Im a bit concerned about removing the text of BSD license... it says

As am I.

> <snip>
>  * 1. Redistributions of source code must retain the above copyright
>  *    notice, this list of conditions and the following disclaimer.
> <snip>
> 
> I wonder if the text of the BSD licence should still stay in there for
> legal reasons.

If that's actually necessary, then I believe there's a license conflict.

> IANAL, but perhaps the text of the BSD licence needs be in there as mere
> documentation to satisfy the previous BSD licence.

If it's needed to satisfy the previous BSD license I'm kind of concerned 
whether or not it's actually compatible with the GPL.  However, most of the 
BSD-licensed code currently in busybox is scheduled for a rewrite _anyway_, 
because it's bloated and we can do better.  Let's see...

find . -name "*.[ch]" | xargs grep -l "must retain"
./networking/wget.c
./networking/inetd.c
./networking/ping6.c
./sysklogd/logger.c

I remember that inetd is crap, and wget and ftpget share no code.  Haven't 
looked closely at any of that yet, though.

./shell/msh.c
./shell/ash.c

When bbsh is done it'll replaces both of those and won't use code from either.

./coreutils/od.c
./coreutils/echo.c
./coreutils/env.c
./coreutils/cal.c

Haven't looked, but "echo" doesn't sound hard to rewrite and probably has to 
be done so bbsh can inline it when necessary.  I've bumped into the od code 
elsewhere while auditing libbb (something I'm about 1/3 through, you may 
remember me consolidating some of the xread/xwrite stuff a couple weeks 
back).  That 5.8k od.c sucks in 20k of libbb/dump.c.  (Wheee.)  Dunno about 
the other two.

./libbb/correct_password.c
./libbb/setup_environment.c
./libbb/run_shell.c
./libbb/restricted_shell.c
./libbb/dump.c
./libbb/change_identity.c

All of that (except the aforementioned dump.c) is being replaced in my passwd 
rewrite already.

(One reason I'm looking at Mercurial is more sane branches so I can do things 
like the passwd rewrite without tangling up my tree so badly...)

./e2fsprogs/uuid/gen_uuid.c
./e2fsprogs/uuid/pack.c
./e2fsprogs/uuid/uuid_time.c
./e2fsprogs/uuid/unpack.c
./e2fsprogs/uuid/compare.c
./e2fsprogs/uuid/parse.c
./e2fsprogs/uuid/uuid.h
./e2fsprogs/uuid/uuidP.h
./e2fsprogs/uuid/unparse.c

All of that is crap is going bye-bye.  For example, my current rewrite of the 
entire e2fsprogs/uuid directory is:

// According to http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
// we should generate a uuid by reading a clock with 100 nanosecond precision,
// normalizing it to the start of the gregorian calendar in 1582, and looking
// up our eth0 mac address.  We have 128 bits to come up with a unique
// identifier, of which 6 have a defined value.  /dev/urandom it is.

void create_uuid(char *uuid)
{
    // Read 128 random bytes
    int fd = xopen("/dev/urandom", O_RDONLY);
    xread(fd, &uuid, sizeof(&uu));
    close(fd);

    // Claim to be a DCE format UUID.
    uuid[6] = (uuid[6] & 0x0F) | 0x40;
    uuid[8] = (uuid[8] & 0x3F) | 0x80;
}

However, recently I read rfc 2518 which (in section 6.4.1) suggests that if 
you're taking the random approach, you should set bit 1 of the macaddr field 
(node ID), which is the mac multicast bit and guarantees we should never 
collide with somebody actually _using_ a mac address.  Seems reasonable.  So 
expect one more | in there for sheer paranoia's sake.

./miscutils/strings.c

Haven't looked.

./util-linux/fdisk.c

Known crap.  It's on my hit list.

> Glenn

Rob
-- 
Never bet against the cheap plastic solution.