Atheros releases ath5k HAL code

The difference is in what's required for operation. A firmware source is not required for operation if it's stored permanently on the card with which it ships. Every card has a version of it, it comes from the factory like that and it may not even be able to be changed. If the company goes bankrupt, you're in no worse a position than before. All hardware has that code loaded and ready to go.

There may be "bugfix" versions of the firmware but the device is essentially another "computer" which your PC is talking to via an established communications standard (i.e. the card's protocol). Knowledge of that firmware's exact innards achieves little at great cost and because it doesn't need to be distributed AT ALL as "software" (except by the manufacturer in the original device), then it doesn't come under legal problems.

However, to RUN a card which does *not* have permanent firmware storage, then you have to have the firmware blob and the firmware blob is a required part of the driver code, no matter what the OS is. Because the blob is part of the code, that brings it into the murky realm of "merging binary blob with GPL driver code" (nobody's quite sure if it's allowed or not, but there haven't been any complaints yet). That's the problem, the solutions to which are:

1) There can be no legal GPL driver.
2) The company releases the source code to the blob under the GPL and a full GPL driver is released.

The legal definitions would be mind-boggling. Is my USB stick a "computer" because it contains a chip capable of performing operations on a private memory area? Is a PIC chip? Is hard-coded logic? Does this communication with a computer device consitute or require distribution of software code? Is that use legal under trade laws (i.e. can you sell hardware that is dependent on YOUR firmware code to operate and then forbid use of YOUR code to person X for reason Y? Are you required to let other people produce their own firmware code etc.)?

It's an absolute minefield, which is why the more that is GPL'd or licensed under even "more free" licenses, the better. However, there has to be a realistic limit or you're into "I want source code for your son and daughter too" territory and all co-operation halts.

Firmware would be great to have open-sourced but if I don't have the facility to use it at all (it's burned into a ROM) or I don't need to ever change it, I *personally* don't care about the source code for it. It's much easier than the hardware equivalent of soft-modems - where having to have a firmware blob (or other proprietry, non-distributed software) downloaded to the device every time I use it, the possibility of uploading the wrong firmware, the possibility of trashing the hardware with a faulty upload, the possibility of that being the only firmware EVER that operates the device because the company goes bust etc.

A GPL-only *driver* that can run on all OS is the ultimate goal for most people. That means not having to distribute other people's code (e.g. blobs, layers and protocols) but being able to control every visible part of the device. Anything past that is a bonus.

Now that a free alternative to ath_hal exists, I can get non-tainting of my kernel. Which means I don't have to unload ath_hal in order to report bugs.

It can be anything from some thin logic so people don't have to make a custom chip to play it to a entire embedded operating system.

The firmware for my Intel Iwl3945 is 184KB. That's a bigger binary then most of the programs in my /bin directory. It's bigger then the BSD-CSH. So it's obviously doing some very fancy things and is far removed from the traditional 'low level logic' that most people think of when they think of firmware.

It's not something that I particularly care deeply about and it's not worth getting into a war about, or anything. But all firmware is not made equal and if your in the market for a card then this is the sort of thing that I would like to know about. The drivers for Intel's cards are all pretty good, but the firmware has been a source of instabilities and trouble in the past for me.

Just last week, the reason I know about the Thinkpad error stuff, is that I was working on my Mother's Laptop I got for her off of Ebay. The stupid thing wouldn't hold a network connection for more then 7 seconds (XP's ping utility said 'hardware failure', then it would reconnect quickly), and when it did disconnect it would kill whatever downloads were occurring. This made it nearly impossible to install XP's service packs over the network.

So I booted it up in my USB flash drive I carry around for these sort of occasions and was able to download most of the software I needed using Linux and the Intel wireless. Now the same exact errors were happening in Linux, but Linux handled it much more gracefully. Instead of losing the connection the download would just get paused for the second it took to reconnect.

I tried reseting the router and all that happy stuff. We contacted the seller of the laptop and he sent a new Wifi card. Same freaking behavior. Eventually just gave up on the Intel 802.11b and bought a 802.11g cardbus card and it worked perfectly.

I am fairly certain that this behavior was due to Intel firmware bugs. I've had similar issues with my Iwl3945 device, and this is a OEM installed item with OEM Linux support. (Dell 1420n). Nothing earth shattering and the Linux drivers were more then capable of dealing with this stuff nowadays. But it took tracking the iwlwifi website for a while and a few firmware upgrades to get everything stable in Debian.

Like I said before, I use Intel wireless and am happy about the drivers and their Linux support, so I wouldn't put off buying a laptop with Intel stuff on it, but it's not ideal.

------------------------------------

Here; I'll give a (counter) example of why it's you should not get all religious about firmware code:

(now don't take this as gospel, I am sure that I'll get several facts wrong)

The AMD/ATI 'Atom Bios' for their video cards. The Atom Bios is firmware provided to Linux/X Windows driver developers that take care of a lot of the low-level functionality that is necessary to do 2D drivers for their newer video cards.

Well the Atom Bios is a binary blob. So you ended up with 2 different sets of 2D drivers being developed in parallel, one that used the binary blob, and the other which said 'no binary blob' and they proceeded to learn how to bang bits about on the surface of the card.

Well the deal is that there _is_no_source_code_. The Atom Bios is mostly shipped as it's developed.. the code in the blob is the code that they more-or-less hand programmed.

Using the Atom Bios is not perfect, it's not ideal.. but the thing is is that with the next-generation of cards all the work on 2D drivers and related items are going to be totally worthless. They won't be programmable using 2D acceleration any more. That part in the video cards will be totally gone and replaced with all 3D-related logic. The newest cards now don't have a 2D acceleration core.. they use hardware emulation and the atom bios to allow code-level compatibility with older 2D drivers.

So instead of putting all the effort into 3D driver development, which is the only thing that is going to be sustainable long-term, we have 2 or 3 different competing 2D drivers; one of the major reasons we have this issue is because of the black-n-white 'no binary blob' outlook. I mean it's nobody's fault how this all worked out.. it seemed correct at the time to shun the Atom Bios, so don't think I am putting the driver developers down or anything. (I think what they are doing is great.)

Anyhow, I agree with you, it doesn't matter much to me; although we have almost successfully reverse engineered Broadcom's firmware, which isn't possible if it's burned into a ROM. It just seems weird to me to burn it into ROM if you could save that cost which is why I always believed it was simply in the HDL. But yeah, it doesn't matter much since you can always treat firmware+cpu as one thing and combine it into new HDL too.