Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote:
> On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote:
> > I think the key distinction (as far as I'm concerned) is that Debian
> > isn't producing a distribution for the microcontroller in my
> > fibrechannel card, it's producing a distribution for my computer.
> > In order to make my fibrechannel card work, it has to poke some bits
> > in a documented way. Even if there happens to be an ARM onboard that
> > card that's running a program, that ARM isn't running Debian.
>
> One of the purposes of having access to the prefered form of modification, is
> to be able to fix bugs.
Certainly, it's one of the purposes. But I don't think we've *lost*
anything by distributing binary firmware. Consider the cases:
1. Everything in hardware. You're not able to fix anything without a
soldering iron ... and good luck to you with that.
2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a
good deal of skill to fix anything. Again, best of luck.
3. Binary-only firmware in the driver. Slightly better chance of trying
to figure out what's going on, but still low.
4. Firmware source in non-preferred form. Modifications probably
possible, but when the next round of changes come out from the
vendor, you probably have to ditch your mods.
5. Firmware source in preferred form. Can send changes back to vendor,
everybody wins.
(and I'm sure people can think of other finer distinctions).
You seem to want to disallow cases 3 and 4 which makes sense from a
"here are the rules of data freedom, now i must follow them" point of
view, but really don't make sense to the vendor, nor to the user. It
seems like an all-or-nothing approach.
Actually, I can turn your argument on its head. The point you're making
is about ease of fixing bugs. Given case 3, I can't fix the bug myself,
but I have in the past been able to get the vendor to fix the bug. In
case 2 (which your argument would seem happy with), I can't fix the bug
at all. So cases 3 and 4 are *better* from a bug fixing point of view.
Reply to: