Question Regarding GPL

Rick Moen rick at linuxmafia.com
Sat Jan 21 04:59:33 UTC 2006


[I'm writing this in a bit of a hurry, and hope I don't mess it up.
I'm also hoping I'm not disagreeing with Larry Rosen on the law of
software licensing, which would be a bit like debating talmudic exegesis
with Rashi.]

Quoting Ben Tilly (btilly at gmail.com):
> On 1/20/06, Lawrence Rosen <lrosen at rosenlaw.com> wrote:

> > This entire issue of linking independent modules to Linux has
> > bothered us all for way too long, and from what I read GPLv3 won't
> > solve it--at least not yet. The GPL is ambiguous about such
> > combinations, and regular pronouncements about it from the mountain
> > top don't really help us achieve a common understanding among all
> > the licensors and licensees in the world.
> 
> I don't see how the GPL can possibly address it given its current
> structure.

I'm not clear on how it could with a different structure, either.
Unless GPLv n>2 says "The following things are allowed regardless of
whether they involve derivative works or not", the factual question of
derivation remains inherently _key_, and also external to the licence.

[Micro Star case summary:]

> The question therefore comes down to whether copyright permission is
> needed to write the loadable module in the first place.

And distribute it.

> According to the Microstar case it is possible to wind up with a
> derivative work even though they did not translate, adapt, alter,
> transform, modify, or arrange the Original Work.

The Micro Star case was unusual in that it involved a _gaming_ product,
FormGen's Duke Nukem, such that creative (and copyright encumbered) data
content was embodied elsewhere besides the source code -- in the "MAP"
level definition files and the visual displays generated by processing
those MAP files.  The court held that FormGen's copyrightable interest
in various game elements got used in the creation of MAP files by itself
and users, which Micro Star then gathered a bunch of (those created by
users) and attempted to re-sell.

FormGen's copyright interest "tainted" the users' MAP files (that they 
ground out using FormGen's "Build Editor", and thus "tainted" Micro
Star's product.  Which in turn caused Micro Star to lose.

The main point for computerists is that copyrightable elements of a work
_can_ exist that will never show up in a source code diff -- for the
simple reason that they're not source code.

> My understanding of Galoob says that there should be no copyright
> issues involved with linking as long as the result is not saved. 

I'm not clear on Galoob's relevance, here:  A Linux kernel module _does_
get saved to disk -- by its author.  Ergo, it isn't just a transitory
creation in RAM a la Galoob.

Getting back to my earlier point:  This fixation with "linking" is
actually irrelevant to the applicable legal issue, which is a factual
one about derivation, which is not a related concept at all.

> You'd still have the silly legal question we are discussing about
> whether writing a work that uses Linux' published API for loadable
> modules results in a derivative work.

Eh?  If you're talking about the 2002 Torvalds post, read what he says
carefully, since it's perfectly sensible.  Paraphrasing:

o  The kernel licence doesn't in itself authorise proprietary 
   derivative works.
o  A proprietary kernel module, because of its structure and 
   functioning, looks at first glance suspciously like a derivative
   work of a kernel.  So:
o  The only way it could avoid infringing kernel authors' copyright
   would be if there were compelling reason nonetheless to believe
   it is not a derivative work.
o  The kernel COPYING file specifically clarifies the authors' 
   intention that system calls be a boundary of the work in a 
   copyright sense, but, in particular, no such concession exists
   concerning the module interface.  Therefore:
o  Mere use of the module interface doesn't exonerate a proprietary
   codebase from that aforementioned suspicion, and there had better
   be some other reason to think it's an independent work, such as
   a prior history as pre-existing code used in other OSes.


> 1. As long as there is a factual question about when something is a
> derivative work, there is a factual question about what the GPL says.

Quibble:  There's no question about what the GPL _says_, just about 
the applicability of some of its terms to particular pairs of works -- 
because those terms apply if there's derivation, and not if there isn't.

If I say "Only redheads may enter my house", there's absolutely no
factual question about what I said -- though there might be doubt about
the admissibility of strawberry blondes.

GPLv2 is very clear that derivative works must be in compliance with
clause 3, if distributed.  There's no factual question about what it
_says_, even if you personally have problems determinining if some 
work _is_ derivative or not.

> In particular the question that I had is whether programming to Linux'
> published API for creating a loadable module was sufficient to make
> your code into a derivative work.

As Torvalds pointed out, that's actually irrelevant to the question.

-- 
Cheers,                                        "He who hesitates is frost."
Rick Moen                                                 -- Inuit proverb
rick at linuxmafia.com  



More information about the License-discuss mailing list