Comment on docs/lesser.txt

Bernhard Fischer rep.nop at aon.at
Tue Apr 18 08:39:31 UTC 2006


On Fri, Apr 14, 2006 at 03:38:30PM -0400, Rob Landley wrote:
>On Friday 14 April 2006 4:38 am, Bernhard Fischer wrote:
>> On Thu, Apr 13, 2006 at 09:49:40PM -0400, Rob Landley wrote:

>Right now I'm concerned that by putting the text of the LGPL into our project 
>without a big fat warning that "THIS LICENSE DOES NOT APPLY TO 99% OF OUR 
>CODE" that somebody is going to decide that this license applies to the 
>entire tree.
>
>> So let's leave removing lesser.txt and adding lgpl.txt to the
>> maintainer.. ;)
>>
>> >Also, having bits of libbb under the LGPL is probably a bad thing.  That
>>
>> Ok, i misunderstood this as i thought that LGPL was ok for the lib parts.
>
>If we start exporting a standard API (like zlib) it's probably irrelevant, we 
>can just state "Linking to a documented stable API does not make your project 
>a derived work of busybox.  We export these stable APIs...".
>
>Right now, we have not made the decision to export any documented stable APIs 
>from libbb outside of busybox.
>
>> >library is not LGPL.  It is, in its entirety, GPL.  We are not intending
>> > it
>>
>> Mjn3 told me that he's fine with putting all his busybox stuff under
>> "LGPL or even GPL", so just go ahead and make this explicit in your
>> files, please.
>>
>> The patches from Denis Vlasenko i checked in earlier this week can also
>> be put under either LGPL or GPL
>> (http://www.busybox.net/lists/busybox/2006-April/020364.html)
>> So i can convert these too.
>
>Ok, just because of this I'm converting new versions of the bunzip2 code to 
>GPL only.  I just want to worry about _one_ license please.  I DON'T want to 
>worry about which parts of the tree are under which licenses.  I'm just not 
>going there.

Fine, so please do adjust the files from mjn3 too, I corrected the new
files from Denis Vlasenko in libbb.
>
>Feel free to make your code available elsewhere under any license you darn 
>well please, but the stuff we're distributing in busybox is GPL.  That's the 

Glad that doesn't sound rude.

Anyway. See below..

>only license we need to document in the tree, because it's the only one that 
>matters for busybox.  If we can't distribute it under the GPL, then we can't 
>distribute it in busybox anyway.  Our copy doesn't _need_ to document other 
>licenses the code may be under elsewhere.  (For example, my bunzip2 code is 
>available from http://landley.net/code and that source is lgpl, but that has 
>nothing to do with busybox.)
>
>I like simple.
>
>> One question about the new networking xfuncs, though:
>> It was not well received that these live in libbb since only
>> networking related applets use them, but they are built even if no
>> applet needs them. I agree that it would be better to have them in
>> libnetworking.a, but we currently don't have this.
>
>If we aren't doing a shared library for the standalone stuff and are instead 
>just building each one separately (which is fine by me at least as a starting 
>point), then this doesn't add extra complexity.
>
>> We only have libiproute.a which is basically the helpers for the ip()
>> (route, addr, etc) related applets.
>
>I don't use the ip applets, I use route and ifconfig.
>
>> I ment to put the networking xfuncs into a combined (and possibly
>> cleaned up) libnetworking.a later on, but this implies that the network
>> stuff is a little bit restructured. How should we proceed on this?
>
>My new dhcp stuff just shells out to ifconfig and route when it needs to, and 
>doesn't have any of that code built in.  It doesn't currently compile so I'll 

It would be nice if you would provide a
config CONFIG_FEATURE_DHCP_USE_BUILTIN
	bool "use busybox' builtin interface and routing manipulation applets"
	depends on CONFIG_DHCP
	help
	  blah ..instead of shelling out to call these.

>have to let you know if this is actually a viable strategy later, but for now 
>it looks like that doesn't impact the existing code at all.
>
>Beyond that, I haven't got much of an opinion at present.  The ifconfig.c code 
>looked reasonable at first glance, the route.c code less so but by no means 
>as bad as some of the stuff in the tree.  Given that it's no longer 1998 we 
>should probably have a "dig" instead of an nslookup.  I have no idea why 
>ping6 doesn't seem to share any code with ping...
>
>Which chunks of libbb did you want to move into the networking directory?

bb_xbind.c bb_xlisten.c bb_xsocket.c

Having them in a libnetworking would avoid forcing literally all applets into
including the networking related headers.




More information about the busybox mailing list