LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for October 24, 2002Proprietary 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:
My argument is that I want this flag as a hint for authors of
proprietary security modules that I'm going to sue them if they use
hooks called from code I have copyright on. This includes such
central parts as vfs_read/vfs_write.
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:
There is NOTHING in the kernel license that allows modules to be
non-GPL'd. The _only_ thing that allows for non-GPL modules is
copyright law, and in particular the "derived work" issue. A vendor
who distributes non-GPL modules is _not_ protected by the module
interface per se, and should feel very confident that they can show
in a court of law that the code is not derived.
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:
The original binary-only modules were for things that were
pre-existing works of code, ie drivers and filesystems ported from
other operating systems, which thus could clearly be argued to not
be derived works, and the original limited export table also acted
somewhat as a barrier to show a level of distance.
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 FoundationOne 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:
Recent open source groupware products & projects (Evolution,
Kroupware) use Outlook as the baseline for design and
functionality, an approach which benefits users by being familiar,
but doesn't take design risks which could have big pay-offs for
users in power and simplicity. We're trying to re-think the PIM in
fundamental ways and expect to be judged in terms of our success in
achieving that goal.
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 updateAs 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
|
|||||||||||||