Re: [DRAFT] resolving DFSG violations
On Tue, Oct 28, 2008 at 10:00:31AM -0400, Lennart Sorensen wrote:
> On Mon, Oct 27, 2008 at 12:26:31PM -0700, Jeff Carr wrote:
> > True, I certainly feel like that at times with the opencores project
> > I've been trying to maintain.
> >
> > On the other hand, I sure know that I know a pile more than you do or
> > we wouldn't be having this discussion :)
>
> I have a different theory.
>
> > Yes Gee whiz. You're not getting it. The firmware is a binary blob.
> > You can distribute the source but you can't synthesize it. So, in the
> > debian installer, you can't include it according to this insane
> > policy.
>
> You could synthesize it if you had the tools for it.
>
> Debian's policy is not insane. It is consistent. Any hardware maker
> that wants their hardware to work with free software could use an
> eeprom to store the firmware within the device, so that there is nothing
> non-free that has to be distributed. That is what Debian is concerned
> with. If the firmware is embedded in the device, then it has nothing to
> do with Debian anymore, and it is entirely up to the user whether they
> care about how the hardware they buy is made. Those that do care can
> simply avoid that type of hardware (or at least try to).
Please try to explain to a hardware manufacturer that free their
hardware will only work with free software if they store their firmware
on an eeprom, and they'll laugh you in the face (or possibly send you
off to an asylum). Do you really think that it's better for our users
that the firmware is impossible to replace (and thus impossible, even
for the hardware vendors, to bugfix)?
Face it, all hardware has firmware, either loadable or in EEPROM. In
most cases that firmware is closed source. In most cases they are for
custom chips that have no compilers/developer kits/whatever available in
Debian anyway, so having the source wouldn't make any difference (and in
some cases, the binary blobs *is* the source code; I've spent more than
enough time programming 8-bit directly from a machine-code monitor).
As a bonus, an increasing amount of firmware these days is
cryptographically signed (cpu microcode, for instance), which means that
even if you had the source of the firmware, and the development kit, you
would still not be able to load the firmware onto your device.
Now, I always prefer to buy hardware I can get the drivers for,
so both my laptops and my server uses Intel chipsets to and through.
The only things I don't have the sources for are:
The CPU microcode
The iwl3945 firmware
I'm 100% certain I wouldn't have any use for the CPU microcode sources,
I know this because the microcode is cryptographically signed, and thus
any modified version I could possibly produce won't be able to load on
the CPU anyway (and apart from that, I seriously doubt that there is any
means of editing it in a sane way available in Debian anyway)
As for the iwl3945 firmware, I do not know for sure whether it's written
in C, assembler, or whatever else (I'm fairly certain it's NOT in some
obscure 8-bit CPU or similar). Personally I wouldn't mind having
the source code, but I do know, that if the choice is between either
having the firmware in EEPROM or having it as a binary blob, I'd take
the binary blob anytime.
I see firmware sources as a nice bonus in cases where it's written in
a language that we can actually modify and build using Debian tools.
I don't see it as a necessity. Throwing out the firmware doesn't help
our users, it makes things worse for our users. And our users are our
number one priority.
The same could of course be argued for non-free software as well, but
the difference is that we can write replacements for the non-free
software. We don't have the option of replacing our users hardware.
The closest we can get is to petition the hardware manufacturers for
specs or source code to the firmware, but if they don't answer, or if
they say no, we have to face he fact: our users are better off with
binary only firmware in Debian. Not in non-free.
For laptops running Intel chipsets, the most common wireless chipsets are
iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary
only firmware. With Intel's recent track record of releasing
sources, it's reasonable to assume that they would have released the
sources if they saw it as possible, so hoping for a source release seems
fairly futile.
Now, imagine Debian having this hypothetical yearly conference, called,
oh, let's say DebConf. During that conference we organise a special day
for our users, let's call it Debian Day. Lots of potential new Debian
users show up with their laptops and wants to install Debian. As the
kind souls we are, we hand out credit-card CD's with netinst images that
they can use with the WiFi available at the conference.
Oh, but wait. They cannot access the WiFi, because their wireless cards
are not supported. Or rather, the drivers are available, but they all
report the same error message "Firmware not found". Happy, happy, joy,
joy. I'm sure those potential Debian users will feel really happy about
Debian's consistent policy that dictates that software running on
non-cpu == software running on cpu. They might not feel equally please
with the fact that Debian isn't consistent in its dedication to
prioritising the users though...
[snip]
Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
Reply to: