Kurt Roeckx wrote: > On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote: >> On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: >> > On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: >> >> > > > Point 3 then seems to go the other way around and say we don't need >> > > > sources for of few types of works. My main problem with this is >> > > > that still a little vague about which types of works don't require >> > > > source. >> >> > > What problems do you consider this vagueness to cause? What changes >> > > would you suggest to make this less vague? >> >> > It lists "images, video, and fonts". And I'm assume it's going to >> > cover >> > more than just that. I'm also not sure that this is something we want >> > for all types of data. >> >> I think we *want* the best possible form for modification for all types >> of >> data. I don't think the DFSG *requires* this, and therefore I don't >> think >> *we* should require it. Do you disagree? > > I think we should require it. The DFSG says we need the source, and > I understand that as the best possible form for modification. > > For instance, bison/yacc generates a C file. You could consider that > C file a source, but it's not. We want the original file that was used > to generate that C file. There might be several layers of tools that > are used to generate an object file from it's source, but it's the > source we want. > >> > For instance when they're raster images or fonts, I'd rather have the >> > source, if there ever was a vector based format of it. But I don't >> > care if there never was a vector based format, so nothing that would be >> > a more prefered way of changing it. >> >> "Rather have" != "Insist on for inclusion in main", though? > > No, I would insist on having it. > >> > > Anyway, the answer I had in mind was a hex editor or a decompiler. >> > > If the firmware in question *is* code, and we know what the chip in >> > > question is that the code is running on, both options seem within the >> > > realm of >> > > plausibility to me. No, of course they're not the *ideal* means of >> > > editing such a work, but AFAIK most firmware is on the order of what >> > > programmers used to program directly in assembly, so it's also not >> > > totally *insane* to try to edit such a binary directly as it would be >> > > for most modern userspace apps, for instance.) >> >> > I don't see a hex editor useful for much, and a decompiler only >> > slightly >> > better. If a decompiled version was useful to do derived work, it >> > would be the same as source, so not requiring source doesn't make sense >> > to me. >> >> > The difference with source is that you actually have names of functions >> > and variables, you have comments with it. Those things make it easy to >> > understand what it's trying to do. So it's easier to make changes too. >> >> OTOH, the source may require a non-free tool to render it into a binary >> firmware form. If you don't have that tool, and maybe even no hope of >> getting access to it, is it any longer evident that the source is more >> useful than the binary for derived works? Yes, from there we get into >> discussions about defining "source" as "whatever form people prefer to >> work from" -- hmm, redefinition? -- and whether we can ship anything in >> main that we don't have a full toolchain for; but a) is that actually >> required by the DFSG, and b) is that the right standard to set, either >> today or in the future? > > The DFSG doesn't say that the toolchain should be available for it to be > free, and it shouldn't. But I understand the SC as requiring it to be > included in main. It's also one of the reasons we have such a thing as > contrib. > > There was a time when alot of java applications were in contrib because > there wasn't anything in main we could use them with. But those were > free software. You just needed non-free software for it to be useful. > And now most, if not all, have moved to main. > >> > It would also be useful to have a list of firmwares we're currently are >> > talking about, and what license they have. Are there any that only >> > fail DFSG 2, or will this part of GR have no effect at all? >> >> Larry Doolittle has prepared a very helpful table at >> <http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html>. A number >> of these are marked as being under a "BSD-ish" license, which would >> qualify; a number of others are listed as GPL but sourceless, which >> nominally makes them non-distributable, but it seems unlikely that any >> copyright holders on these would refuse to relicense under more >> appropriate terms even if they weren't willing/able to release source. > > So, from that list: > * 46 source files that already use request_firmware() or > mod_firmware_load() > * 18 already removed from Debian (linux-2.6_2.6.17.orig.tar.gz) > * 47 apparently nondistributable > * 12 apparently ok for non-free > * 14 free > > So, we have a total of 137 drivers that require firmware. We have > 14 that are free and can stay in main in any case. > > I'm not sure about those 46 that already use request_firmware(),
Almost all of these feature externally packaged firmware, not in the kernel source. It's a fairly easy project to download and package those whose licenses allow it. > but we > seem to have atleast 12 (BSD-ish) that could go to non-free, but with > your proposol could stay in main. > > It would be interestig to know if any of those other 46 are currently in > non-free, or what their license is. Yes, it would. Example #1: ipw2200. Firmware downloadable from http://ipw2200.sourceforge.net/firmware.php. It's a nasty license. I believe it's clearly safe to make a downloader package with clickwrap, though. I don't think Debian as a whole wants to agree to the "you may not reverse engineer" provisions, otherwise it would be distributable. Example #2: atmel. Firmware in atmel-firmware package in non-free. :-) Example #3: cx88-blackbird. The firmware appears to lack a public distribution license. Reference http://plutohome.com/wiki/index.php?title=Installation : "You can get this from the card manufacturer." Some people seem to have made illegal packages of it; I suspect that they simply lifted the file off the manufacturer's CD. Example #4: ivtv. There's a program called 'ivtvfwextract' floating around to extract the firmware from the manufacturer's CD. (http://www.cugy.net/forums/printthread.php?t=1103&page=2&pp=15) Again it probably doesn't have a public distribution license. Example #5: bcm43xx. Similar to ivtv, there's a 'bcm43xx-fwcutter' program. http://langerland.de/linux/bcm43xx/firmware.html Example #6: bcm203x. Firmware in the bluez-firmware package in non-free. :-) This is a random selection, but I seem to have already run across the full gamut of possibilities. > Kurt -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
