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...
Intel -- Only "Open" For Business
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
While it may seem backwards that Intel, a hardware company, would be loath to release the specs of their hardware so that third parties could develop drivers for it (essentially for free), you have to also assume that the specification itself provides significant insight into some "whiz-bang" hardware implementation that Intel doesn't want to be common knowledge. What seems strange is that de Raadt is calling for BSD-licensed "binary blobs". I can't imagine why he would want that in favor of BSD-licensed code, or better the hardware interface specs.
It's a little bit frustrating that Intel, the de facto standard when it comes to PC hardware, would let its products flounder on certain platforms. Not that there's this huge market for OpenBSD users (it's dying, of course), but the effort involved in keeping the driver off the platform seems to be no greater than allowing the OpenBSD developers to have a crack at it.
If I weren't a Windows user whose hardware is fully supported, I'd be right there with those guys. There's really no excuse for this sort of behavior.
"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.
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."
OK, so although the GPL means BSD can't lift code directly from the Linux base (and there's no reason why that should work anyway), surely it has to be easier developing a driver by studying this code rather than reverse-engineering Windows binaries?
The difference is that Linux is an open-source OS, windows is a closed source one. So, when someone argues that Intel doesn't support OSS, they can point to the fact that a good deal (most?) of their cards do -in fact- run on Linux.
It's not an argument "against theo", it's an argument against expecting Intel to give a shit about what is (in its' eyes) a fringe OS. From Intel's point of view, there simply isn't enough demand to justify changing what they're already doing -- particularly since they're already providing support for Linux.
Looking at GPL code is legal, but the virality of the GPL taints anyone who does so.
Clean room design can help you circumvent this:
http://en.wikipedia.org/wiki/Clean_room_design
do !
Or we'll call you really, really, really dirty names.
There, however, seems to be a small hole in the plan
From 1998, this article describes how Intel was eager to have Linux support UDI, the Uniform Driver Interface.
A lot of water has gone under the bridge since then, but UDI seemed to get submerged.
Sigh the driver does work in OpenBSD but not well. Damien who works on the IPW driver in OpenBSD but which IIRC is also used by Net, Free and OpenSolaris! has been trying to get documentation so he can write a proper OPEN SOURCE driver
i.e.
From: http://damien.bergamini.free.fr/ipw/
"I've started to work on a driver for Intel® PRO/Wireless 3945ABG network adapters, as found in recent Centrino(TM) laptops. Needless to say, this driver won't require any binary-only user-space daemon to operate, contrary to the Linux driver provided by Intel®. Such daemons that must execute as root and have complete access to the hardware are unacceptable for this project."
They are also asking people who use ANY OPEN SOURCE OPERATING SYSTEM to complain so perhaps intel will change their policy regarding firmware licensing, right now a few of the sell out commercial linux distros can distribute the firmware because they have signed restricitve agreements, however the terms are completly unacceptable to many.
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.
Technically-speaking, do you even need need clean room reverse engineering? As long as you don't copy code (i.e. you don't do anything that's prohibited by copyright statute), I would think you're legally in the clear. In that case, the benefit to doing it clean-room-style is that if the code you wrote happened to be very similar to the code you took apart, you would have documentation that shows that you couldn't have lifted code verbatim, because the person who wrote the code never saw the original.
As far as I know, no such "tainting" exists in law, but your boss's lawyer will advise him to have you do things clean-room anyway, so that your laziness doesn't end up adversely affecting the organization.
http://outcampaign.org/
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/
As a user of Alyson Hannigan's film products, I demand that she must give me open access to her networking wetware. I represent thousands of nerd, all of whom want this access, and I am prepared to act as a gatekeeper and distributor, conditional only on being given first access rights. I expect this demand to have every bit as much success as Theo's.
If you were blocking sigs, you wouldn't have to read this.
I think that would legally be called a "derovative product". Clean rooming is making something new that works like something old. Using the existing code to make code that works on a different platform is not the same. Since one runs on Linux and the new would run on BSD, you would have to change a chunk of the code anyway. The only way you can make a "similar" program/driver legally is that whoever is doing the coding is ignorant of the contents of the original piece.
If Microsoft took Apache, then viewed the source and then rewrote it to replace IIS without a clean room method and used their own license, the open source community would go nuts. This is no different. Just because you LIKE the people who are writting the code, that doesn't make it legal or right.
Tequila: It's not just for breakfast anymore!
correct me if I'm wrong-- these cards already work in Linux.
IIRC they require a binary only blob that runs in userspace, and it's x86 only. Even if it was open source, I can understand why they'd want to do it in userspace given that the Linux driver ABI is such a moving target.
OpenBSD want to distribute firmware along with the OS under an acceptable license. They are not asking for the source
code of the firmware. Intel are instractible here, so owners of Intel wireless devices needs to personally accept a license
before downloading the firmware. As an example: http://ipw2100.sourceforge.net/firmware.php
As for open source drivers: OpenBSD wants hardware documentation, not a Linux driver, so that they can write their own drivers.
Intel claims that they are open source friendly and gives out documentation, but the last is clearly a lie since OpenBSD had to reverse
engineer several Intel wireless chipsets.
Giving the appearance of beeing friendly to open source, while not beeing so, is the latest fad in business. Intel is an example
of this fad.
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.
If MS did NOT cleanroom their implimentation, then yes, they would be open to lawsuits. With a cleanroom system, ONE groups will look at the code, and how it works, describe it to a 2nd group who hasn't seen the code but will write the 'new' code based on what the 1st group learned. That way the group coding has never seen the original sourcecode and not likely to be able to violate any copyright law when writing. Patent law is another issue.
You CAN view source code and write your own version of the software, but if any code matches (and because some functions WILL match, out of the fact that there is sometimes only one logical way to do a task) then you get to explain to the judge how "Yes, I looked at the code, but I didn't copy it. No, really.". This is why most places will cleanroom software instead.
Tequila: It's not just for breakfast anymore!
Firmware blobs run only on the chips they are for. They don't run on the central CPU, and they don't run in kernal space, therefore, they aren't a security risk. Drivers blobs are an entirely different matter. Drivers blobs are a security risk and need to be open.
Security is not just one of the chief concerns of the BSD crowd, it is one of Theo's chief concerns. If he's not asking for open blobs, it's because they aren't a security concern.
For Theo de Raat to have a "don't be a jerk" campaign is like RMS having a "shave every day" campaign.
What OpenBSD is doing has worked with other companies. Until someone has hundreds of millions to put into your open source hardware, the OpenBSD's approach has much more likelihood for success useful to other people.