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."
You must set it free.
Bahh. What about when we have cases of driver hooks being yanked from the kernel simly because of inflated egos? (I.e. PWC/PWCX)
So why do companies have a problem with free driver distribution?
The Cheese Stands Alone.
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.
Comment removed based on user account deletion
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.
comparison shop for 'your rights online' ? wtf???
That's like the old Lycos at one time put in this automated advertising thing, so you search for libstdc++-devel-3.2.2-5 and it comes back with "Find bargains on libstdc++-devel-3.2.2-5 at Amazon.com!", "See what people are saying about libstdc++-devel-3.2.2-5 on movietalk.com!"
try { do() || do_not(); } catch (JediException err) { yoda(err); }
The hardware -design- is the "keys to the kingdom" not the firmware, and they're not even asking for the firmware binaries to be open sourced - merely licensed so that they can be distributed freely by OSS vendors. Feels like I'm just quoting the article here, so I guess you might need to reread it more carefully.
If you've dealt with traditional firmware it's called "firm" because it's usually written to a flash memory of some sort on the device (be it CD Burner, NIC, etc.) in this case these vendors are cheaping out on an inexpensive piece of flash memory, and instead designing the 'firmware' to be loaded by the driver, thus unless the driver loads it each time the computer is turned on, then it disappears, it is not static. As such, it makes the hardware utterly useless unless you not only have a device driver, but also this firmware binary loaded. If they had spend a few cents extra and invested in a flash chip that moved with the hardware, this wouldn't be an issue. Instead, they've turned a hardware design issue into a software problem, and if they don't allow for that firmware blob to be redistributed with software drivers (be they proprietary or otherwise) from other vendors - the hardware is useless.
Rather than making a strawman argument about this issue which you didn't take the time to fully understand despite the large amount of text and background links in the story, it would really help everyone if people would write the vendors in question and ask for them to make a minor change. No one is asking them to open their designs a la opencores.org, merely license their firmware blobs in such a way that the firmware can be shipped with other Operating systems that -already- have OSS drivers.
(Going to write and call now instead of waste more breath on slashdot responses)
or has BSD been getting a heck of a lot of stories on the main page lately
It's like they haven't been listening to the trolls at all
--
I write stuff, but not that well and not that often...
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.
Its really nice that people who run slashdot themselves now encourage corporate harassment and activist measures by posting people's names and email addresses.
Whats next ? Posting email addresses of likely Presidental voters to get them to switch to Slashdot's favored candidate ?
Honestly, why would someone submit this to Slashdot? I mean, they've managed to submit hundreds of "well written" messages to vendors, and now they're about to fuck it all up by encouraging the illiterate, and largely uninformed masses here to send in their own special brands of wisdom.... Then there's the goatse fans, tubgirl gang, "BSD is dying" trolls and other shining stars of the forum just waiting to get in on the fun... ... oh well, it could have worked ;-)
Code, Hardware, stuff like that.
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
Here is the reply I got when e-mailing him:
/b"
"This is an automatic reply.
I will be away from the office on business in Europe from 12n Monday 11/1 through Friday 11/5. During this time, there may be a delay responding to your email.
I wonder what his expression will be on Monday when he checks his e-mail...
This is about firmware, which is code which gets sent to the device and helps the device work. These are not drivers, which you run on your processor. Typically, firmware is written either for some weird variant of C, or for a completely non-sequential language (for FPGAs). You'd probably have a really hard time compiling it if you had the source. One set of firmware I know of only builds with a particular non-current version of a $10K/seat commercial compiler; this isn't unusual. Furthermore, they're often signed, if only to keep people from messing up their hardware by loading a broken version into it.
In any case, these aren't programs for your computer, and it is merely a matter of convenience that they aren't sealed into the device at the factory (so you can update them without sending the device back). It doesn't make any more sense to want the source for the firmware for your NIC than it would be to ask for the source to the firmware for your microwave.
Previously, the firmware was only available from the manufacturers directly, and licensed such that you weren't supposed to redistribute it. OpenBSD people complained that making people go online to update their NIC so that it works is a bit annoying, and that they'd like to be able to get it from OpenBSD, whose CD they would be getting and who would be happy to download the firmware for them.
Licensing to disallow distribution of proprietary software doesn't prevent this from occurring, whether the software is "firmware" or an "operating system".
All that is gained with this petition is the ability to help an proprietor more efficiently distribute their non-free software. Users still have no idea what that software will do in the future or how it works now. Users don't gain the ability to fix it when it breaks or improve it to make it do something better.
The proponents of this petition and letter-writing drive are clear in their intent: they are stressing popularity over software freedom; their users are gaining the ability to help their neighbor more conveniently lose their software freedom. In a way, it is ironic that this plea to become proprietary software distributors is championed by those who criticize the strong copyleft in the GNU GPL (which the OpenBSD folks are known to do, putting in time to replacing GNU GPL-covered programs with new BSD-licensed replacements).
It's no accident that this call for increased popularity and out-of-the-box utility is being done in the name of "open source". That movement pushes aside software freedom in pursuit of a message to make businesses feel more comfortable. For the open source movement, proprietary software is merely a less technically efficient way of speaking to businesses. Popularity, to them, is more valuable than software freedom. And that's a shame because history teaches that popularity won't get users freedom. Proprietors are chiefly looking to sell users software which denies users their freedom. Proprietors want to treat users as a market, not contribute to the free software community. The open source philosophy makes this more politically feasible.
From the essay:
I realize that not being able to use the latest hardware is inconvenient. But one's software freedom should not take a back seat to convenience.
Digital Citizen
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!
I am not making this crap up, nor am I quoting from some trade rag, journal or online posting. I've spent the last several years as an active, voting participant in IEEE 802.11, sitting in the room with the engineers who design these chipsets and radios. If only one of them, from one company, had explained things this way, it would be one thing. But the reality is that this is the story from all of the mainstream chipset / radio vendors, and it's validated by the other folks in the room who specialize in regulatory issues.
(Here that is again, this time not anonymously. Anonymous comments seem to score really low.)
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.
The African dyoung stays cool in its burrow during the daytime, coming out only at night to forage for food.