Slashdot Mirror
OpenBSD Activism Shows Drivers Can Be Freed
grey continues "This means that currently, these wireless NIC's don't work out of the box on OSS install or boot media. In just the first 4 days, hundreds of users wrote and called vendors, and already 2 vendors freed their firmware, and several others are in discussions with Theo de Raadt about taking similar steps.
We need your help! TI has still not responded at all. You can call or write to Bill Carney, - Director of Business Development of TI's WNBU to add to the approximately 400 well written messages the OpenBSD community has already sent to TI. We hope that you'll help, and if you do please keep messages polite and to the point. Please remember, we are not asking for the vendors to open source their firmware under the GPL or BSD licenses (though we wouldn't complain if they did). Instead, ask if they would simply email Theo to open discussions on licensing their firmware binaries under terms that allow for free redistribution. If changed, these firmware binaries would then be able to be included with OSS software and function with existing BSD and GPL licensed device drivers from the start.
You can find other contacts for target vendors here, here, here, and here, and it can't hurt to sign this petition. These changes aide all OSS efforts, not just OpenBSD. As you can see from the OpenBSD community's results already, contacting these vendors really does make a difference. We're sure that with the numbers of OSS minded readers in the Slashdot community you can really help with the heavy lifting where fewer numbers of BSD users have already begun to succeed, and all Open Source Software users will benefit."
Particularly where OpenBSD is concerned, where every inch of the code has been scrutinized for security holes, encouraging the use and distribution of binary-only drivers sounds like a quick way to lose the status of never having a security hole in the installation. There's got to be a hardware manufacturer that's willing to release source (though the hardware might cost a little more).
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Until an open source hardware manufacturer is sprouted, I can't understand why any for-profit company would license the most difficult part of their design for "free distribution".
I mean, if they licensed it for free distribution, what would prevent some half-baked Chinese knock off from mass producing the wireless chipset reference design, burning the for-profit's "free" firmware, and selling for a huge profit?
Please sir, if you'd only give me the keys to the kingdom.
I wonder if Linus could do something similar to get ATI and NVidia to open up...
Your CPU is not doing anything else, at least do something.
First; Write your letter to the hardware company.
Second; Sign the above mentioned petition.
Third; Only buy hardware from companies that are OSS friendly, that make good products for which they do not rely on disabling the expensive features in software.
Forth; Send a(nother) letter to the hardware company that makes the devices that you would have preferred to buy, and tell them why you didn't buy it.
Hi!
Yes, well that's the slashbot conspiracy theorist answer.
In reality, most companies pay people to produce drivers. The smart ones realize that drivers are a part of the whole experience and seek to further differentiate their offerings from those of their competitors with good software. When there is money to be made by open sourcing drivers (i.e. when it helps sells hardware in numbers that matter) it will happen.
Until then it is too easy to dismiss the whole open source community as whiny cretins who have no appreciation of the process and who don't spend enough money to matter - like you.
Cheers,
GNU/Wolfgang
I'm not disagreeing with things here, but that's not always the way people do it, at least with Windows.
I have seen this first hand. The not-very-enlightened of the Windows world, when they "need a driver" (even if the hardware is already working) go to google and usually type "driver [hardware name]" or "find my driver for my sound card".
This then gives them a wonderful list of web sites which are NOT the manufacturer, and have drivers that undoubtedly are of questionable origin. I've even seen them install software (spyware) which even said it wasn't the driver, but if they installed it *it* would find the driver for them. Spyware makers are some sneaky pricks.
This is great. I hope several companies agree. It will be hard to get Linksys to agree, if they try. Linksys will not do anything about it. I have written to them three times about it, and gotten bullshit each time saying that they might be working on drivers for other OSes. The more companies we get the better. Wireless support is the only issue stopping me from using BSD or Linux.
Scott Simontis
There is some concern about the issues involved with turning the binary firmware blob into a string constant in a C file to be compiled into the kernel image so that it is accessible to the driver before there is a filesystem. Having a license to distribute a file is different from having a license to distribute a program that, without any input, outputs the file.
Of course, you get into awkward circumstances here. What if your program messes up and fails to output the file exactly as it was supposed to? You now have a program that outputs a modified version of the file. Of course, you'd want to fix it so the device would work, but OSS developers don't want to be responsible for copyright violation if their code misbehaves.
So they want to be legally permitted to distribute non-working modifications to the firmware (just in case), although they don't care about having any way of making useful modifications to the firmware as sent to the device.
Probably the best thing is for the manufacturers to encrypt the firmware, and have the device decrypt and check it, and let people do whatever they want with the binary (because they won't be able to do anything useful other than send it to the device). Or, alternatively, let people mess with the firmware however they want, so long as they don't mind not having any source for it.
Of course, I think the standard practice in Linux is to distribute the original file and a program to convert it into a C file to be compiled into the driver, steps which are no less legitimate than converting it into PCI bus transfers. Then it is simply embedded in the kernel binary in much the same way that it was embedded in the filesystem.
I think Linux at some point included some C files of firmware, which were determined not to be properly licensed and were removed in favor of only distributing untranslated firmware files.
Well, that's an interesting point. However, in this case, the firmware could effectively be in silicon. It's just easier to make it not be in silicon. Do you ask Intel for the rights to their Microcode? Intel/AMD CPU's (that's pretty much definitely hardware), have microcode patches.
Do you demand Transmeta software. Their CPU is a big software translation engine, but they burn their software into a piece of silicon because it executes faster.
Do you ask Intel for the plans to their CPU so you can use the Free Software concepts to fix up their CPU designs? They are nothing but big pieces of software that are turned into hardware by a very precise etch-a-sketch.
The problem is that hardware is software, and software is hardware. Especially at the level of firmware. If it's programming an FPGA, that's literally hardware that is changeable. You are configuring a bunch of AND and OR gates. If it's running an ARM, you might have a development environment.
However, if it's say the Adaptec SCSI firmware, you have a non-standard instruction set, with non-documented hardware. A non-existant tool chain. What do you want the source for? The only reason they do things in firmware, is so they can avoid soldering wires, flashing the PROM, or forcing you to physically pull the ROM and replace it if they find a problem. If they document it's behaviour and say "avoid that", it effectively becomes a hardware problem, the same as if they burned it to silicon.
Open Source is a fairly practical solution to an Engineering problem. It's applying the age old solution of scientific peer review to the world of software. The freedom is incidental, but most of the original great science was fairly publicly available. At the level you are talking about, you are beginning to approach, "Well, is it a wave, or is a particle", when discussing "is it software, or is it hardware". I mean the CPU is flash upgradeable, and I'd say the CPU is about as hardware like as hardware gets.
I agree that most of the time, all software should be open. However, in the case of the firmware, I think several different issues come up. Not the least of which are, you'll need the vendor to open the docs on the specifications of the hardware internals (this works at a lower layer then the driver does). You'll needs a tool chain for an assembler that might literally be a one-off designed in house by a hardware engineer. At some point, they'll be a layer of software, that until there is an open hardware maker that will be inheriently propritary (documenting the firmware properly essentially draws a blueprint for the hardware). The economics of the situation make no sense for the hardware makers to make it public knowledge. I'm not saying it's a good thing, but economics makes the computer world go around. The economics of hardware is what made writting software a possibility for so many of us. To blindly ignore them is naive. I wish that there was more open hardware that was actually made and sold as high quality equipment. I know I'd pay a premium for it to get hardware that was open all the way down to the traces on the board level.
Kirby
Please don't even bring up the notion of a freely distributable binary/closed source driver - that's what things like NDISulator basically workaround, they're nasty ugly kludges that are a REALLY REALLY bad idea for a large number of reasons (I won't get into them here, just like I won't go into why FCC arguments are a red herring). Closed binary firmware isn't ideal, but it's what we've dealt with for quite a while already (only, as mentioned before, it shipped on flashmem built into the hardware, not as a binary loaded by a driver).
As an aside, you mention the prospect that some of these chipsets are SDR's. If one of these vendors -did- open up the firmware binary or provide some sort of SDR chipset SDK, just think of what projects like GNURadio could accomplsih affordably and ubiquitously. THAT, unfortunately is probably a pipe dream for now, but would be WICKED cool (think affordable GNURadio, mixed with MythTV maybe). That sounds like another activism campaign worth fighting for someday for GNURadio. Today, let's just stick to the issue at hand and try to get these firmware binaries licensed in a manner that would allow OSS vendors to ship them out of the box.
I have to say that the NVIDIA guys are way more relaxed than say intel or broadcom. I'll give you an example: I contribute to the DragonFlyBSD project. NVIDIA found out that I have been porting the FreeBSD X11 NVIDIA driver to DFBSD. They contacted me, and after some pleasant communication, they sent me a prerelease driver for me to port. But that just started things rolling, because I passed on the contact details to Joerg Sonneberger, and he managed to get the nvidia ethernet binary object relicensed so it could be included in our base install.
This just shows that it can be done.
I worked for six months to get Atmel to release their firmware under a licence which allowed redistribution. That was for use with the Linux atmel_cs driver. And I collaborated with Manuel Estrada Sainz to add the hotplug firmware loading code to Linux, to avoid violating the GPL by linking Atmel's proprietary stuff with the kernel. And I built and distributed packages of the firmware. And all of this is a piss-poor alternative to just releasing the source!
It is not true that WiFi card makers are not allowed, under U.S. regulations, to expose the transmit power control, tuning, etc., to the user. People who say so, even people at Atheros who say so, are mistaken or lying. (As one FCC lawyer told me in the mealy-mouthed language of Washington, D.C., "it sounds to me like they are being less than forthright.")
And yes, I am quite aware of the FCC's SDR rules. Why, I have even read them, which is more than virtually anybody else who is commenting has done! A maker certifies their product under the SDR rules *at their own option*, and then (and only then) do they accept certain strictures (they have to take measures to protect against tampering) in exchange for a streamlined re-certification process. AFAICT from the FCC certifications database, NO WIFI RADIO, least of all any Atheros-based radio, has been certified under the SDR rules. The rules simply *do not apply* in WiFi space.
(Now, it is likely that the rules in Europe are stricter than in the United States. Still, Atheros will send you a copy of the U.S. SDR rules if you ask about the regulatory issue.)
Incidentally, every single WiFi radio in existence is
software-defined under the FCC's broad definition. Some of them nevertheless have open-source drivers that let you adjust the tuning and power control by getting directly at the hardware. See, for instance, the open-source ADMtek drivers for BSD and for Linux. I wrote the former driver, and I didn't have to break U.S. law to do it. And the manufacturer supports new development on the driver.
Finally, I will just add that the FCC has traditionally not required even a modicum of tamper-proofing on Part 15 devices. Their long-standing position has been that a device need only protect consumers from *inadvertently* or *casually* tuning a channel they're not entitled to use, or setting an illegal power level, in order to qualify for certification. Furthermore, the FCC seems to be aware that determined radio hackers with malicious mis-use in mind will not be stopped. Hacking a wireless driver for illegal channels or transmit powers is not the "casual" or "inadvertent" consumer activity that the device certification process is designed to prevent.
I think the real reason Atheros and other WiFi chipmakers are not opening things up is that they want to protect their intellectual property. Someone at Atheros has told me that is a key reason. I doubt that there are major innovations in the software interface (register set, descriptor ring format, blah blah) that give deserve protection because they give them a competitive advantage, but this wouldn't be the first time that a chipmaker saw it that way.
You might ask, why does it matter whether the software interface concealed by the HAL is opened up? First, so that radio experimenters and open source developers can innovate with WiFi at their own pace and according to their own agenda. Second, because the HAL documentation is virtually non-existent, and nobody is going to write it. Third, (Theo will appreciate this) so we can audit the code (which runs w/ all the privileges on your Linux/BSD system!) for bugs. Fourth, so that we can fix the bugs---and there *are* bugs.