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