| |||||||||||
Debian Weekly News 2004/15Debian Weekly News 2004/15Posted Apr 15, 2004 16:42 UTC (Thu) by pizza (subscriber, #46)In reply to: Debian Weekly News 2004/15 by Peter Parent article: Debian Weekly News 2004/15 You ignored the last paragraph of my original post. I agree that the "little lie" runs counter to the DFSG. But I'm taking that "little lie" one step further -- I see no difference, morally, between a binary blob that has to be copied over to the hardware, versus a binary blob already embedded in the device itself (even if it's just mask ROM!). I consider that blob and the rest of the hardware inserparable, because without it, the hardware is just a paperweight. But as you said, distributing this binary blob runs counter to the DFSG. I just hope that, once all of these redistributable (yet non-DFSG-compliant) binary blobs are removed, the Debian kernels are still bootable.
(Log in to post comments)
Debian Weekly News 2004/15 Posted Apr 15, 2004 23:36 UTC (Thu) by Peter (guest, #1127) [Link] I just hope that, once all of these redistributable (yet non-DFSG-compliant) binary blobs are removed, the Debian kernels are still bootable. Long term, I think it's good for someone to stand up and send a message to these vendors that not everyone thinks they should keep back part of their source code just because it's not executed on the host CPU. Remember, a few years ago, binary-only drivers were quite common, even for things like network cards. But you can't get your driver into a Linus published kernel without giving out your source under the GPL. And these days, nobody in server space wants to be caught without a driver in the standard Linux kernel. So the vendors swallowed hard and did the right thing, contributing docs and in many cases actual drivers to Linux kernel development. Not that I expect this next round to be won so easily, mind. Mostly because Linus doesn't really care about this part of the issue, so you can't threaten vendors with not having a driver in the official kernel. Debian is considerably less influential. But still, Adaptec proved many years ago that it's entirely possible - even reasonable - to ship full source code for your firmware. (They even went a step further and shipped the source for an assembler capable of assembling it.) And I dunno, maybe it's just me, but this decision doesn't seem to have hurt them in the least. Since Adaptec proved it can be done, I don't see much reason for other vendors to insist on sending us their binary blobs. Except for the obvious reason: that they really don't care. That is the attitude it would be nice to change.
|
|||||||||||