On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote: > "Jeff Carr" <[EMAIL PROTECTED]> writes: > > > On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > > > > Your argument boils down to: There is function that will > > > never be supported by free software. Annoying people by asking > > > them to expose their function by freeing the software just > > > irritates them, so we should just suck it up and accept it. > > > > I don't think I'm explaining this well, as it seems you are still > > not getting it: there isn't any source code to get.
I just want to find out: Under what circumstances does the blob need to be modified and who gets to do that modification? From earlier thread: > Because that's how the hardware works. If you are making a widget and > you need a fpga or hybrid chip of any sort, then you generate a binary > blob using the chip manufacturers tools. Are these "chip manufacturer tools" physical tools/machines or software programs? (i.e. something I need to pick up in my hands or something I need to execute?) Is there any way that someone else can use the same or similar tools to modify the blob (even if it is only useful to do so on a different board / with a different chipset)? > If so, I don't get it either. > > If we use the “preferred form of the work for making modifications to > it” definition of source code, what is the form that best meets that > definition? If the chip is used on a different board with different configuration, is the blob going to need to be changed and who gets to change it? Can Debian include software that supports porting Debian to the new board or can the blob be used to lock Debian out? If I build a customised board myself, is the blob / lack of blob going to prevent me running free software on the chip/board? > If the vendor is able to send out a bit stream and (with or without > the owner's intervention) load that bit stream onto the > already-purchased hardware to modify its behaviour, then we just > crossed into the realm where the recipients of those bytes (the owners > of the hardware) deserve all the free-software freedoms in order to > retain ownership of their hardware. Sounds like a DRM type intervention. > If the bit stream is contained in hardware such that it not feasible > for the user *or* the vendor to modify, then they are both on equal > footing and it's much less important to demand free-software rights, > since the vendor doesn't have them either. > > > So yes, I think most people aren't going to "get" the issue unless > > they may have been firmware engineers. > > Thank you for continuing to discuss it; I'm genuinely interested in > testing the principles of software freedom to ensure they continue to > apply as computer designs change. From an embedded perspective - so am I. I admit, I know very little about the minutiae of hardware but I know I'm going to come up against these problems and I want to know more about fixing them - *without* needing to get permission from the chip manufacturers or getting their software tools or needing expensive hardware tools. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
