[PATCH] new applet: nmeter

Jason Schoon floydpink at gmail.com
Wed Aug 23 03:19:15 UTC 2006


On 8/22/06, Rich Felker <dalias at aerifal.cx> wrote:
>
> On Tue, Aug 22, 2006 at 05:17:39PM -0400, Rob Landley wrote:
> > If you want to hold off on merging this patch after GPLv3 ships, we'll
> > probably have gone GPLv2 only at that point.  But right now, we're
> holding
>
> May I ask one final time, WHY? What advantage do you get by preventing
> people from using the code under GPLv3 as well as GPLv2? Are you
> worried that someone will make a derived work and change the "v2 or
> later" to "v3 only" and that you'll want to incorporate their changes
> into BB but be unable to do so? Unless this is your concern, there is
> absolutely no reason to remove the "or later" except to make people's
> lives difficult for the sake of political bickering. The last thing we
> need is for this sort of pettiness to fragment GPL'd software by
> splitting it into two mutually incompatible "v2 only" and "v3 only"
> corpuses of code that can't be used together.
>
> As far as I can tell, v3 has its place but it's not right for BB.
> However it's ridiculous to prevent people who need v3 from
> incorporating BB code into their projects.
>
> Rich


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.

V2 or later is the most flexible of our options.  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.

If we go V2 only, we have just eliminated V3 or future code.  Likewise, if
we were to go to V3 only (not probably likely), we could not accept anything
that was V2 only.  V2 or later on the other hand allows us to take anything
except V2 only.  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.

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,
or it unfortunately can't be accepted.  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.

My $0.02.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20060822/c4c43675/attachment.htm 


More information about the busybox mailing list