In this open letter, MontaVista Software's Bill Weinberg responds to the recent article by Kevin Dankwardt entitled “Are non-GPL loadable Linux drivers really not a problem?” . . .

---

Hi Kevin,

Very fine article. I have a couple of observations to share:

(1) Source of GPL “Dispensation” for non-GPL modules

Of the various sources for the disputed dispensation, MontaVista and others focus on Linus' own statements, with particular emphasis on the last one you list:

“Code that had a life outside Linux from the beginning, and that do something self-containted [SIC] that doesn't really have any impact on the rest of the kernel”.

On the basis of that statement, indeed, we have been among the “aficionados” of whom you speak (although that makes me an “aficionado professional”).

The “life outside” statement is taken as a mandate for choice in licensing terms for modules, but from a legal standpoint, it raises a question of intent. If a driver, for example, existed a priori, let's say for Solaris, Linus would like to encourage a port to Linux to enrich the technology corpus. But what if a driver writer has before him/her the task of writing a driver from scratch, for at least Linux and perhaps for other OS platforms? If Linux were the first or only target, then Linus appears to encourage (or perhaps demand) that the driver or module be licensed under the GPL. The licensing mandate then hinges on intent — is Linux the primary target OS or truly one of several?

In a recent dialogue with Linus cited by Ted T'so, Linus was urged to make a more definitive statement with regard to module licensing status. He declined, forcefully, saying he felt that he preferred to leave the situation vague, so as not to give the lawyers a chance to leverage any statement. With all due respect to that position, I and others aver that an under-defined set of terms for the interaction of proprietary modules with the GPL kernel accomplishes just the opposite — rogue coders will enter the gap and ignore the spirit and letter of Open Source and the GPL, while many cautious companies and their lawyers will react to the ambiguity by fleeing Linux altogether.

(2) The Effect of Tainting – Poor Messaging

Tainting itself is really not an issue for a developer delivering a mixed derived work — embedded systems are usually a complex admixture of licenses and IP sources anyway. The tainted kernel message itself, however, is very jarring to first-time embedded Linux developers (and their lawyers). It has been a source of friction in a technical support context. How does a company like MontaVista tell a customer new to Linux that it's okay to be “tainted”?

(3) Kernel.org Debugging Woes and Binary Modules

I have great sympathy for the challenge faced by Alan Cox and others when faced with post-mortem dumps in which the calling chain is obscured by binary-only module code. Using his and others' frustration with poorly structured bug reports to justify “tainted” messaging and the imposition of GPL-only exported symbols, however, belies the existence of Linux technology and support organizations outside of kernel.org. It also does not acknowledge the simple fact that in embedded, proprietary modules are the rule, not the exception.

I, personally, and MontaVista as a matter of practice, take pains to encourage customers/partners/developers to build open source code (under the GNU GPL or other OSS license of their choosing). However, we are never in a position to demand that a global embedded products manufacturer “expose” their IP by choosing to license module sources under the GPL, if that's how they perceive such a practice.

The message that the commercial embedded Linux community needs to transmit to kernel.org is “Don't worry about having to debug binary modules on behalf of third parties — that's one of the things that we do well, and indeed is part of our livelihood. And, given that the commercial embedded Linux community services a user base that prefers binary modules, please don't limit the licensing options (GPL, non-GPL – open or proprietary) available to those users.

(4) Technical Reasons to Avoid Binary Modules

Kevin, while I understood how that point in your teaser/abstract played out, it does beg the question — what does an IP-sensitive developer use instead? At this point in history, the alternatives to binary modules are limited and grim:

• defy their own management and legal advisors?
  
• attempt to write driver code in user space using mmap(), etc.?
  
• wait around for a viable user-space driver framework?
  
• ignore GPL norms and practices?
  
• abandon using embedded Linux and go back to the old ways of the proprietary RTOS?

Musings Moot?

Despite the above-cited ambiguity surrounding the licensing status of kernel modules, and the FUD disseminated by the proprietary vested interests, Linux continues to gain design share across the embedded application space. While we, as “insiders” debate and dissect the topics in your article, corporate lawyers and engineering management at global Fortune 100 companies are overcoming their concerns about the GPL and protecting their IP. In ever increasing numbers, they are committing to Linux as their strategic embedded platform.

Should the doctrine of using kernel modules as a vehicle for licensing choice ever be tested in court, the now-pervasive practice of protecting sensitive driver code in binary modules could end up carrying more legal weight as an established precedent than all our musings and those of our Open Source colleagues.

– Bill Weinberg

---

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.