Re: Considering porting acpi
On 10/12/14 10:24, Rich Felker wrote: > On Sun, Oct 12, 2014 at 03:08:03AM -0500, Rob Landley wrote: >> Heh. The ping.c one is particularly strange because clause 2, >> "Redistributions in binary form must reproduce the above notice" but >> busybox does not include the word "Regents" in any text string, so how >> it would emit it at runtime I couldn't tell you. That said it's been >> there like that for _years_ and nobody has ever cared except me. > > The subject of the verb "produce" there is not "the program, when > executed" but "[the] redistribution". This just means you have to have > a text file or paper distributed with the binary containing the > notice. It does not mean that the program itself needs to embed the > notice and be able to display it on an output device; however, doing > so is an easy way to ensure that it stays attached unless somebody > intentionally removes it. "Must reproduce in the documentation" but ping --help doesn't mention it, busybox.net/BusyBox.html doesn't mention it... Assuming your interpretation is correct, does that mean the busybox.net/downloads/binaries directory I put up ages ago is in violation? (I think defconfig contains ping, but haven't checked in ages.) Or is it ok because the notice exists elsewhere in the downloads directory? (In which case if something like buildroot downloaded the binaries via automated wget deep in the bowels of the makefiles, would _that_ be in violation? And yes, automated wget of binaries is a thing these sort of projects do, ala http://git.buildroot.net/buildroot/commit/?id=ae2364676f6a0d5390142791b7cb4200dc55ad9e). How about router firmware that contains busybox but not a copy of the BSD boilerplate? (Presumably most of them do it anyway but do they know they need to do it if busybox has ping enabled?) And I'd still like an explanation of how this requirement is compatible with GPLv2, but as I said I no longer feel qualified to travese this minefield. My Ohio LinuxFest talk included a section about how asking kernel developers to do userspace programming is how you get the lovely git command line, asking non-cryptographers to do cryptography is how you get side-channel attacks (at _best_), and asking cryptographers to do C programming is how you get heartbleed. This kind of subdomain expertise is why intellectual property lawyers point and laugh if criminal defense attourneys express opinions about IP. Now stop and realize neither of us are _any_ kind of lawyer. Confident in your understanding of these issues now? I'm not in mine... I was happy with the GPL when it was the universal receiver license, the only one I had to care about, and I could study it for years and parrot what experts told me and reduce all license interaction questions to a binary "is this GPLv2 compatible or not". But there's no such thing as "The GPL" anymore. Linux and Samba provide GPL implementations of two ends of the same protocol but can't share code. QEMU is stuck between wanting GPLv2 only Linux driver code and GPLv3 or later gdb/binutils processor definitions and there _is_ no license that lets you combine both in the same program. A project that's "GPLv2 or later" can't accept code from _either_ source. And that's before you get to the v3 clause selection and Affero and so on. Not quite the universal receiver it once was, eh? I responded because somebody asked: zero clause BSD is a public domain permission statement, which means it's presumably equivalent to unlicense.org and Creative Commons Zero and "LibTomCrypt is public domain" down in the Dropbear sources. It's a universal donor, so public domain _is_ compatible with both GPLv2 and 4 clause BSD. To what extent those two are compatible with each other I leave to others to answer... > Rich Rob ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On Sun, Oct 12, 2014 at 03:08:03AM -0500, Rob Landley wrote: > Heh. The ping.c one is particularly strange because clause 2, > "Redistributions in binary form must reproduce the above notice" but > busybox does not include the word "Regents" in any text string, so how > it would emit it at runtime I couldn't tell you. That said it's been > there like that for _years_ and nobody has ever cared except me. The subject of the verb "produce" there is not "the program, when executed" but "[the] redistribution". This just means you have to have a text file or paper distributed with the binary containing the notice. It does not mean that the program itself needs to embed the notice and be able to display it on an output device; however, doing so is an easy way to ensure that it stays attached unless somebody intentionally removes it. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On 10/10/14 01:50, Isaac Dunham wrote: > Hello, > I've written an acpi command for toybox, and was thinking about porting it > to Busybox. > What I've written is a partial clone of acpi 1.7, implementing -abctV > (ac, battery, cooling, and thermal status; -ctV are currently living > in a patch). I easily could add -d. > > Is this likely to be interesting? > > The code I have is currently using dirtree_read(), which corresponds to > recursive_action(). > Basically it looks in /sys/class/*/*/, /sys/class/power_supply, > and /sys/class/thermal for device status. > I could make it shorter if I use glob() instead of a recursive callback; > does anyone know whether glob() is likely to be a bloat problem? The only part of busybox currently using glob() seems to be hush.c. > Also, what would be the impact on license? It's currently "0-clause BSD". Zero clause BSD is a public domain license. I took out the "copy this specific license text into derived works" clause but left the permission grants, so you can pretty much do what you like with it. Also, you own the copyright to you own code, so you can issue any new license terms on it you like. (This doesn't affect other licenses you've issued to the code, they're multiple permission statements with different wording and/or requirements to exercise the permisson to use your copyrights.) Also, Busybox has already sucked in more conventional BSD licensed code before. ping.c for example has GPL at the start and BSD at the end because separating them as much as possible makes it less obvious that "this text blob must be copied verbatim into all derived works" might not be entirely compatible with GPLv2 but nobody currently suing people over it seems inclined to pursue that, so you'd have to wait for some third party troll to inherit somebody's copyrights and try to make trouble before that becomes an issue. But that hasn't happend since SCO in a way I've noticed, and it's not like anybody's been successfully sued over BSD license terms since the whole AT&T vs BSDi thing (that I know of), so we're all acting like that's not an issue in hopes it won't be. Heh. The ping.c one is particularly strange because clause 2, "Redistributions in binary form must reproduce the above notice" but busybox does not include the word "Regents" in any text string, so how it would emit it at runtime I couldn't tell you. That said it's been there like that for _years_ and nobody has ever cared except me. Personally, I've stopped trying to shove camels through this particular needle, for reasons I went over in my "Rise and Fall of Copyleft" talk at Ohio Linuxfest last year, which expanded the three minute summary halfway through the "What is Toybox" talk at the Embedded Linux Conference six months earlier... Rob ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On 10 October 2014 18:16, Rich Felker wrote: > On Fri, Oct 10, 2014 at 08:43:15AM -0700, Isaac Dunham wrote: >> > > The code I have is currently using dirtree_read(), which corresponds to >> > > recursive_action(). >> > > Basically it looks in /sys/class/*/*/, /sys/class/power_supply, >> > > and /sys/class/thermal for device status. >> > > I could make it shorter if I use glob() instead of a recursive callback; >> > > does anyone know whether glob() is likely to be a bloat problem? >> > >> > There's a cut-down glob function you could borrow from the linux >> > kernel ( lib/glob.c ) if you really wanted it slim. >> >> That would make a smaller static binary where only the "acpi" applet is >> concerned, but it might well increase the net size; glob uses fnmatch, >> which is use in several parts of busybox. > > Yes, I would think replacing glob would be a net increase in size > unless you have an extremely minimal bb config to begin with. Ah yes, you're both right, I'd somehow forgotten about the whole multicall thing! If curious how much difference there is (I was): [all tests done using musl libc, static] Standalone: ~15k for glob.c test program ~28k for fnmatch.h test program Busybox: === fnmatch.h test === function old new delta globA_main - 132+132 === linux kernel glob.c test === function old new delta glob_match - 255+255 globB_main - 107+107 Steven ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On Fri, Oct 10, 2014 at 08:43:15AM -0700, Isaac Dunham wrote: > > > The code I have is currently using dirtree_read(), which corresponds to > > > recursive_action(). > > > Basically it looks in /sys/class/*/*/, /sys/class/power_supply, > > > and /sys/class/thermal for device status. > > > I could make it shorter if I use glob() instead of a recursive callback; > > > does anyone know whether glob() is likely to be a bloat problem? > > > > There's a cut-down glob function you could borrow from the linux > > kernel ( lib/glob.c ) if you really wanted it slim. > > That would make a smaller static binary where only the "acpi" applet is > concerned, but it might well increase the net size; glob uses fnmatch, > which is use in several parts of busybox. Yes, I would think replacing glob would be a net increase in size unless you have an extremely minimal bb config to begin with. > This reminds me: I keep thinking about writing "fngrep", a grep-like > tool that uses fnmatch instead of regexes. Not widely useful, perhaps > on occasion. Since grep already has -E and -F, wouldn't it make more sense just to add this as a nonstandard option to normal grep? Then you'd get all the other grep functionality for free. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On 10 October 2014 16:43, Isaac Dunham wrote: > On Fri, Oct 10, 2014 at 01:46:36PM +0100, Steven Honeyman wrote: >> Off-topic slightly; Issac - am I right in thinking I've seen your name >> in relation to Puppy Linux somewhere? Do you know if someone by the >> name "technosaurus" is still around? > > Yes; that's how I started modifying busybox originally. (By the way, > the name's Isaac not Issac.) Oops, my bad, sorry! > "Technosaurus" is still around--he wrote blkid/fstype and mixer for > toybox; last I heard, he was considering a "Puppy BSD" and had been > working on some tiny project with a permissively licensed userland. Interesting, thanks. (I asked due to my interest in his "zero libc" macro-filled header that I found from 2012/2013 or so on the Puppy forums. Wondered if he was still working on it, or if there was a newer version.) Steven. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On Fri, Oct 10, 2014 at 01:46:36PM +0100, Steven Honeyman wrote: > On Friday 10 October 2014 06:50:49, Isaac Dunham wrote: > > Is this likely to be interesting? > > To me it would be... although I already wrote my own implementation; > if the developers don't ignore you and it gets added, it'd be 1 less > patch I'd have to use each build :) OK, I'll port it. > > The code I have is currently using dirtree_read(), which corresponds to > > recursive_action(). > > Basically it looks in /sys/class/*/*/, /sys/class/power_supply, > > and /sys/class/thermal for device status. > > I could make it shorter if I use glob() instead of a recursive callback; > > does anyone know whether glob() is likely to be a bloat problem? > > There's a cut-down glob function you could borrow from the linux > kernel ( lib/glob.c ) if you really wanted it slim. That would make a smaller static binary where only the "acpi" applet is concerned, but it might well increase the net size; glob uses fnmatch, which is use in several parts of busybox. This reminds me: I keep thinking about writing "fngrep", a grep-like tool that uses fnmatch instead of regexes. Not widely useful, perhaps on occasion. > Off-topic slightly; Issac - am I right in thinking I've seen your name > in relation to Puppy Linux somewhere? Do you know if someone by the > name "technosaurus" is still around? Yes; that's how I started modifying busybox originally. (By the way, the name's Isaac not Issac.) "Technosaurus" is still around--he wrote blkid/fstype and mixer for toybox; last I heard, he was considering a "Puppy BSD" and had been working on some tiny project with a permissively licensed userland. > > Thanks, > Steven ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Considering porting acpi
On Friday 10 October 2014 06:50:49, Isaac Dunham wrote: > Is this likely to be interesting? To me it would be... although I already wrote my own implementation; if the developers don't ignore you and it gets added, it'd be 1 less patch I'd have to use each build :) > The code I have is currently using dirtree_read(), which corresponds to > recursive_action(). > Basically it looks in /sys/class/*/*/, /sys/class/power_supply, > and /sys/class/thermal for device status. > I could make it shorter if I use glob() instead of a recursive callback; > does anyone know whether glob() is likely to be a bloat problem? There's a cut-down glob function you could borrow from the linux kernel ( lib/glob.c ) if you really wanted it slim. Off-topic slightly; Issac - am I right in thinking I've seen your name in relation to Puppy Linux somewhere? Do you know if someone by the name "technosaurus" is still around? Thanks, Steven ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Considering porting acpi
Hello, I've written an acpi command for toybox, and was thinking about porting it to Busybox. What I've written is a partial clone of acpi 1.7, implementing -abctV (ac, battery, cooling, and thermal status; -ctV are currently living in a patch). I easily could add -d. Is this likely to be interesting? The code I have is currently using dirtree_read(), which corresponds to recursive_action(). Basically it looks in /sys/class/*/*/, /sys/class/power_supply, and /sys/class/thermal for device status. I could make it shorter if I use glob() instead of a recursive callback; does anyone know whether glob() is likely to be a bloat problem? Also, what would be the impact on license? It's currently "0-clause BSD". Thanks, Isaac Dunham. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
