LWN.net Weekly Edition for October 24, 2002
Proprietary kernel modules - the boundary shifts?
The GNU General Public License places strong requirements on anybody who distributes code derived from GPL-licensed source: the derived code, too, must be released under the GPL. The Linux kernel's license states explicitly that programs running in user mode and making use of kernel system calls are not derived works, and may thus be proprietary. The situation with loadable kernel modules has always been a little more fuzzy, however. The legal status of proprietary Linux kernel modules may heading toward a long-term resolution, however; the news may not be good for vendors of such modules.User-space programs run in a separate address space, in a different processor mode, and communicate with the kernel via special instructions. There is a clear boundary between the two. Loadable modules, however, are linked into the kernel itself; they run in kernel mode, access the kernel address space, and require (GPL-licensed) header files to build. For all practical purposes, they look like part of the kernel itself, and thus should perhaps be seen as derived works.
Linus Torvalds's longstanding policy - never actually written down anywhere - has been that binary-only kernel modules were permissible as long as they restricted themselves to the (never really defined) kernel API. That has been interpreted to mean that modules which use only explicitly exported symbols can be proprietary, and numerous such modules have been shipped over the years. Linus is not the only copyright holder on the Linux kernel, however, and quite a few other kernel developers have been known to mumble that they had never agreed that their code could be linked to proprietary modules.
This situation has thus always been a little unstable. It came up again in recent times when Christoph Hellwig posted a patch which explicitly made the Linux Security Module functionality available only to modules licensed under the GPL. People were, says Christoph, using the LSM hooks to change the behavior of system calls, and that went further than he thought was appropriate. In a separate posting, Christoph stated:
This is, of course, an explicit shot across the bow of anybody who distributes proprietary kernel modules. Linus, then, sent out his current view on binary-only modules:
This is a more restrictive view than has been seen in the past. Linus would likely argue that his position has not changed, but he has not been quite so clear before. One possible reason for a change in attitude can be seen in another quote from the same posting:
What's different now? Certainly one relevant point is that far more kernel functionality is exported to loadable modules. Proprietary modules, once, didn't have the access to kernel internals that they have now. But there may be a more important message here: years ago, binary-only modules were useful for bringing in capabilities that nobody had, yet, been able to write as free software. As the kernel has developed, the role of this sort of imported code has diminished.
In other words, we may be seeing a harder line against proprietary kernel modules for the simple, pragmatic reason that we don't need them anymore. Linux has evolved from a small, struggling system into one of the most capable systems available. Proprietary module vendors now have little to offer the kernel. Over the coming years, it would not be surprising to see the policy on binary-only modules harden further, until one day they are explicitly forbidden.
The Open Source Application Foundation
One might be forgiven for a certain sense of déja vù: a group of longtime industry people, with names like Andy Hertzfeld, gets together with a pile of money to redefine the desktop experience. The story is a little different this time, so a quick look at the Open Source Application Foundation (OSAF) is worthwhile.
The OSAF has actually been operating since the summer of 2001, but it has
only recently made its existence known to the rest of the world. The
Foundation has been funded by Mitch Kapor, the founder of Lotus and a
co-founder of the Electronic Frontier Foundation; its mission is to
"Create and gain wide adoption of Open Source application software
of uncompromising quality.
"
The Foundation differs from the venture-funded exercises of the past few
years, however. It is a non-profit organization, funded by donations.
Thus far, it appears to be working mainly from a big donation from
Mr. Kapor; there is a donations
page for those who would like to add their support as well. The OSAF
thus looks more like the Free Software Foundation than a company like
Eazel, but there is no confusing the two. There appears to be no political
agenda to the OSAF's activities beyond the production of high-quality free
software. The Foundation also foresees ways of revenue generation
("fee-based license for proprietary developers who do not
redistribute source code, the fees fund our core development
") that
the FSF would not approve of.
The first project is ambitious, the creation of an "interpersonal information manager" which will handle email, calendars, contacts, etc. It will be built on top of a number of established free software technologies: Python, wxWindows, the Zope Object Database, Jabber, Mozilla, etc. The calendar component, it is hoped, will be released by the end of the year. The project is seen by many as an alternative to Outlook, though its backers see it as something entirely new. Rather than try to clone Outlook, the OSAF people want to try some different approaches. From a design description posted by Mr. Kapor:
It is, frankly, a relief to see that the project is trying to do something new, rather than chasing the taillights of proprietary application vendors. As they say, we will have to see what they come up with to see if they succeed, but the goal is right.
The days of high-flying companies using venture capital to take over the world with a great new free software platform are done; the likes of Eazel or Zelerate will not be seen again anytime soon. Much of the excess of the dotcom boom will not be missed, but it would be nice if we could retain some of the focused (and funded!) development that those companies created. With luck, the OSAF will do that, at least for one piece of the application space.
LWN update
As of this writing, the LWN.net subscriber count has just passed 2100. That's a far cry from our (near-term) goal of 4000, but the trend is in the right direction. Many thanks to all of you who have subscribed, you have gone a long way toward putting LWN on a solid financial foundation. For the rest of you, will you consider subscribing now?For those of you who took out monthly subscriptions: we are now one month into the subscription experiment, so the first round of automatic billing is beginning to happen. We have recently added a transaction list to the "My Account" area; if you have bought a subscription from LWN you can see a summary of all charges there. It is also possible to generate a printable receipt should you need one.
We are continuing work on the site code to better support the subscription features and our readers. Near-term plans include a gift certificate capability and the integration of the text ad system into the main LWN server. There have been a few requests for a stable (constant) link to the most recent, freely available Weekly Edition; we will be hacking that one up shortly. (Remember also that there is a mailing list available for those who want to know when content becomes free; you can sign up in the "My Account" area). Oh, yes, we haven't forgotten the search engine problem either. Before too long, however, we want to start putting less effort into site code hacking and more into providing the best content we can.
For those of you wishing to pay with American Express: we have an AX merchant account now, but the process of getting it connected up to our credit card gateway is taking a little longer than we had hoped. With luck, that will get sorted out soon.
That is where things stand for this week. Thanks to all of you for your support.
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Linux and email-based exploits; new vulnerabilities with the kernel, mod_ssl, PAM, and ypserv
- Kernel: The last-minute merge wishlist; writing virtual filesystems; <tt>sys_security()</tt> removed
- Distributions: Xandros Desktop OS
- Development: HylaFAX 4.1.5, ALSA 0.9.0 rc4, BusyBox 0.60.4, AFPL Ghostscript 7.31 beta, Zope 2.6.0, Twisted 1.0 Developer Platform, Mozilla 1.2b, FLTK 1.1.1, Samba 2.2.6.
- Press: Xbox broken open, LPIC vs RHCE, Internet Bookmobile, Linux at Wall Street, Ming Poon and Jeremy White interviews, KDE 3.1 review.
- Announcements: IBM Linux Resources, Linux PDA Guide, ecasound docs, Perl jobs, MySQL session, PostgreSQL class, The Solutions Show, Linux Installfests.