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
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
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
Comments (15 posted)
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:
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
Comments (4 posted)
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
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
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
Comments (11 posted)
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,
- 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,