Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
> md@Linux.IT (Marco d'Itri) writes:
>
> > On Aug 07, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> 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
Reply to: