Re: on firmware (possible proposal)
On Thu, Nov 13 2008, Peter Samuelson wrote:
> ------------------------------ [Forward] -----------------------------
> From: Sven Luther <firstname.lastname@example.org>
> Date: Thu, 13 Nov 2008 21:01:13 +0100
> - code uploaded into another cpu (a device cpu, not a SMP cpu of some
> kind) does not run in the same memory space, and can thus not impact
> the main software running on the host CPU.
Impacting other software has very little to do with the
desirability of freedom of software.
> => The argument is here that it is not as important that this is
> free software, since it cannot corrupt the software running on the
> main cpu.
Again, corruption or lack thereof is not why I want freedom in
> - code uploaded on a device cpu, is in no way less free than the case
> where said code would be found in a flash rom or something, on the
> contrary in some way it is more free than those cases.
But debian does not distribute the latter, so the fact that the
software being distributed is more free than some very non-free
software not distributed by debian has dubious value.
> - the third point, is that the fact that the code runs in a separate
> device CPU, create a clear interface barrier, and make it clear that
> the the uploaded firmware is not a derivative work of the kernel or
> driver or whatever that uses it.
Sure. It is non-free, but not a derivative of the kernel. Nvidia
drivers also qualify here.
> This means that you are able to use these points (especially the last
> one) to respond to most of your question, and explain why the position
> of considering it ok to have non-free firmware in main is one that can
> be considered.
I do not buy it.
What shall we do with the cell, BTW? It has multiple processing
units, and the central processing usint, if one may call it that, si
the dispatcher, which does little work. Would the software that runs
on the other processing units be considered to have different needs of
e-credibility: the non-guaranteeable likelihood that the electronic data
you're seeing is genuine rather than somebody's made-up crap.- Karl
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C