Novell made the right decision even if for the wrong reasons

Novell has decided not to use proprietary Linux modules such as the NVidia accelerated driver. My first reaction was that Novell was being needlessly idiotic. Then I read this article on OSWeekly.com, by Matt Hartley. It calls out the leading Linux distributions for failing to band together to pressure hardware vendors to pre-install Linux. I've been saying basically the same thing for the past few years, so I heartily agree with this article. It was then that it occurred to me that Novell may have made the right decision, even if for the wrong reason.

Before I continue, I have to point out a delicious irony in the first page of the above-mentioned article. It reads, "I have just learned that Novell is working to front a full scale assault on Microsoft's Vista as they ready their own Linux distribution, SuSE 10.1 and that super-cool xgl feature based on OpenGL." I can't help but wonder if the either Novell or the author is aware of the fact that Microsoft owns the patent on OpenGL. SGI used to own the patent, but Microsoft snagged it in one of the infamous "bail-out" deals Microsoft loves to make with struggling competitors. No doubt Microsoft coveted the patent for OpenGL because it was the only credible competition for DirectX. Should OpenGL-based games ever pose a threat to its PC and Xbox game market strategy, Microsoft now has the ability to cause trouble for the competition. Microsoft has hinted at waging patent wars against Linux, and this may be one that it has in mind. But that's a topic for yet another column.

Obviously, the Novell decision affects more than just NVidia, but NVidia practically owns the graphics card market, and for good reason. The video cards that use the NVidia chipsets are top notch. Virtually every computer I own has an NVidia card, and every computer I have owned in the past several years had an NVidia card. Why? They (with a few exceptions) work great, and they work even better on Linux when you use the NVidia proprietary driver. The driver is so popular that many Linux distributions install it by default when they detect that you're using an NVidia-based card. When distributions do not install it by default, it's generally a breeze to install it yourself without having to download the driver from the NVidia web site.

As I said, I'm an NVidia guy, and I'm not familiar with ATI cards or drivers. So I'll spend most of my time talking about NVidia. But the sentiments I am about to express apply to all proprietary drivers, even drivers for devices other than video cards.

Given the quote from vice president of Linux product management "[this decision] gives the responsibility for drivers to the vendors, which is where it belongs", I am inclined to assume Novell made this decision to offload the burden of maintaining the proprietary drivers to the vendors, not to pressure the vendors to reconsider how they license their drivers. That's too bad.

Come together, right now

So to echo the spirit of Matt Hartley's article, I am calling out all Linux distributors to follow Novell's lead, but for the right reasons. It's time Linux distributors, large and small, commercial and free, band together and pressure vendors, especially NVidia, to relicense their drivers under the GPL.

I'm perfectly aware of the fact that vendors like NVidia and ATI have proprietary driver algorithms they want to protect. But as far as I can see, NVidia has already made public all of the source code that comprises the kernel portion of the NVidia driver. That's probably because this code isn't doing anything interesting with the card. As far as I can tell, the NVidia driver doesn't even load a proprietary binary, such as firmware, in order to work. Most of the interesting stuff must take place in the Xorg modules and GL drivers, none of which would taint the kernel no matter how proprietary they may be. I'm not sure whether the NVidia license conflicts with the Xorg license, but that would be a whole 'nother issue.

The kernel issue must revolve around this header in the NVidia driver source (emphasis mine):

/* _NVRM_COPYRIGHT_BEGIN_
*
* Copyright 1999-2001 by NVIDIA Corporation. All rights reserved. All
* information contained herein is proprietary and confidential
to NVIDIA
* Corporation. Any use, reproduction, or disclosure without the written
* permission of NVIDIA Corporation is prohibited.
*
* _NVRM_COPYRIGHT_END_
*/

Well, all of NVidia's information contained therein may be proprietary, but it isn't very confidential in any practical sense. You can browse through the source code all you want. So why not simply change the license to be GPL? WHat harm would that do to NVidia? None that I can see.

The only possible problem I can imagine is if the NVidia driver loads one or more of its proprietary libraries when you run Xorg such that these libraries become part of the kernel at runtime. I don't see any evidence of this, but it's conceivable, since the driver module seems to use up 4 MB, and I don't see how the source code alone compiles into a module that size. Maybe I'm missing something in the code that allocates that huge chunk of memory for reasons other than loading something at Xorg runtime.

But let's assume, for the sake of argument, that this is the case. The NVidia driver is loading proprietary binary code at runtime, and does so in such a way that this proprietary code becomes part of the Linux kernel. Obviously, in this case, it would not solve the problem to relicense the source code as GPL.

It would solve the problem, however, to make that binary code firmware that is licensed such that it can be included in all distributions. The Linux kernel already accomodates drivers with proprietary firmware, so this approach shouldn't taint the kernel. But (assuming NVidia isn't making its source code proprietary for other reasons, such as company politics), then perhaps the need to turn some portion of its libraries into firmware could be the sticking point for NVidia.

Here's why. The only way to switch from loading binary code into the kernel to making this same code firmware would be to modify the NVidia cards. Unless NVidia provided a way for the cards to work with both the firmware approach and existing drivers, this kind of design change would break backward compatibility and force NVidia to rewrite all of its drivers for other operating systems.

I hope NVidia will excuse me if I have little or no sympathy for the company if it has to deal with this problem in order to make its drivers GPL. The same goes for ATI, if ATI faces a similar problem. You can find NVidia chipsets everywhere these days, including embedded systems and motherboards. NVidia must be making a feces-load of cash. Surely it can afford to make this sort of change. It might jack up the price of its video cards, but it could also make these cards run faster.

The beneficial tradeoff would be that the kernel developers would carry the burden of maintaining the source code for the drivers. NVidia would no longer need to modify its source code every time a change in the kernel breaks their current driver code.

Put the pressure on

NVidia has a weak spot for Linux because NVidia's video cards are favored by those companies that use Linux and NVidia for high-performance rendering of graphics for animation, among other things. However, I don't see how anyone could get every Linux user on the planet to ditch their NVidia graphics cards, and I don't know that it would make a big enough dent in NVidia's bottom line even if they did. Maybe I'm wrong, but I think there's a better approach.

Linux distributors should band together to exercise some of their muscle to pressure NVidia, ATI, and others to GPL their drivers. They should make it as difficult as possible to install the proprietary drivers, even if they have to insert boot scripts to delete the modules and the proprietary libraries. They should, as a unified group, threaten to make it extremely painful for all but the most savvy Linux users to install and use the proprietary drivers. Better still, pick one or more alternative video chipsets with GPL drivers (I hear there are good GPL drivers for Intel video chipsets), and rub those in the faces of NVidia and ATI.

Threaten to promote these alternatives in advertising. Threaten to make a deal with Intel (or whoever) to help them sponsor a campaign to "trade in your NVidia/ATI card for $XX off on the alternative". Even better, go after both NVidia and ATI and play them off each other. Make it clear to NVidia and ATI that if one of them goes GPL and the other doesn't, that could make all the difference in video card brand loyalty. It takes only one victory to start a campaign to rip out your NVidia or ATI card in favor of the other because those drivers are finally GPL. Indeed, I might find it hard to give up the NVidia performance I enjoy for an inferior card, but ATI is real competition. I would be among the first to rip out all my NVidia cards and replace them with ATI cards if ATI went GPL.

I'm sure there are other tactics that escape me at the moment that would increase the pressure on NVida, ATI, and others. Some combination could work.

The key here is that the Linux distributions leaders are dropping the ball on several fronts. As Matt Hartley aptly pointed out, they're dropping the ball on getting Linux pre-installed on hardware. When it comes to hardware preloads, they seem to be unaware that if they cooperate more and compete a little less, they'll create a rising tide that lifts all boats. The same applies when it comes to making NVidia and ATI drivers GPL. All Linux distributions would be much more attractive to a wider audience if they all just worked with the favorite video cards of existing and potential customers.

The question is, are the executives and leaders of distributions listening? Are you willing to put in the effort? A lot of you give constant lip service to the importance of free software. How about backing that up with some aggresive pressure on those companies who fail to provide GPL drivers?

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

apply pressure?

FrankR's picture

I am not sure if you can apply pressure to big companies this way.
In the end it's always their own decision. But who knows.

Oopsnosity

bacon's picture

bacon

Intel open-sources graphics driver

Paul Milliken's picture

The following article describes yesterday's announcement by Intel that they will open-source one of their graphics drivers:
http://lists.freedesktop.org/archives/xorg/2006-August/017404.html. Very encouraging.

Paul Milliken

Linux and the The Never Ending Driver Issue

Robert Backlund's picture

I have to confess that I cannot call myself as a Linux Geek, not smart enough for that. I am just one of the lowly end users and have been working with and struggling with Linux, namely Suse Linux since ver. 6.1 to get a productive desktop up and running. The only reason that I still contend with Micro$oft on a daily basis has been difficulties with getting all of my hardware working under Linux. When it comes to drivers I quite frankly could care less where they come from, don't care if they are proprietary or open source and I could care less if they "corrupt my kernel" let me make that decision! I just want my damn hardware to work and I can't stand the Linux purists that constantly insist on making things impossible to use this system. If I did not like many things about Linux I would have given up with it long ago but I still plod along and now that Novel has made it more difficult to use the hardware that I have paid good money for I will no longer use Suse. At least I have been around long enough and have learned enough to know how to install the driver manually (unlike a lot of new users) I keep hearing that this is the year of the Linux desktop; well wake up and smell the roses people. Until you purists get off of your high horses , Linux will never be ready for the average PC user. Unlike Nicholas Petreley I feel that NVIDA needs to be commended for they have been providing drivers that make my video cards work under Linux from the beginning of my efforts with this fine OS unlike many of the other companies out there that refuse to provide drivers for my hardware. Could the reason be because of the attitudes of Nicholas Petreley and his ilk who insist that all companies give up their trade secrets (it is not for him to make the judgment for these companies of how they distribute their drivers) by opening up their drivers to the GPL. One of the things that I do not think that many of these purists get is that everything is market driven and quite frankly Linux just isn't there yet with sufficient numbers for the vast majority of companies to even give us a second thought, they don't need us and don't care if our hardware works while using Linux or not. So it seems to me that everyone in this community should be striving to make things as easy as possible to use Linux especially for the new end user. Like I said before “I just want my damn hardware to work

Give up trade secrets?

Nicholas Petreley's picture

Quite the contrary, I'm all in favor of NVidia keeping its trade secrets private. In fact, if you read the article (did you skip this part?) my suggestion to convert the proprietary binary stuff to firmware (if that's even necessary - it may not be) is designed to allow NVidia to keep its secrets secret.

All I want NVidia to do is make its existing source code (which is already there for anyone to read, so it doesn't protect any secrets) GPL. This would be good for both Linux users AND NVidia. The code would become part of the Linux kernel, and the kernel developers would have to maintain it. That's less work for NVidia. End-users would get distributions that "just work" without having to download drivers after they're done installing Linux (which is usually how it works now).

By the way, this only applies to people who want accelerated NVidia drivers. Linux and Xorg already work with NVidia cards "out of the box". These drivers simply don't take full advantage of the acceleration features of the NVidia cards.

Firmware doesn't make a bit of difference.

cprise's picture

A prime example of devices that use firmware drivers are Wifi cards. And Linux' situation with Wifi is even worse than it is with graphics cards.

Hardware vendors have settled into the practice of uploading the firmware from the driver to the device every time the latter is initialized.

As for not open-sourcing the driver "stub", I suppose Nvidia would like to reserve leeway to change any interface details willy-nilly as much as the FOSS developers do for their ability to 're-engineer, re-compile on a dime'. And Nvidia are already having the interface details dictated (and capriciously reworked) to them at a low level; why have the FOSS folks also dictate the nature of the *inner* interface? I'm sure Nvidia's brightest minds at the core of their engineering efforts have better things to worry about than re-re-accommodating the FOSS politics of the week.

Your suggestion is destructive.

cprise's picture

I don't think the idea of effectively sabotaging binary driver installation processes will be welcomed by the community.

Without a well-maintained Hardware Compatability List that users habitually check before purchasing equipment, the influence FOSS vendors have on PC component OEMs will remain next to null. Until then, they have few if any options for steering users away from incompatible products and bringing consumer pressure to bear on OEMs.

But similar to their lack of interest in creating a desktop-PC software spec, FOSS vendors avoid collaborating on an authoratative HCL that would directly benefit the non-techie consumer. Perhaps constructive measures like this would cost too much in time or money, or perhaps the vendors loathe making committments to end-users. Regardless, neither one has happened yet.

User education would help

X-Nc's picture

I don't necessarily mean that the distros and LUGS need to get all detailed and technical. Simply get the public to understand that if their HW doesn't work it is the device vendors fault. I hear all kinds of whining about how "Linux sucks because it won't run my XYZ card like Windows does." Whenever I come across this I try to gently hammer into said whiners skull that it is not Linux fault but the vendors fault that their XYZ card doesn't work like it does in Windows. When all the users and developers and enthusiasts and distro builders all start pounding away at XYZ vendor to get their $#it together it will happen.

[I'd post this from my actual LJ account (Joe Klemmer) but I keep getting my passwd knarfed-up]

Linux and drivers hardware support

Wendell Anderson's picture

I am pleased to see you and Matt Hartley encourage and even prod GNU/Linux distributors and major vendors to put pressure on Hardware OEMs, especially the major manufacturers.

The stupid politics of technology that has so far hindered or ignored, or end attempted to repress fuller acceptance of GNU/Linux and *BSD growth in the marketplace for graphics and other hardware use is unacceptable.

Keep up the frankness and the pressure.

Wendell Anderson

Band together against Nvidia and ATI

Anonymous's picture

I usually wait for the hardcopy (magazine) but the Nvidia story was too close to my skin to miss. Of course, since that article came out, ATI was bought by AMD for a large-chunk-of-change. And that muddies the water even more.

I too have long been an Nvidia supporter, almost as long as I have been supporting SuSE (since 6.4). But a recent switch to FC5 (because of its better implementation of XEN for one, and it's awesome software updater YUM is slowly winning me over). I too was itching for a look at the goodies OpenSUSE 10.1 was talking about and the new Xgl graphics made me want to give it a try. To get Xgl working you had to jump through some funny hoops. I had heard that Nvidia was tightening its controls on its drivers and that is never good. Needles to say the new Eye-candy didn't work, as if that was a big loss. But the YAST2 installer definitely showed its age being way behind FC5's Yum. I thought opencarpet and red carpet was going somewhere too, but even that rework of Debian's Apt-Get was sluggish at best.
Dropping a favorite for something better is never fun, but necessary.
Back to using FC5, I now look to the possibility of dumping Nvidia for
ATI. After all, all my CPU chipsets have come from AMD. United We Stand, Divided We LOSE.
ELO

Flexibility and configurability

Paul Milliken's picture

You suggest that Linux distributors "should make it as difficult as possible to install the proprietary drivers, even if they have to insert boot scripts to delete the modules and the proprietary libraries". I disagree - a distribution that makes it difficult for users to do what they want with their computers is not what I believe most users are looking for. One of the reasons I run Linux is so that I can configure my computer how I want it. I propose that it should remain the choice of the user if they wish to install proprietary software.

Paul Milliken

Good point

Nicholas Petreley's picture

I think you make an excellent point. This was just one off-the-cuff suggestion as to how to apply pressure to get the drivers licensed under the GPL. Maybe it wouldn't take such a drastic measure.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState