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"

Where do you draw the line??

[EmbeddedJanitor]

I'm not an Intel fanboy by any measure, but I wonder where you draw the line as to where you just accept specs and where you start demanding more detail.

"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.

Re:I can't see this working

[RLiegh]

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.

Re:The interface is the product

[QuantumG]

The firmware could be useful to many people, we just have no idea what they could do with it because we're not given enough documentation for the device. There's either two possibilities, the firmware contains code, can contain bugs and can therefore be hacked to make the device work better or it is "just data" and is therefore not a "creative work" protected by copyright. If anyone had any balls these days we'd know which it was because they'd just distribute the damn binary blob anyway they liked and when Intel decided to sue they'd have to disclose what is in these binary blobs when they present their case in court. If it was just unimportant data the courts would throw it out. If it was code or otherwise "creative" data then their disclosure would be a good starting point for reverse engineering the blob, in which case we'd likely be free to create a clean room implementation of the blob and distribute that.

Re:I can't see this working

[Schraegstrichpunkt]

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.

Re:I can't see this working

[Pharmboy]

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.

Re:Security

[LurkerXXX]

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.

Re:As good a time as any to revisit UDI.

[Wesley Felter]

Linux developers will never allow UDI because it is a stable driver ABI. OpenBSD developers will probably not allow UDI because it supports binary drivers, which they don't want. Probably the only major OSes that would potentially benefit from UDI are OS X and Solaris.