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