Want some frustration? Buy a piece of hardware with “Linux support” and try to use it on anything besides x86 GNU/Linux. If you’re fortunate enough to choose a device for which there exists free drivers, you’ll have much more luck. Often, recompiling is all that’s necessary–and if you use a modern distribution, you may not even have to compile it yourself.
Otherwise, you may be in for days of fun trying to explain that the Linux kernel and almost any piece of software you can run on x86 works just fine on PPC, or that FreeBSD or OpenSolaris or all of the other open and stable free operating systems can do much the same.
It’s easy to make the argument that supporting multiple operating systems and hardware platforms with source code (or better, specifications) requires little work on the part of hardware vendors. I’ve made just that argument. Customers don’t pay for drivers–we pay for the hardware.
Some companies do release open drivers and, perhaps more importantly, open specifications for their hardware. These vendors deserve tremendous praise.
What about the other vendors? Let us assume that they are familar with the potential benefits of open source development models and that they appreciate the value of a larger market not tied to a single platform or OS vendor. Assuming this good faith from vendors, there must exist some compelling contrary reason not to provide open specifications or driver source code.
An oft-cited reason is the existence of nebulous “intellectual property concerns”. Yet as the Free Software Foundation points out, using the phrase intellectual property often confuses the issue.
Perhaps disentangling all of the possible types of “IP” will provide insight.
Copyright
It’s easy to dismiss copyright concerns. A hardware vendor that released driver source code under any OSI-approved license would retain its copyright on the code.
The same goes for releasing documentation and hardware specifications.
Thus copyright is not the primary concern for a hardware vendor acting in good faith toward its customers. As further evidence, consider that distributing binary drivers also falls under copyright. The vendor retains that copyright and can license it to other parties at its leisure.
Trademarks
Trademarks are almost irrelevant to releasing source code or documentation. Certainly there’s the potential to misuse the vendor’s trademark, but trademark policies are (comparatively) clear: don’t misrepresent a work.
It’s likely that a vendor with registered trademarks has already defined a trademark policy. Though there are ongoing questions about using trademarks to discourage distribution of derived works, a hardware vendor acting in good faith can produce a sane and usable trademark policy that would not interfere with the creation or continued development of open drivers.
Patents
What if the vendor has patented technologies that releasing source code or specifications would reveal?
Though patents have generated a lot of attention lately, this isn’t actually an interesting question. Patents are already public information. That’s why they exist. The same goes for the case in which the vendor has licensed a patent from another holder, as well. That other patent is also public knowledge.
In a related note, many advanced technologies in hardware and software and especially algorithms are publicly available in journals and the proceedings of strong conferences such as SIGGRAPH. Much information is already public knowledge.
Trade Secrets
Trade secret protection is a possibility. It’s also a risky strategy; there’s little anyone can do to retract a disseminated trade secret. (There are strategies to attempt to prevent the revealing of secrets, but to my knowledge, they focus more on punishment of revealers than prevention.)
Another risk is clean-room reverse engineering. Devices without open drivers but with compelling uses will soon happen. Again, there are potential legal options to restrict the publishing of certain information, but it’s practically impossible to erase secrets so revealed.
The argument that keeping trade secrets protects a vendor against its competitors is also somewhat toothless. There are plenty of potential competitors in places such as Taiwan and South Korea unbound by any reverse engineering concerns–as well as very well-funded competitors with access to their own fabs and high-end equipment such as electron microscopes and experienced engineers.
A very paranoid vendor could always offer specifications under NDA to a few trusted external developers. It’s not an ideal situation, but it happens and it works.
Vendor Secret Shames
OpenBSD’s Theo de Raadt suggests that the real excuse for not releasing source code or specifications is to cover up poor engineering.
Another possibility I bring up for the sake of completeness is pri ce discrimination. Maybe the differentiating factor between the Bronze, Silver, Gold, and Plutonium cards is, in hardware, the value of a single register and, in software, a flag that checks that value and enables and disables features accordingly. Thus a $200 card with a revised driver might suddenly have all of the physical capabilities of a $600 card.
A few vendors have made the mistake of adding benchmarking cheats to their drivers. This code disables certain slow optimizations in certain benchmarking situations while claiming to perform them appropriately. I’ve personally accidentally left debugging code in released software; it’s possible that driver programmers did the same while tracking down very specific bugs and optimization problems. (Of course, releasing source code would help vendors demonstrate that any such situations were accidents.)
The Patent-Related Minefield
Karl Fogel’s Producing Open Source Software suggests the poorly-kept secret that video card manufacturers all violate each other’s overly broad and unpredictable patents.
Publishing specifications (and likely source code) would make this more obvious.
However, patents are already a mutually-assured destruction scenario, except for patent trolls. Yet no patent holder that actually produces a real product wants trolls to succeed.
It’s in a vendor’s best long-term interests to fight software patents in general, rather than making the problem worse in the short term. In this area, free software advocates have much in common with hardware vendors. Reforming the patent system to increase the amount of public knowledge and reward contributing to the technical commons rather than providing ammunition to discourage competitors helps all honest companies.
Maybe They’re Locking You Out
Yet another possibility is that the vendor believes that it cannot allow you to access the full capabilities of the device you’ve purchased.
Perhaps the device blocks you from accessing media files you’ve created or have a license to use, time- or device-shift, or manipulate but not redistribute for your own purposes.
Perhaps the device has modes of operation which may violate regulations in certain jurisdictions for certain users. (I wonder if my now-expired amateur radio license would have given me permission to use higher powered devices on wireless networking frequencies, however.)
The potential for malfeasance rests with any tool, and the primary use of each of these devices is legal. What possible responsibility does the vendor have for the end user’s abuse of a device?
Again, this is an area in which free software and free culture advocates have common ground with hardware manufacturers. It’s difficult–if not impossible–to provide technical solutions that meet the desires of DRM advocates. Legal barriers to providing fully-working hardware make it difficult to compete with hardware from companies in countries without such harsh laws.
Protecting Yourself
Unfortunately, the best choice is not to buy such hardware, when possible. (It’s often a question of pragmatism versus expedience, where short-term benefits mask long-term problems.)
That’s often not possible, especially when buying specialized hardware or devices with difficult-to-replace components, such as laptops.
However, it’s clear that the normal approach–that is, complaining in small groups and rewarding vendors with your business anyway–is not working. Nor does reverse engineering drivers address the root of the problem. It’s valuable in that it mitigates the damage, but it does little to prevent further problems.
Acknowledging vendors with the courage to deal with their customers respectfully and honestly may help. Free and open source software advocates can do a much better job of praising honest efforts to work with communities–and to encourage other companies to do so in a mutually beneficial way.
The ultimate long-term answer is continued work to produce actual and lasting reform of legal systems that reward information hoarding to dangerous extremes. This change will only occur with focused and directed action from the people affected. This means you. Have you shared your concerns about software patents with your legal representative lately? (However, if you like software patents and DRM that prevents fair use, then now is a time for very quiet reflection.)
It’s unfortunate that the acts of a few dedicated individuals and companies have so punished both vendors and their customers. Instead of casting aspersions on each other, perhaps working together for common interests will both increase the market for high-quality hardware from trustworthy vendors and provide free and open source communities with open and redistributable drivers and specifications.
I guess Greg Kroah-Hartman's explicit offer of Free Linux Driver Development on the LKML is particularly interesting in this context.
That was an interesting synchronicity, Aristotle. However, Greg's offer is, more or less, just an official (and very pleasantly worded) presentation of a long-term Linux kernel policy.
Maybe we're all trying to present a more positive face toward vendors.
This is a great overview of the situation. The only other issue that I would add to the list is corporate inertia - changing an existing policy requires internal advocates as well as external ones. It may be that some hardware vendors don't have people that are aware of the issues in positions of influence, and aren't being pressed by larger partners or customers to rethink their position.
Which I find a bit troubling after the Sony rootkit incident. Vendors that insist that their customers run closed source code in kernel space are actually asking for a lot of trust, and organizations that handle sensitive data should probably be asking more questions about proprietary hardware drivers.
@Stuart, thanks for the additions. I'd forgotten temporarily about the issue of sensitive data and unauditable components. That should be an important concern.
Yes, I know it's nothing new. It just hadn't been stated this explicitly, nay, bluntly, before.
One issue which never seems to be raised is the fact that in most cases the hardware vendor, who designs and markets the final assembly, doesn't own the rights to the register specs for the ASICs that they use in their design. In many cases, they have nothing more than a binary license to the drivers.
The companies that must be convinced to open their specs are not the Belkins and EVGAs of the world, but the chip vendors such as Philips, ST and nVidia.
The chip vendors see their customer as being the board vendor, and see no direct benefit to signing up their support organizations to work with people not directly related to product orders.
If there is truly a market for Linux hardware with open source drivers, there should be no reason to just run repurposed Windows hardware. There is always room in the marked for innovative companies--instead of complaining, form a company to build the hardware, make the business case to the chip vendor for releasing open source drivers based on their specs, and do something about it!
In addition to the artificial distinction between high and low end hardware products which may differ only in software or "a single register", there's the issue of OEM versus retail packaging -- with different pricing and different parties responsible for end-user support. Open source would make it harder to charge extra for support on a higher-priced package. Not that there's much support to be had...
@chromatic, regarding "I wonder if my now-expired amateur radio license would have given me permission to use higher powered devices on wireless networking frequencies..."
Assuming your expired US amateur radio license were Technician class or above, you would have been authorized to use up to 1500 watts (and high gain antennas) on, for example, particular channels of the 2.4 GHz 802.11b/g band. Of course, you would have had to comply with FCC Part 97 regulations, including station identification.
Interesting article. One thing to keep in mind is that there is a lot of hardware out there with open drivers, but it is nearly impossible to find that information. There are bits and scraps all over the internet, but no single comprehensive resource. The driver issue would not be such a big deal if we had easy access to that information. I.e., print out the list of video cards with open drivers, go to Circuit City, buy something on the list. Outside of printers, we don't have such a resource. I recently bought a TV tuner and got screwed by buying one without Linux support.
... sadly, you're right on all counts, they're deathly afraid of a "true level playing field" where everyone can see if they are true or false,...cheating, or honest,... and nobody wants to be in that position.
-But then again this just begs that question ?,
"What in the heck are the chip-makers in the business of making chips for in the first place !?!?!?"
...and I ______bet "... you just can't eat one..."
http://www.crynwr.com/on-being-proprietary.html