Learn more about Gcom, Inc. - the protocol people

Linux GNU License and Gcom Drivers

Introduction

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 these concerns.

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)
Date:         1995/12/17
Message-ID:   <4b0rbb$5iu@klaava.helsinki.fi> 
Sender:       torvalds@cc.helsinki.fi
References:   <4aprrr$7ag@sanson.dit.upm.es> 
Content-Type: text/plain; charset=ISO-8859-1
Organization: University of Helsinki
Mime-Version: 1.0
Newsgroups:   gnu.misc.discuss

In article <4aprrr$7ag@sanson.dit.upm.es> ,
Paco Moya <paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN>
wrote:
> 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 example). 

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. 

                Linus

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 archive.

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
actions.

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
words:

"... 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.

David Grothe

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Thursday, June 07, 2001 1:53 PM
To: hps@intermeta.de
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sockreg2.4.5-05 inet[6]_create() 
                register/unregister table

> 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 kernel.

Customer Support Customer Incident Tracking System Download Directory Documents Library