Sven Luther <[EMAIL PROTECTED]> writes: > On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: >> Compare it to including a hexdump of an image or sound in a header >> file and including that in the binary. And compare it with having that >> same image or sound as external file shipped in the same deb. > > Well, the FSF argues that it is not important where the file is, as long as > there is a logical link, in order to have the GPL cross the dynamic linking > barrier. In the same way, the only relationship of the non-free firmware or > your image or sound, is that it is transported in the same binary, and used as > data offloaded to the peripheral device. > >> Assume the image/sound was rendered/generated from some source format >> not included in the source. E.g. povray input. > > So ? What has this to do with it ?
So you can't claim the hexdump (or binary file) is the prefered form of modification (source). >> Is it an aggregation with the image linked into the binary? > > It depends if your binary is an image compressor, and only transports the > image, or if said image is used in the binary for icons of its GUI for example > or as splash screen. If I just dump my hexcode of the image/sound to my black box (qiv or xmms for example) for (dis)playing then I only transport the file. If I (dis)play it myself then it isn't an aggregation. Intresting. Or does the black box have to be hardware? >> >> "aggregated" code from the kernel image? >> > Not relevant. >> >> If it is an aggregation then there must be a way to break it up and >> only keep the GPLed parts. I think that is very much relevant. I don't >> think you can call something an aggregation if it is inseperably bound >> together. > > Well, sure there is part to separate them. You could imagine a (non-free) tool > called before lilo or grub, and which would upload those firmwares for the > peripheral device to be ready when the free driver comes into play. I can imagine a tool that rewrites non-free parts of a binary as free software from scratch without breaking any laws about reverse engeneering too. Does that mean they exist or are even possible? no. > Or you could use the new initramfs/firmware loading kernel infrastructure to > separate the firmware from the kernel. That requires changes in the source. Exactly those changes is what I say must happen. The firmware loading kernel infrastructure marks a clear lines where an external blob of firmware gets loaded that isn't part of the kernel binary itself. > Err, is not this latest one what you are suggesting we do ? So, if i > understood you well, your own argumentation is hitting you back there, and > this is usually proof that there is something terribly wrong in your > argumentation to start with. No. You just argumented my point. The source changes to seperate the firmware and to use the firmware loading kernel infrastructure makes a difference imho. Also notice that with the firmware loading kernel infrastructure you can just delete the firmware file and the loader will give a simple error. Good luck trying to remove the char *firmware from a kernel image and not have it crash. Best you can do there is fill it with dummy data. > Friendly, > > Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]