| A response to Kevin Dankwardt's GPL article |
by Bill Weinberg (Oct. 3, 2002)
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
Talk back! Do you have comments or questions on this story? talkback here
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed