Axioms:
1. Users should not be prevented from choosing whatever operating system, video driver and video hardware suits their needs. A copyright license violation (compared to EULA) cannot occur on the end user's machine since he is not redistributing anything.
2. Vendors should not be prevented from distributing video driver software in whatever form they see fit and for whatever platform they see fit, as long as they are complying with the law in doing so.
3. Open source software is categorically superior than binary only software in terms of maintainability, in terms of supporting different host hardware platforms including those that did not exist at the time of original development, and in terms of building a knowledge base that later innovations can be built upon.
4. Most open source software is superior to binary only software in terms of the license conditions and in terms of flexibility.
5. Any open source software can be better designed and better tested, and therefore more usable, than any binary-only software – given sufficient developer time and a common, fixed set of user requirements between the two.
6. Binary only software provides a superior, but not infallible, vehicle within which to protect trade secrets, hide evidence that could substantiate a patent infringement injunction or award, and hide copyright violations.
7. A system with binary only modules that fails is not practical to debug by code reading and must be debugged interactively. The level of encapsulation does not matter because data that has passed through a binary only module is tainted for purposes of debugging. Strict assertion checking may mitigate this somewhat.
8. An operating system kernel with binary only modules cannot protect other parts of the kernel without sacrificing performance.
9. Precedent has shown that given access to the kernel, third-party binary only code will subvert the user's control of the system, either on behalf of the author of the code, or on behalf of someone else who exploits the binary-only code. Therefore, for a reasonable guarantee of security, it is necessary but not sufficient that the source code is made available to all modules that have access to the operating system kernel.
10. A high frame rate is the number one requirement for a gaming-oriented 3D graphics video card driver.
11. Vendors of 3D graphics cards intended for the consumer market prioritize frame rate and apparent image quality over rendering correctness, reliability, security, or flexibility. Vendors of 3D graphics cards intended for the professional market prioritize image quality, rendering correctness, and operating system stability over other characteristics.
12. The DRI 3D graphics framework that is used by open source operating systems is the best available framework in terms of flexibility and security. Graphics card vendors who have a number one priority of delivering performance and image quality prefer not to use the DRI framework.
13. Open source developers categorically consider flexibility to be a virtue. Therefore, they would prefer a given graphics card to be usable both in a consumer and in a professional context, as well as possessing all of the above mentioned qualities such as reliability and security, to the fullest extent that the hardware permits.
14. Once a driver is developed, the source code of the driver is sufficient reference material in terms of maintainability, portability, and auditability. Therefore, it is irrelevant whether a databook for a piece of hardware is available publicly or whether its availability is restricted under NDA.
There seem to be two issues, with several schools of thought.
a. If hardware manufacturers should provide necessary materials that open source video driver development requires, what the extent of expectations for such materials should be.
b. Whether open source operating systems under the GNU license should attempt to use the GNU license terms with respect to derivative works to compel distribution of driver source code.
Some supporting information on both issues. Any discussion of “drivers” or “databooks” below is limited strictly to the context of 3D hardware drivers and open source developers. When binary-only drivers are mentioned, assume they are for Linux on IA-32 processors unless otherwise noted. 2D acceleration hardware that assumes a planar windowing system is largely considered obsolete and so open source drivers and availability of documentation are not a hotly contended issue. (Some vendors, such as NVidia, contribute directly to open source 2D driver development.)
NVidia and ATI have not released any driver source code recently. They have released binary-only drivers for Linux. NVidia's only driver source code release, in 1999, was deliberately obfuscated. NVidia has never released databooks. ATI has released databooks for Rage Pro, Rage 128, and Radeon 9200 or for Rage Fury MAXX. A reverse engineering effort for the binary-only R300 driver exists meeting with limited success.
Matrox released driver source code developed externally (by Precision Insight, a subsidiary of VA Linux, now VA Software). Matrox also publically released databooks for the G200 and G400. Matrox's driver did not include microcode source for the graphic processor (or for the HAL used to configure the display). Without the microcode source, it is impossible to improve the security architecture of the microcode, as well as to allow the microcode to accept standard OpenGL vertex formats (currently conversion to Direct3D 6 format is necessary, with the associated overhead). It is also impossible to improve the microcode to add new features, such as offloading the T&L rendering stage. Matrox has not released databooks for the G550 or Parhelia products, if they exist. Matrox has not released source code for any Parhelia or video capture/editing product. Matrox has released binary-only Linux drivers for Parhelia. Matrox has removed access to G200 and G400 databooks. Matrox has also placed a EULA prohibiting open source development on their driver source downloads, though it is possible to avoid agreeing to it, further divulging their current attitude. No known open source developer is part of Matrox's development partner program, nor has anyone been known to receive a response from their developer inquiry form. Matrox is largely considered irrelevant to the consumer 3D industry.
3dfx released driver source code developed internally. 3dfx also released databooks to developers. Precision Insight developed the open source Linux drivers for 3dfx hardware. 3dfx is now irrelevant, buried by lawsuits unrelated to its source code release. Documentation or code for the VSA-100 SLI and T-buffer features was not released.
S3, VIA, SiS, and Trident Microsystems did not release source code or binary-only code for any graphics product when they were separate companies. SiS and Trident Microsystems have never released databooks for any graphics product.
S3 had a developer program to receive databooks, with the exception of the Savage2000 which no one has been known to possess a databook for. Based on those databooks, an open source S3 ViRGE driver was created.
VIA used Trident graphics cores until acquiring S3. VIA/S3 has released source code for Unichrome, including the MPEG decoding hardware, but no databooks. Based on that source code, an open source driver for the S3 Savage3D/Savage4 was constructed. The quality of the released Unichrome source code is contested and some hardware features are considered unreliable as long as the source code released as of 2006 is the only documentation. No source code or databooks for Deltachrome or Gammachrome were released. VIA/S3 has released binary-only Linux drivers for all of their integrated graphics platforms.
ST has never released PowerVR, including Kyro, databooks or source code. A binary-only Kyro Linux driver exists. Kyro is considered a dead product. PowerVR and SGX cores are currently being licensed, again with no databooks or source code.
Rendition never released databooks, source code, microcode source, or Linux drivers. Rendition considered the binary-only Verite SDK sufficient for third-party developers. A V2200 databook was leaked after Rendition became irrelevant.
XGI, a spinoff of SiS's graphics division, acquired Trident. XGI has released binary-only drivers for its Volari products but no databooks. The situation has not changed since XGI's graphics unit has been purchased by ATI.
3DLabs has released or leaked a Permedia2 databook and no others. 3DLabs has not otherwise released source code or databooks for Permedia2, Permedia3, GLINT R3/R4, or Wildcat. Binary-only drivers for Linux were released. 3DLabs is now owned by Creative Labs and pursues core licensing.
Intel released databooks for i810 and a mix of source code and binary-only drivers for later integrated graphics solutions. No other databooks have been released.
Based on the above, we can summarize the places where vendors would like to hide programming information about their cards.
– BIOS/firmware
– HAL, if applicable (may be part of BIOS as in Intel)
– 3D processor microcode
– 3D driver
There can be significant assets inside the driver source code. Some of these, such as Macrovision and S3TC texture compression, are patented technologies which are licensed from third parties or covered by cross-licensing agreements. Others are in-house optimization techniques, either hardware-dependent or hardware-independent, which provide a competitive advantage in the market.
The patent system encourages the publication of techniques, but its current climate discourages the publication of source code. Software and technology-related patents tend to border on idea patents. Some are patents on a functional block that takes some input and transforms it to some output; the functional block and output can be so vaguely described as to apply to any transformative process involving the given input. Vague patents can cover software techniques as well as hardware techniques. Even without knowing the physical hardware design, NVidia and ATI representatives have argued to Jon Smirl that any revelation of hardware interface and internal state would be a dangerous situation with respect to the patent situation. However, it is questionable how much weight this holds given that engineers flow back and forth within the industry.
There is no statute of limitations for patent infringement, so any related patent would have to expire before it would be considered safe to reveal one's hand with respect to potential patent violations. This means that a piece of hardware and the accompanying software must be at least 20 years old to be considered safe with respect to patent infringement.
So in summary:
– Companies cannot open-source their drivers that contain externally licensed software and patents.
– Companies that remove the externally licensed software and patents and open-source the rest of the driver would be giving up a competitive advantage in terms of implementation secrets, and potentially opening themselves to patent suits.
– Companies that remove external assets as well as remove any code that would dissolve a competitive advantage if divulged would still suffer from patent liability.
– Companies that externally publish hardware specifications would suffer from patent liability.
– For some companies, it is speculated that the driver source code is the hardware specification.
– An NDA does not change the fact that if the NDA is violated and the individual penalized, the company could still be sunk.
– 20 years must pass before hardware can be safely “opened”. By that time, the hardware's capabilities will be irrelevant, and it is likely that if the company is even still in business, that the associated documents have been lost (possibly intentionally).
The current patent system seems to be the problem. By encouraging vague patents, it invokes the paranoia that discourages publication of driver source code or hardware specifications (if they exist) to third parties.
There is little to be done about the patent system. Since a contract between ATI and NVidia not to sue each other over information divulged through open source development is unlikely, we have few options.
1) Reverse-engineer existing drivers.
2) Convince ATI and NVidia to hire open source developers to work on an open source driver tree free of legal liabilities.
3) Create hardware on our own like OpenGraphics.
1 is difficult, but not as unattractive as it would appear. A reverse-engineered driver will never catch up with hardware to be able to play the latest games, but it will be capable of running all of the existing base of software up until the point the driver was released. So as time passes, this existing software library is larger for a given piece of hardware developed at that time than for a piece of hardware developed at a previous time. This phenomenon is also due to the fact that new software targeting older hardware still in deployment continues to be developed. The hardware itself becomes more complex and difficult to reverse-engineer, but the reward for successfully reverse-engineering successive pieces of hardware is a monotonically increasing percentage of application coverage.
A reverse-engineered driver cannot, however, expose unimplemented features in the driver, and provides only limited information on how the driver architectutre can be improved through more efficient use of hardware.
3 is difficult for a community development project due to the nature of hardware development. FPGA hardware is at least an order of magnitude less efficient/capable than ASIC hardware. However, since graphics is a task of highly parallel nature, it should be possible to exploit this to create fast FPGA-based graphics boards. The cost will not be reasonable compared to ASIC boards, but it will provide an option for those who cannot use or cannot tolerate binary-only drivers.
To be continued.