[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

Sven Luther <sven.luther@wanadoo.fr> 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


Reply to: