...works for SuSE Linux seller Novell, added a patch that will trigger such a blockage for the USB subsystem he maintains.
"The USB subsystem will not be allowing closed-source kernel drivers to register with it" after February 2008, according to a note with his patch, posted online. Those with proprietary functions can move them above the kernel level, he argued. But his position against proprietary modules has sparked concerns about blocking use of some ISDN networking gear.
A proprietary driver, even if it works, raises complications. "If you have an open source kernel... and you add a binary module into the mix, it reduces your ability to provide the customer the same level of service," says Dirk Hohndel, Intel's director of Linux and open source strategy.
Red Hat shuns proprietary drivers for business reasons, says the Linux firmChief Technology Officer Brian Stevens. "Why wouldn't you want the army of users to resolve it and make the driver a better driver? There are a lot of smart people who work on open source," Stevens says.
The company is urging graphics chipmakers to help open source programmers by sharing hardware details, Stevens added. "We have made a direct request to them to open their specs fully. That's something they're not able to do at this time, but that request came from me," Stevens says.
On the flip side, Intel believes it can use open source drivers to gain against Nvidia and ATI. The strategy parallels the chipmaker's earlier move with wireless networking support, and it has won an ally in Red Hat. "Their partnering with the open source community is a pretty strong advantage," Stevens says.
Intel has new plans for its open source graphics driver work, though Hohndel wouldn't reveal details. "Our [graphics] drivers are open source. We are bringing out some interesting new stuff. It's not released yet," he says.
Warning shot across the bow
Users got a taste of an open source-only world last month from Red Hat. The company inadvertently suppressed the ability to use proprietary kernel modules when it shipped the new version 5 of its popular Fedora Core Linux. The unplanned experiment wasn't pretty for newbies.
"I do not believe the intention was to promote open source modules and to attack proprietary modules," Larabel says. "One of the reasons I personally believe this is the fact that beginning Linux users who tried Fedora Core 5 would experience problems with loading mainly ATI or Nvidia modules and ultimately tarnish Fedora's reputation due to a troubling experience — or so I have gathered from the countless emails I received from those beginning users."
Red Hat unblocked proprietary modules in an update. However, other snags persist. Fedora and Novell's equivalent, OpenSuSE, don't ship with the proprietary drivers, requiring users to jump through extra hoops to obtain and install them. On top of that, updating the kernel sometimes requires a corresponding video driver update.
One change that could ease driver difficulties is a stable interface to the Linux kernel. A stable interface provides a fixed and documented way for a driver to communicate with the kernel. Even if the kernel interior changed, the method of communication would remain the same, and drivers wouldn't have to change with kernel updates, for example.
"I understand the reasons why kernel developers try to steer clear of that," Fear says, giving as an example the wish to preserve maximum freedom to innovate. But a stable interface "would make our lives and the lives of the end users easier", he adds.
With the existing fluid interface in Linux, programmers must provide drivers for numerous kernel variations, and old drivers — open or proprietary — stop working, says Miguel de Icaza, vice-president of development at Novell. "Contrast this with Windows, where there is a stable interface for drivers in the kernel. A driver developed against NT 4 works on XP," he says.
ATI is willing to accommodate Linux's fluid style. "ATI accepts that as part of our day-to-day responsibilities in Linux," Tippett says.
Some worry that a stable interface could lead to more proprietary drivers. Arjan van de Ven, a former Red Hat kernel programmer who now works for Intel, described a speculative "Linux doomsday scenario in which Linux kernel developers accept binary modules and a stable interface. In his scenario, posted on the Linux kernel mailing list in December, hardware companies reverse current open source support and ultimately leave users unable to respond to a serious security vulnerability.
Only some steps of the scenario are unlikely, van de Ven says. Despite this, he remains hopeful. "I believe that the advantages of freedom in the end are strong enough to overcome the counter forces," he says.
Talkback
Proprietary kernel modules are all very well when they work, but you are chained to the vendor's bugfix schedule when they don't. And the kernel hackers can't be expected to help when you've got a black-box driver doing who-knows-what to system memory.
The Open Source Radeon driver may be rudimentary, but it works and will keep on working for so long as there are users out there with the hardware to use it.
Still, it's good to know that NVIDIA are less concerned with intellectual property issues than they are with the complexity of the drivers themselves. Maybe their engineers could work *with* the Xorg / Linux / BSD graphics programmers? After all, some of the Linux Kernel Maintainers actually *work* for Intel. So what's to stop NVIDIA submitting patches too?