[PATCH] new applet: nmeter

Rob Landley rob at landley.net
Wed Aug 23 20:50:21 UTC 2006


On Tuesday 22 August 2006 11:19 pm, Jason Schoon wrote:
> I was on the fence about this until I thought about it a bit more after
> reading Rich's post.  I have to say I agree with him.

Ok.

> V2 or later is the most flexible of our options.

It's the most flexible in terms of other people taking code from us, but not 
in terms of our development.  It restricts the sources of code we can take 
from, because we can ONLY take contributions that are both gplv2 and gplv3.

> The problem we are trying 
> to solve is that we want all code in Busybox to be licensed uniformly (not
> necessarily my belief, but it seems that is the current push so lets go with
> that).  To do this, all accepted code has to either be the same license as
> Busybox, or convertible.

My ideal is new code written from a spec with small size in mind, but I 
realize this is often unattainable. :)

> If we go V2 only, we have just eliminated V3 or future code.

A) You're talking about a body of hypothetical code that doesn't actually 
exist yet, so this is purely hypothetical.

B) In terms of accepting contributions it doesn't eliminate anything.  If we 
stay dual licensed then we can never accept contributions that are under only 
one of those licenses, so we can never accept v3 only code.  If we go v2 only 
and receive dual licensed contributions, we can use them under v2.

The v3 only allows other people to use OUR code in v3 only projects, of which 
there are currently zero.

> Likewise, if we were to go to V3 only (not probably likely),

I'll go beyond unlikely: it's not happening.

> we could not accept anything that was V2 only.

Such as kernel code.

> V2 or later on the other hand allows us to take anything 
> except V2 only

Why do you think that "v2 or later" would allow us to accept v3 only code?  It 
doesn't.

> .  We would probably want to stay clear of any unlikely cases 
> of V3 only also, but anything else should go.  This gives us the largest
> possible melting pool of code.

Nope, v2 only does.  Because it includes the Linux kernel and the utilities 
maintained by the Linux kernel developers like Greg Kroah-Hartman.

> I would say that the license should stay where it is, and in the case of
> diet-hotplug, either a continued push for a license change should be made,

We asked Greg, he said no.  He's not changing his mind, and it would be 
outright rude to harp on it.

> or it unfortunately can't be accepted.

It won't be the last kernel utility under those v2 only.

> Erik could release his code 
> standalone, and it could still be used on embedded systems, and it could
> even include a mode/patch to easily integrate it into Busybox for those
> wanting to do so on their own systems.

He already did.  It's in buildroot.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list