X
Tech

Open source self-tied knots

Pragmatism demands that proprietary modules be allowed to load in Linux, and requires the creation of a consistent kernel interface for driver developers. Unfortunality, ideals militate against these requirements.
Written by John Carroll, Contributor

I'd known about the debate between open source pragmatists such as Linus Torvalds, who believes that proprietary modules in Linux are permissible provided they're not derived from the Linux kernel, and the license purists such as the FSF which states, in the words of FSF attorney Eben Moglen, that "if the kernel were pure GPL in its license terms...you couldn't link proprietary video drivers into it, whether dynamically or statically."

Funny tug of war, that. You have the person who started the whole Linux project and decided which license it would use describing how he understands the terms of that license pulling against the people who wrote the license and feel their interpretation trumps that of the copyright holder. I don't know about you, but that would annoy the hell out of me.

But the FSF, under Stallman, is all about control over software. You've heard of submarine patents. Well, there's also such a thing as a submarine open source license, and if you think every person who applied the GPL to their code fully understood the ramifications of stating that their software is covered by GPL v2 or "any later versions," you should have your head examined.

Frankly, the FSF interpretation is, to my mind, insane. Why on earth would a license designed to prevent you from EXTENDING the code without releasing source code details of those changes (which, as I've said before, is an efficient way to prevent forking in open source projects) allow it to determine the license used by binary modules that get loaded into the system? If those modules were based on GPLed code, then yes, they should be released under a GPL. I might even argue that if the kernel REQUIRED the presence of those modules to run, then they should be covered by the GPL. However, graphics cards are interchangeable, making them optional add-on components.

If you're a purist and want a completely open source operating system, then you can choose a graphics card for which GPLed drivers exist. Intel, apparently, is on board with this (no pun intended). If you don't care, though, why does the FSF have the right to force you to be free in ways they think you should be (which is really freedom for other people, as most users could care less if they have access to the source code of their drivers).

Yet again, the Free Software Foundation is insisting that the contributions of proprietary companies is unwelcome and unnecessary, even though the facts of software history show that proprietary software is the largest generator of use value in existence. This is silly, IMHO, but pragmatism is a principle completely lost on the FSF.

Yesterday's article on the open source tug of war, however, informed me of something I didn't know, which was that Linux lacks a stable interface to the 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.
...
With the existing fluid interface in Linux, programmers must provide drivers for numerous kernel variations, and old drivers--open or proprietary--stop working, said 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 said.

Some, according to the article, defend this as providing maximum scope for innovation, or as a firewall against the spread of proprietary drivers upon which Linux must rely. But if you get down to brass tacks, what is really being said here is that Linux has no standard interface for driver development.

Imagine if my employer Microsoft did something like that.  Perhaps they defend the lack of a consistent API as a means of giving Windows developers maximum flexibility, or to prevent any one graphics card company becoming too dominant on the Windows platform. It would certainly solve some of Microsoft's legal problems. Sorry, European Commission, we can't document our server APIs because they don't exist.

The chorus of laughter would be deafening.  The same should be the case in Linux. 

Standard APIs are job number one of a product that aims to become the new dominant ecosystem...and yes, that is what most Linux developers clearly want. I'm quite surprised that this is still a problem. ATI may claim that they accept the fluidity of the kernel interface "as part of our day-to-day responsibilities in Linux," but I bet that is said through clenched teeth after months trying to get a driver to work across distributions.

Fragmentation didn't work for old-school Unix. Linux solved the structural issue by providing a level of consistency made possible through use of the GPL. It's worth remembering that before attempting to justify an unjustifiable lack of a consistent Linux kernel interface.

Editorial standards