Slashdot Mirror
Intel Accused of Being an "Open Source Fraud"
Binary-Blob writes "Kernal Trap has an article up in which some key OpenBSD developers accuse Intel of being an open source fraud. The issue stems from the prevalence of firmware 'blobs' in open source projects, and OpenBSD's reluctance to use them unless they are distributed freely and without restrictions. Leading project creator Theo de Raadt offers that Intel should follow the example of other companies in the market: 'Intel must do this firmware grant in the same way that Adaptec, Atmel, Broadcom, Cirrus Logic, Cyclades, QLogic, Ralink, and LSI and lots of other companies have granted distribution firmware to be used by others.' He concluded by requesting that the open source community contact Intel to help get them to change their policies"
Intel is lying...
"Just download this firmware blob" is one level, then "just load this microcode". If you're using a Xilinx FPGA running a downloadable CPU core, should that be treated as yet another CPU (ie a sealed blob) or should the downloadable core be considered firmware/microcode? As we get more and more interesting hardware, the boundaries are only going to get more blurred.
Even regular CPUs have an interface (the instruction set etc) and their inner workings are sealed from the software developers.
Engineering is the art of compromise.
Because the source code for firmware is completely useless to all but 5 people on the planet. The firmware isn't the driver, the firmware is just a binary chunk that "SHOULD" be burned into eprom on the hardware.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Why is it that this is one of the most popular arguments against Theo? I mean, sure it works under Linux, but Theo develops OpenBSD.
Next time I hear some Linux user going off about how some device isn't supported I'll just argue that "--correct me if I'm wrong-- this device already works in Windows."
I think you're mixing stuff up.
The "blob" part is like the Nvidia binary drivers for X11.
What Theo is asking for is to be allowed to re-distribute the firmwares
for the chips, so that you can use the network card for installs, for instance.
If you are required to go through a webpage and click Yes before you can use
your network card, then it's pretty much useless for installs unless you already
had another network card in there already.
Then, on top of this, he seems to want the specs for the API used to talk to
this firmware-driven hardware, so that they can write a driver of their own.
Big difference there.
* Firmware - please allow us to redistribute verbatim copies of it.
* API - docs in order to write free drivers.
These are two things needed in order to get those intel cards going.
Since the firmware in one way or another already is available on the
net or on the CD in windows-format, there really shouldn't have to be
such a problem to allow redistribution of it. For the API's, everyones
guess as to why you'd need to keep them secret is as good as theirs.
As he states somewhere, not getting these two parts makes the card
unusable anyhow, so there's nothing to lose really.
-- I'm as unique as everyone else.
The cards won't run without the firmware, not in Linux, not in BSD, not anywhere. Intel forbids distributing the firmware without agreeing to
a restrictive contract. Some Linux distributions happily agree to that contract, and restrict their users by doing this. OpenBSD does not
want to restrict their users, so they don't agree to the Intel contract. They want Intel to give permission to freely distribute the firmware files.
Apparently, they've gone from being "not really open source" to being "an open source fraud". This can be viewed as a progress of sorts and therefore qualifies as news. Hence the new posting.
/. staff shrink to know exactly what the real reasoning was.
At least that's my take on it. We"d have to consult with the
May contain traces of nut.
Made from the freshest electrons.
There are two pieces of software here: the driver (which runs on the host), and firmware (which runs on the card). Theo wants freely redistributable firmware (which can be binary-only for all he cares), and documentation to write a free driver (which definitely must NOT be binary-only). Try not to get confused: He's not asking for free (as in freedom) firmware (though it would be nice), and he's not tolerating binary blobs that run on the host.
http://outcampaign.org/
Can I interject here and point out that none of you are actually on-topic?
This discussion is not about device drivers, it's about the "blobs" that contain things like firmware and the distribution licenses that come with them.
For the most part, OpenBSD is doing pretty well creating device drivers. Indeed, it does better than Linux in many respects: OpenBSD's ipw3945 driver, for instance, is fully self contained and doesn't require the ugly hacks involving user-space daemons that the Linux version does. The author of the OpenBSD driver reverse engineered the Linux driver, and did so in a way that wouldn't taint anything (he hacked the driver to write information about what was being sent to what registers and when, recorded this information, and then wrote his driver. His driver is 99% based upon the actions of source code he's never seen.)
The issue isn't writing device drivers. Most of the devices Theo is complaining about already work under OpenBSD. However, the only way to obtain some critical components, such as the firmware, is to navigate to a website, agree to a license, and download them.
This especially a PITA if you're trying to get a network device to work. You can't access the network without the blob, and you can't obtain the blob unless your network is up. Not impossible to solve, but an added cause of frustration for anyone who's been in this situation.
You are not alone. This is not normal. None of this is normal.