Posted Sep 27, 2008 13:34 UTC (Sat) by ledow (guest, #11753)
In reply to: Wow? by tialaramex
Parent article: Atheros releases ath5k HAL code
Yes, but you're discussing the difference between a closed-source bit of code that has to be distributed with the hardware and one that has to be distributed with the software (i.e. subject to the GPL etc. restrictions).
I don't care that much about on-board firmware that works. Network cards have it, video cards have it, usb devices have it, BIOS's ARE it. It doesn't mean that having the source code available for that is necessary for operation of that device, which it is in some cases and is for the HAL layer of Atheros cards.
The last time I updated a BIOS was about six or seven years ago, and I would only EVER do it from manufacturer-supplied sources. It's the same thing - although it would be lovely to get the source to my current laptop's BIOS, I wouldn't try to use it, compile it or update it and use of it would almost certainly void all warranties. User-land code very rarely voids a warranty (the only case I can think of are the IBM laptops that could have their EEPROM corrupted by loading an I2C driver - and I don't know if IBM assisted in replacing such machines). The original firmware works, under all operating systems, and is supported and that's good enough for me. Future operating systems won't work on this laptop so there's no point "upgrading" to an OS BIOS to add features that it can't make use of. This BIOS will last the lifetime of the laptop.
This is how the internal stored firmware of any device is treated too - so long as it works for everything, it's fine. When it doesn't work, few people are going to want to make a permanent and therefore dangerous change to it even if they have the source. Whereas, devices that can safely update firmware on every boot by a simple upload from the driver - they should have source available because it's part of the necessary operating of the device from the factory and also because people might well tinker.
I have madwifi-supported cards and the freedom of the HAL layer for them is the only thing that has or will ever interest me. It means my kernel won't taint. That's all I care about. I'd love to have the source for the BIOS, firmware, every stored byte on the machine, but that's a very purist view. Atheros cards are basically "non-firmware" because the drivers do not require knowledge of the firmware.
One set of "true" firmware-less cards are those based on RT2500 and similar chipsets, which have entirely GPL, non-firmware drivers. But I don't know (or care) if there's a small EEPROM on there that holds the MAC, or a tiny embedded chip which DMA's data across busses... so I'm don't care if the "firmware" for that EEPROM/chip is available - I'll never need to know it and if the device fails, I'm stuffed anyway, whether I have the source or not.
Posted Sep 29, 2008 9:55 UTC (Mon) by jamesh (subscriber, #1159)
[Link]
Considering the GPL issue, the firmware that is uploaded to the card looks like data to the main CPU (and hence Linux kernel).
If the Linux kernel and downloadable firmware are not considered to be separate works but instead one program (the point at which the GPL becomes an issue), why wouldn't the same apply if the firmware was uploaded into the card from a ROM?
The only real problem with downloadable firmware is how to get it onto the system. If the firmware is freely redistributable, then it can be included by the distribution. If it isn't, then the user needs to get it some other way, which is the problem.
Given that on the hardware manufacturer's side, the decision to go with downloadable firmware is economic (no need to include an extra ROM/flash on the board) rather than depending on whether they think users will want to modify it. So saying that downloadable firmware should be open source but firmware stored in ROM or flash shouldn't be seems quite arbitrary. Either it is okay or it isn't.
Wow?
Posted Sep 29, 2008 13:10 UTC (Mon) by ledow (guest, #11753)
[Link]
What about ROM's in the real sense of the word (i.e. one's that CAN'T be changed)? If the software CAN'T be changed, what use is the source? And the companies are not under ANY obligation to release ANYTHING if the binary blob is indeed proprietry. But if someone wants to write a GPL driver, then it (may be) impossible to distribute the binary blob alongside the driver.
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.
Wow?
Posted Sep 29, 2008 21:20 UTC (Mon) by iabervon (subscriber, #722)
[Link]
But if someone wants to write a GPL driver, then it (may be) impossible to distribute the binary blob alongside the driver.
According to the GPL (Section 3, last paragraph): "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."
You may not be able to stick the firmware in the driver as a hex constant, and the firmware license may prohibit redistribution, but distributing it alongside the driver is explicitly permitted by a plain reading of the GPL.
Wow?
Posted Sep 30, 2008 2:33 UTC (Tue) by jamesh (subscriber, #1159)
[Link]
A Linux driver that supports firmware upload doesn't need to contain the firmware itself. For most modern drivers, the kernel asks user space to provide the firmware image and the driver then uploads it to the device.
During the upload process, the firmware looks like data: it just sends whatever data was passed by userspace to the card. When the device is operational though, you have two cooperating programs: the driver on the main CPU and the firmware on the device CPU.
My contention is that there is no distinction between the cases where the firmware is uploaded or comes on ROM/flash: if the two cooperating programs are considered a single work then the GPL would cover the firmware. If they are separate, then the GPL does not extend to the firmware. So the ability to create a GPL'd driver for the hardware shouldn't depend on the method used to load the firmware.
You bring up the problem of how to get the firmware if the company producing the hardware goes bankrupt. The firmware is still distributed with the device: just on a CD rather than a ROM. In such a case, it is just a matter of extracting the firmware from the CD (perhaps extracting it from a Windows driver). This is what people already have to do in cases where the manufacturer hasn't provided permission to redistribute the firmware. If they have provided permission to redistribute the firmware, then your distro probably already includes it.
Wow?
Posted Sep 29, 2008 13:08 UTC (Mon) by cortana (subscriber, #24596)
[Link]
Uploading firmware to a bit of hardware does not set the taint flag, at least in my experience (p54, iwl3945 drivers).
Wow?
Posted Sep 29, 2008 13:38 UTC (Mon) by ledow (guest, #11753)
[Link]
No, but using a driver that combines intimately with a non-GPL piece of software does. E.g. ath_hal, which is what this article discusses. ath_hal taints my kernel. As would the nvidia and ATI drivers that do the same trick (GPL wrapper around a blob).
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.