Linux GNU License and Gcom Drivers
Occasionally we are asked whether there
is any unusual consideration concerning
the use of the Gcom® protocol software
on Linux given that the Gcom protocol
suite consists of kernel drivers and the
fact that the Linux kernel is published
under the GNU General Public License.
This document is intended to address
The GNU License
There are two forms of the GNU public
license. You can read the text of these
licenses at the Free
Software Foundation's web site.
The gist of the licenses is this. In the GNU General Public License
(GPL) you are required to publish your source code and the source
code of anything that can be considered a "derivative work"
of the GPLed code. According to the terms of this license, this
includes binary modules linked in with the GPLed code.
There is also a GNU Library General Public
License (LGPL), whose name has recently
changed to the GNU Lesser General Public
License. This license is similar to the
full GPL in the requirement to publish
source code, but it contains an exception
that binary modules linked with the LGPLed
code need not have their source code published
and are not considered "derivative
works" of the LGPL code.
The Linux Kernel
The Linux kernel is publshed under the full GPL. It is for this
reason that questions arise concerning proprietary modules that
load into the kernel. One might think that loading a module is the
same as linking with the kernel and that, therefore, the module's
source code must be published.
In 1995, in an e-mail to a discussion group, Linus Torvalds, the
principal copyright owner of Linux, had the following to say.
From: torvalds@cc.Helsinki.FI (Linus Torvalds)
Content-Type: text/plain; charset=ISO-8859-1
Organization: University of Helsinki
In article <firstname.lastname@example.org> ,
Paco Moya <paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN>
> Some weeks ago I posted an article on a probable violation of the GPL.
> It was about a device driver for a frame grabber which could be
> dynamicaly linked with Linux or statically linked with it.
> Some people, namely Linus himself, stated that it was fair use of
> the GPL'd code (the kernel) because no line of code was apparently
> used and the driver was independent enough.
> I'm not a lawyer but I cannot accept this interpretation of code reuse.
> A device driver is not in any way independent of the kernel with which
> it interacts. I'm not talking about interface copyright or patents but
> about logical dependance.
Note that there is no such thing as "dynamically link into the kernel"
in linux. Instead there are "loadable modules".
Now the above may strike some people as nit-picking, but there is one
rather important thing about loadable modules: they can _not_ link
themselves against any random kernel routine. And the routines they
_can_ link against are routines that I consider to be "logically
independent" of the kernel implementation.
Essentially, the kernel module interface is a "library" interface to the
kernel, and kernel modules are considered to be under the GNU _Library_
license. In fact, due to the way kernel modules work, you automatically
do it according to the LGPL so this isn't explicitly stated anywhere,
but that's the way you should think about this.
Another way to look at this - using the legal rather than the moral
viewpoint - is to just see module loading as "use" of the kernel, rather
than as linking against it. I prefer to explain the rationale behind it
using the _moral_ reason to do it, though.
The reason the kernel is exposed in such a LGPL'd way when using modules
is simply that there are a lot of kernel device drivers for unix
available, and they were not all written under linux. If somebody wants
to port his SVR4 driver to linux but doesn't want to GPL it, I feel that
he should have the right to do that, using modules. After all, the
driver wasn't actually derived from linux itself: it's a real driver in
its own right, so I don't feel that I have the moral right to force him
to switch copyrights.
Now, the above said, I _much_ _much_ prefer GPL'd drivers, even if they
are available only as modules. Especially if they were actually
originally written _for_ linux, I consider it a bit dodgy to not use the
GPL (they can potentially be considered derived works even if you don't
actually link them into the kernel per se). But I do not want to force
it on people that arguably are _not_ doing derived work (it would be
rather preposterous to call the Andrew FileSystem a "derived work" of
linux, for example, so I think it's perfectly ok to have a AFS module,
For several reasons a linux module also doesn't always make much sense
unless it comes with sources - if some commercial company thinks that
linux is important enough that they want to do a commercial module for
linux, they may also recognize that a binary module doesn't work for
most linux users who use experimental kernels, for example.
Final note: the linux interpretation is not a "normal" case. I wouldn't
use it as a guide-line to anything else, especially not in user mode.
In other words, loadable modules are
not bound by the full GPL. The exported
kernel interface is considered LGPL.
Linux STREAMS (LIS)
Linux streams is published
under the LGPL, the library form of the license. Thus, STREAMS drivers
linked with Linux STREAMS can be proprietary binary modules. Recently
Alan Cox raised the possibility that since Linus was not the sole
copyright owner of Linux that Linus' opinion that the kernel interface
was LGPL "didn't count". This comment was brought to my
attention and gave rise to the following posting to the LiS news
This is in response to a posting by Alan Cox on the subject of the reach
of the kernel's GPL. The original posting, as it was presented to me,
appears at the end of this response.
In order to respond to Alan's forcefully stated opinion, I more or less
followed his advice and consulted with my attorney. Tom Johnson, of the
firm Sandler, Travis & Rosenberg, formerly with Baker & McKenzie, is an
experienced attorney in matters of intellectual property rights. Here
is his and my joint opinion on this issue.
Alan is incorrect in a crucial point. Linus' opinion very much counts
when it comes to licensing issues. The reason is that in U.S. tort law
there is a concept known as "standing". "Standing" means that in order
to have a court hear a complaint, the person filing the complaint must
be the party that was harmed by the alleged action. This means that I
can't file a lawsuit alleging that you were harmed by someone else's
The case of the Linux kernel is complex in that there are a number of
copyright holders. Unless there is an agreement subordinating all other
copyrights to Linus, each copyright holder retains certain rights with
respect to the portion of the code that they wrote. In Tom Johnson's
"... Linus cannot claim copyright ownership on the whole. Each
copyright owner can sue if the infringer is using the file that
copyright owner created. If a license is granted, the person claiming
violation can only sue if that person's file is being used. Lots of
times, the later files are developed based on or working with the
original files so they become derivative files under copyright law.
That means that the owner of the derivative files can only grant a
license on his own files, not the underlying or original files; neither
can the original file owner grant licenses on the derivative files. If
someone is using both original files and derivative files without a
license, either owner can sue but typically they will cooperate in
bringing a suit."
So, theoretically at least, it comes down to who wrote what in the Linux
kernel. What did Alan write? In the 2.4 kernel source Alan's copyright
appears on 11 files which also contain copyright notices of others. His
copyright notice appears on just 6 files as the sole copyright holder.
These files are mostly sound card drivers and watchdog board drivers.
He does have a sole copyright on the traffic shaping module that seems
to be an interface between IP and serial line network drivers.
So if Alan wanted to file a lawsuit alleging violation of the strict GNU
license, he would have standing in the case that the alleged violator
used any of these eleven files. (Depending on the agreement with the other
joint copyright holder, Alan may not be able to commence a lawsuit without
the agreement of the other joint copyright holder).
By contrast, Linus' copyright appears on 336 files in the 2.4 kernel
source, including a few of the files jointly copyrighted by Alan Cox.
So, what about LiS. First of all, LiS does not utilize any of Alan's
copyrighted files. It uses only core kernel services such as memory
allocation, semaphores, spin locks, IRQ hooking, etc. So I don't see
that Alan has any standing for legal action involving any STREAMS
driver's misuse of his copyrighted code.
Secondly, LiS is GNU Library License code with the explicit intention
that STREAMS driver writers be able to link their binary drivers with
LiS to form a loadable module with no requirement that the driver
writers publish their source code.
Thirdly, if a STREAMS driver writer makes his/her driver loadable as a
separate module, not linked with LiS, and if he/she uses only LiS
constructs without utilizing any inline code from any kernel header
files then that driver is completely free of any possible reach of the
full GPL of the kernel.
The reason for this is that, even if it were held that the kernel GPL
extended to encompass LiS, LiS itself is compliant because the source
code is published. However, I am the copyright holder of LiS and am the
only one with standing to allege license violations of LiS. A
separately loadable module that uses only LiS constructs is in compliant
with the LiS license, and I won't file the lawsuit.
End of case.
From: Alan Cox [mailto:email@example.com]
Sent: Thursday, June 07, 2001 1:53 PM
Subject: Re: [PATCH] sockreg2.4.5-05 inet_create()
> And this is legal according to the "Kernel GPL, Linus Torvalds edition
> (TM)" which says "any loadable module can be binary only". Not "only
> loadable modules which are drivers". It may not be the intention but
> it is the fact.
Linus opinion on this is irrelevant. Neither I nor the FSF nor many others
have released code under anything but the vanilla GPL. By merging such code
Linus lost his ability to vary the license.
So it comes down to the question of whether the module is linking (which is
about dependancies and requirements) and what the legal scope is. Which
is a matter for lawyers.
Anyone releasing binary only modules does so having made their own
appropriate risk assessment and having talked (I hope) to their insurers
In summary, if Alan's objections have
any legal standing it is only regarding
portions of the kernel in which he is
the copyright owner. LiS does not use
any such modules, it only uses core kernel
services of which Linus is the copyright
holder, and Linus has already stated that
these services are to be considered LGPL.
Gcom Driver Code
Gcom's protocol drivers are distributed
in binary form only. They are linked in
with LiS, an LGPL module. LiS is loaded
into the kernel dynamically and uses the
published kernel interface, which Linus
has declared to be LGPL. Therefore there
is no requirement that Gcom publish the
source code to its drivers on account
of the GPL license that governs the Linux