On Tue, Jan 10, 2006 at 05:19:47PM +0100, Andreas Barth wrote: > * Kyle McMartin ([EMAIL PROTECTED]) [060110 16:20]: > > I would argue it's the former. I can see the argument when it's a part of > > the source code, but not when it's a completely seperate entity. > > Sorry, but there is no difference regarding DFSG: If the binary blob is > actually seperated from the kernel implementation, it can be treated as > binary blob (which I personally consider as non-program - but see
how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. Micro-code being another synonym for the concerned firmware in some cases. So how could anyone honestly claim it is a non-program is beyond me :) I know we all wish it where so, but ... > Steve's mail for details). Whether this binary blob is embedded in the > kernel source code (like we have IIRC for the pinguin boot logo) or not > (or is linked to the kernel during link time) doesn't make any Indeed. > difference to this. It might however make an difference to > GPL-compatibility, unless the license is GPL-compatible anyways. Nope, please read my posts on debian-legal about this topic 6 month or so ago. The firmware is destined to run on another processor, and thus there is no way you can claim it is a derived work from the actual linux driver, since the communication channel is clearly delimited. The counter-example would make the linux kernel a derivative of any expansion card or motherboard with embedded bios, or even make it a derivative of the actual hardware. So, no, there is no GPL issue there, and things are clearly separate. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]