On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > > On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > >> > No, because those are not linked together with the GPLed code, but are a > >> > mere > >> > aggregation of works inside the same media, i.e. the binary file. Those > >> > non-free firmware will never run inside the same memory space as the > >> > kernel, > >> > and are offloaded to a peripheral processor, and the communication media > >> > between the kernel and this peripheral processor running said firmware is > >> > clearly defined, there is no doubt that those non-free firmware do not > >> > break > >> > the kernel GPL. > > > >> They are linked in, they have symbols, the code directly references > >> their address. Can you name one tool that will easily remove such > > No. They are a char array, it's data copied where the hardware wants it. > > It's not code called by other functions. > > That still leaves the symbol for the variable holding the char array > and its size. The code copying the data references that variable and > size. I didn't say the code is called.
Yeah, thanks very much. I suggest you go over to the FSF site, and read the GPL faq, and then come back and discuss this again. I did so during that discussion last year, and as said, that argumentation convinced the broadcom legal department, and even the FSF had nothing to say against it. A quick clue to help your search, the important parts are the one about the 'significant interface' or something such, and i seriously doubt that having a single variable referencing the non-free stuff is enough for that. Or else, consider this in a different way. On your computer disk, you have a bunch of binary files, those are called partitions, and hold data in a filesystem format. If you have any part of a GPLed binary on that filesystem, which is referenced by an inode or similar, and a non-free work (and you have probably bunch of unlicenced non-free stuff, like this email for example), referenced by another inode, then this doesn't make this email a derivative work of the linux kernel. > 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 ? > 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. > >> "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. Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
