OpenBSD Activism Shows Drivers Can Be Freed

grey writes "The Age has a story up about how the OpenBSD community has been contacting wireless chipset vendors to license their firmware binaries under terms that would allow for free redistribution. This is important, because even with existing GPL and BSD licensed drivers for these chipsets, the drivers don't function without first loading onerously licensed firmware binaries which can only be acquired from the vendor, not shipped by an OSS provider." (Read more, below.)

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

Comments

Why NOT?

[TexasDex]

Really. I never understood the reason for such restrictive licenses on drivers. I could distribute the drivers far and wide, but without buying the company's hardware (read: paying them money) they are really really useless.

So why do companies have a problem with free driver distribution?

Re:Why NOT?

[MBCook]

Here is my guess, as always, IANALBIPOOSD (IANAL but I play one on /.).

Legal stuff always tries to reserve as many rights as possible for the company, so when they came up with the license for the drivers they came up with a license that gave almost no rights to people (as licenses usually seem to do). And that's the way it's been for a long time because, untill now, no one needed that ability. I mean other than with OSS (IE in the Windows, DOS, or Mac worlds) what reasons would anyone have for wanting to be able to distribute a tiny part of a driver (the firmware) without the rest of the driver for free? The only times I ever saw drivers given out (other than with hardware) was on CDs that game with magazines (so you could get the lastest that way) but then they include the full driver anyway.

Basically, no one cared before now, so there was no reason to give it to people. Now people want it, and I see no reason why there shouldn't give it up (it's not like we're asking to have it open sourced or the rights to dissassemble it or anything).

Re:Why NOT?

[Coneasfast]

They don't want you getting a driver from some shady site that put a virus in it, and thus giving their company a bad name (at least for dumb-computer-users).

1) most people should know to download drivers from the computer manufacturer / device manufacturer. and if someone wanted to do that, they could without having the source code, just have to put a virus in the installer or reverse engineer the code.

2) i don't think this is the issue here, look how many drivers are in the BSD/linux source code, has this really become a problem? no. will it ever? probably not.

Re:Why NOT?

[cmowire]

A variety of reasons, and there's probably a bunch more that I'm not aware of:

• Legal counsel decides it's a bad idea because it could expose them to liability
• It really does expose them to liability. For example, you could exceed FCC restrictions on the ISM bands by programming your card to emit more power than it should on frequencies it's not allowed in the US to be in.
• They are selling the same hardware as three different products with only the drivers different.
• You could make a linux-based device cheaper than their stand-alone equivelent.
• There are bits of licensed code in the driver that aren't theirs to give out.
• They are using a reference design and the driver contains features unique to their product. If they let the driver out, people will be able to buy the cheaper implementation of the same reference design and get those features.

Re:Why NOT?

[networkBoy]

I think the real concern of the companies is that often drivers contain lots of information about the architecture of the hardware, that if it were to fall into "enemy hands" would compromise valuable IP assets that are likely trade secrete rather than patented.
I know this to be the case where I work.
-nB

Re:Why NOT?

[SydShamino]

Dude, note that this is for FIRMWARE, not drivers. Big difference.

Hardware used to do things using discrete transistors, resistors, diodes, etc. These days most of that (and more) can be done better in high-density logic devices. But the "top of the line" high density logic, ASICs, still have too great a startup cost for many companies. Plus, they cannot be field upgraded.

The next best logic, FPGAs, are not hard-coded with the firmware. Instead, they load it from a memory source on the hardware - or they load it from the operating system on boot or plug-in. The advantage of the latter is that you don't have to pay for the EEPROM or flash to store the firmware on board, and updating the firmware is as simple as downloading a new binary to your computer. (Overwriting EEPROM or flash firmware on hardware can be dangerous, as a failure could prevent the hardware from being recognized to try again.)

So, firmware (i.e. code for the hardware) ships with the software driver, but is separate from it. Your next question will be: Why don't they open-source their firmware, too?

And the answer here is simple. They have to pay someone to design that firmware, lay out the PCB, spec in parts and materials, and then provide hardware to build those units. If their firmware is available to all, then someone else can take that code, copy their PCB, and produce the exact same board except with no overhead of R&D. Heck, they could even provide (under the table) vendor and device information so that it looked exactly like the primary company's product, would work with their driver, etc.

Why would any company want to do that? One of the early competitors of my company, 15 years or so ago when we used TTL parts, copied the entire product exactly. Reverse engineered the PCB. Then ran advertisements showing the two boards side-by-side, explaining how they were identical except that theirs cost less because they have no research overhead.

So, of course, my company leveraged its research "overhead" to produce a better, faster product that also happened to not be so easily copied. This resulted in our first ASIC. There is no way that we or most other existing hardware companies would return to the days where anyone can copy their products.

Re:Why NOT?

[technoid_]

Because we all know the competition could never go out and buy the product and get the driver from the included CD, or just download it from the manufacturer's site.

The consumer might as well be considered enemy hands.

Re:Why NOT?

[lawpoop]

Also:

• They are using unlicensed code, i.e. code that they shouldn't.

Re:Why NOT?

[Anonymous Coward]

Dude, this article is about -licensing- the firmware in such a way that it can be shipped by OSS vendors - NOT about Open Sourcing it (quote: "Please remember, we are not asking for the vendors to open source their firmware under the GPL or BSD licenses"). Stop trying to answer a question no one was asking, you're either making yourself look foolish or intentionally misleading people when you do such things.

Anyone who wanted to reverse engineer the firmware would have just as tough a time doing it _now_ as they would if the firmware was able to be shipped on a knoppix or OpenBSD CD instead of downloading it from a website with an Intel licensing splash page.

You have some worthwhile points and you explain the distinction between drivers and firmware well, but your argument and company's experience is not relevant in this instance. Getting companies like TI and Intel to license their firmware in a way that allows for other vendors to provide it out of the box is just going to help users - other companies which might be helped or hindered by open sourced firmware will be completely unaffected, because the challenge will remain the same as it is now.

Let's take that intellect and argumentative skills and point it at contacts for TI and intel instead of veering off course.

Re:Why NOT?

[Bastian]

While I agree that most of those are good reasons, I must say that I think that something is terribly wrong with the legal system if the vendor can be liable for my intentional misuse of their product.

I envision a similar situation in which Detroit gets sued because they are liable for a person's speeding ticket. Only the person had to override some sort of speed limiter device in order to do it.

Re:Why NOT?

[ewhac]

A variety of reasons, and there's probably a bunch more that I'm not aware of:

And most of the ones you cited are complete bunk. To wit:

* Legal counsel decides it's a bad idea because it could expose them to liability

Liability for what, exactly? This bogeyman is often trotted out, but only in the vaguest sense. The only concrete example offered thus far is the potential for lawsuits owing to frivolous patents. Sounds to me, then, like a reason to agitate for patent reform rather than screw your userbase. Argument weak.

* It really does expose them to liability. For example, you could exceed FCC restrictions on the ISM bands by programming your card to emit more power than it should on frequencies it's not allowed in the US to be in.

That's not the fault of the manufacturer, that's the fault of the guy driving the HW out of spec, and the FCC will go after him first. If it's later discovered that the HW itself should have enforced those limits, well, that's a separate discussion. Argument invalid.

* They are selling the same hardware as three different products with only the drivers different.

This has always been a completely bullshit way to differentiate between "products", and anyone who does this should be thumped over the head. Argument invalid.

* You could make a linux-based device cheaper than their stand-alone equivelent.

And so also could the vendor. And since all the driver-writing expertise already resides under his roof, he already has all the competetive advantage that he needs to stay ahead. Argument invalid.

* There are bits of licensed code in the driver that aren't theirs to give out.

This is the first valid reason you've offered. However, as an OEM, you really should be thinking much more carefully before agreeing to such terms. You could be shutting yourself off from a lucrative market.

* They are using a reference design and the driver contains features unique to their product. If they let the driver out, people will be able to buy the cheaper implementation of the same reference design and get those features.

Then why weren't you, the vendor, doing this in the first place? Frankly, I'm not interested in compensating for a vendor's lack of business acumen. Argument invalid.

Schwab

Re:Why NOT?

[metlin]

Excellent point.

But that's why you have checksums and digital signatures.

Re:Why NOT?

[halligas]

Legal counsel decides it's a bad idea because it could expose them to liability
Not true, they are already giving this firmware out with the cards, it is just on a cd and can only be installed from Windows. OBSD is merely asking for the ability to package the firmware with their distro.

It really does expose them to liability. For example, you could exceed FCC restrictions on the ISM bands by programming your card to emit more power than it should on frequencies it's not allowed in the US to be in.
Not true, FCC regs do not apply to the manufacturer, they apply to the user.

There are bits of licensed code in the driver that aren't theirs to give out.
OBSD is not asking for the source to be opened. Read the article again. The binary firmware blob, which is already on the CD (but with a onerous re-distribution license) is what is being discussed here. No one cares what the code in the firmware looks like, we just want to be free to give the blob away.

They are using a reference design and the driver contains features unique to their product. If they let the driver out, people will be able to buy the cheaper implementation of the same reference design and get those features.
Again, read the article, the drivers already exist in OSS. The drivers are no good if you can't load the firmware binary.

No one is asking anyone here to open source any code. We just want these vendors to remove restrictions on redistribution of the BINARY firmware (that they themselves already give away).

Good work.

[dickeya]

I'm a little surprised to see that the OpenBSD community is so actively pursuing this, whereas I hear it as an issue for large linux distributions but don't see much being done. I honestly thought the various BSD-type followers were dwindling. It's great to see them working in an area where all open-source type software could use some work.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Salient point:

[gl4ss]

*Why settle for binary only?*

because it's doable and reasonable, and most importantly something that the vendors could agree to.

(they don't really lose anything if they allow the binary versions to be distributed along the os's, all they lose is that people won't dl the files from them directly)

Re:Free distribution = Free

[Anonymous Coward]

Since they can already download the binaries, what's to keep the knock-off producers from doing it now?

The legitimate manufacturers lose nothing and gain market share by doing this. For a hardware manufacturer, it's a winning proposition.

Slashdot - force for harassment

[gorim]

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 ?

Re:Bahh

[erikharrison]

Then you have a seperate issue, with a seperate OS, with a seperate developer, with a different kind of hardware.

PWC hooks in the Linux kernel were hooks that were removed as part of a standard kernel policy, after the driver had fallen under the radar for some time, and that hook was specifically designed to extend the capabilities of working hardware in a way which was legally fishy.

This is the issue of going to a vendor for the licence to redistribute firmware which already has a generic kernel hook for being loaded and will not initialize with said firmware.

Or are you just being crabby?

Re:Theo

[Anonymous Coward]

Dude, Linus does absolutly nothing worthwhile - seriously! He might be 'some' Linux Loser people's God for some stupid reason, but I can assure you, he's completely useless...

Re:Bahh

[ComputerSlicer23]

Oddly enough, what this is doing, is precisely the way that the PWC/PWCX should be handled. He could have easily started shipping a module that was compiled out of tree, or as a patch, then no GPL violations happened (if you compile your own and don't distribute, there's literally nothing that is illegal you can do, it's only at the point that you distribute binaries that you get into trouble). He could have designed the other module to merely hook into it if it was loaded as opposed to designing it to require a function pointer. That was where it all went so badly wrong. If the binary only module was loaded inplace of the GPL'ed version it would have been fine. The problem was that the GPL'ed one was runtime linking to non-GPL'ed code. The code he was putting into the binary only version was clearly developed independently of Linux in the same fashion that the NVidia driver was (it was used in a different OS first, and it used essetially the same interface to the kernel as userspace does, thus passing Linus's criteria for not being a derived work).

The problem was that there was a hook there that had the sole purpose of explicitly violating the GPL. Here, the firmware isn't linking with the GPL'ed code. So it's all good. This is uploading firmware from userspace via the kernel. Requiring it to be GPL'ed is like requiring that the files I read and write be GPL'ed because they passed thru the kernel.

The firmware loading is there to resolve several pseudo GPL violations (I believe Adaptec has long strings of stuff that is a binary code that gets loaded into the firmware that people claim "we should have the source"). I've always held the believe that that code is not linking with the GPL'ed code, it is merely data as far as the kernel is concerned (you don't have to GPL the constants you use in drivers). While the firmware is intersting and it's plausible that OSS could improve it, it just saves the costs of burning a ROM in case there are bugs that have to be fixed.

This all came up not that long ago and was a possibly blocking problem with the next debian release, but they choose to overlook the problem. The firmware loading is clever because it solves several problems, and is more flexible, and moves the problem outside of the kernel, and turns it into a data problem, not a code problem.

Kirby

Re:Firmware is not drivers

[drfreak]

These are not drivers, which you run on your processor.

True, but the firmware is still needed in order for the driver to do it's job. The issue is not about the public having access to firmware source code, the issue is that these developers need to be able to re-distribute the firmware binaries in order for their drivers to work "out of the box." From what I can see in reading the emails, these licenses are too restrictive for the developers to feel safe in re-distributing them. One of the replies I read from Intel seemed like it was saying they do not mind redistribution, but interpreted the letter sent to them as a plea to change the binary license to be compatible with BSD. I think if there was more communication and less threats against the use of this hardware, a lot more might get done. For the above example, maybe just asking for clarification in writing about permission to re-distribute the firmare binaries would solve the problem?

This reminds me of the majority of distributions that refuse to bundle proprietary video card drivers with their CDs because they do not think they can. Both NVidia and ATI have no problem with the re-distribution of their drivers. NVidia even gives the option of repackaging the driver already compiled for your own custom kernel, and gives a command-line option for their .run installer to do so.

Is there not a happy medium we can reach here? Do we absolutely need to be balking at licenses that allow us to integrate these products in our distributions just because they do not allow us to make modifications?

Don't help distribute problems.

[jbn-o]

They don't want you getting a driver from some shady site that put a virus in it, and thus giving their company a bad name (at least for dumb-computer-users).

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:

The main argument for the term ``open source software'' is that ``free software'' makes some people uneasy. That's true: talking about freedom, about ethical issues, about responsibilities as well as convenience, is asking people to think about things they might rather ignore. This can trigger discomfort, and some people may reject the idea for that. It does not follow that society would be better off if we stop talking about these things.

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.

Re:Don't help distribute problems.

[codguy]

However, in the case of the firmware, I think several different issues come up

No, no, no--this whole argument is irrelevant because this is not what is being requested.

They are only requesting the ability to freely distribute the firmware with OpenBSD and other OSS. They are not asking that the hard-/firm-/software be opened for use by OSS.

Most hardware manufacturers allow Microsoft to freely distribute basic driver software for their products. Does it seem unreasonable that OSS should not be able to distribute they same type of stuff?

Does Microsoft require that hardware manufacturers open the code to them in order for it to be included in Windows? No. And this is the same with OpenBSD's request efforts. They are not requesting that the code be opened, they simply want to be able to distribute it so when you load their distro (or any OSS distro) your hardware will be functional immediately instead of having to go to a website to download it.

This would eliminate many chicken-or-the-egg first problems. For a user that only has wireless connectivity, how will they be able to get to a website to download software if their dumb wireless NIC is brain-dead on arrival because of this firmware load-on-the-fly technique? Yeah, of course there are many solutions, but the simplest one would be to have the firmware freely distributable so it could be included along with any distro.

Loosely speaking, the firmware in question is already freely available--you just go to the website and download it. So the request to simply include it (no reverse engineering, no open source code, etc.) along with an OSS distro doesn't seem outlandish at least to me.

For those who think this only affects OpenBSD, you have quite shallow foresight.

--codguy

Re:If you love your driver

[mav[LAG]]

If it comes back to you, it's yours :)