Tech Insider					     Technology and Trends


			      USENET Archives

From: paco@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Paco Moya)
Subject: [Q] GPL violation.
Date: 1995/12/14
Message-ID: <4aprrr$7ag@sanson.dit.upm.es>#1/1
X-Deja-AN: 121854817
organization: Dpt. Ing. Telematica
newsgroups: gnu.misc.discuss

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.

We're about to release a GPL'd library written in C++ using libdl for
easy expansion in runtime. The library implements a base class Filter
which provides support for making instances of derived classes loaded
in runtime. It sounds similar to the case of the proprietary driver
but we do not want proprietary Filters derived from our library.

Dynamic linking is just a special case but object oriented development
is a more general case where derived work don't actually use a single
line of code from libraries but use them. Why bother to write LGPL if
anybody may make works derived from GPL'd code without distributing
sources? If the legal interpretation of GPL allows such behaviours there
is no need for LGPL at all.

I don't know what does the GPL or Copyright law consider a derived work.

Could anyone explain wheather the GPL would allow proprietary classes
derived from a GPL'd class? Does dynamic linking make difference?

Thanx a lot,
	Paco.			fm...@die.upm.es
				p...@neptuno.die.upm.es

From: torva...@cc.Helsinki.FI (Linus Torvalds)
Subject: Re: [Q] GPL violation.
Date: 1995/12/17
Message-ID: <4b0rbb$5iu@klaava.helsinki.fi>#1/1
X-Deja-AN: 122134619
sender: torva...@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$...@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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/