Question Regarding GPL

[Ben Tilly]

On 1/20/06, Rick Moen <rick at linuxmafia.com> wrote:
> [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.]

I find that I learn fast when I publically disagree with someone who
knows more than I do on a topic, and then get corrected.  I may not
always ENJOY that mode of learning, but it seems effective. :-)

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

I was thinking that it can't be done with a copyright license, but
could with a contract.

A contract would, of course, require a radically different structure...

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

Point.

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

Another example that just came to mind is that a game called pernband
ran into copyright issues.  The game still exists as ToMe, but it has
no characters resembling any in books written by Anne McCaffrey.

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

The relevance is that the clearly derivative work caused by combining
the module with the Linux kernel generally is transitory and therefore
isn't a copyright violation.

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

We are in complete agreement on that.

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

I am mocking the legal system, not the argument.  Can't I mock the
legal system a little?

Consider what we've established.  Saving something in RAM is
transitory.  Saving something on a hard drive is not transitory.  What
if future computers wound up replacing RAM with a series of small disk
drives?  (Don't laugh, Moore's law is going faster with disk drives
than with RAM, and on current technology curves this will make sense
in a few years.)  Do things that are allowed today suddenly become
banned?

Copyright is a highly artificial concept.  And a lot of very arbitrary
lines have been drawn involving it.  And then subtle distinctions are
seriously argued over by intelligent people.  If you're unlucky then a
subtle distinction that is drawn differently in 2 different states can
be the margin between being sued or not.

I find this state of affairs silly.  Serious, but silly.  It is good
to laugh about things that scare us.

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

Yup.

> > 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 you read "the effect of what it says" where I said "says" then my
original intent should come through.

[...]
> > 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.

Who are you to tell me that I had a different question than the one I
said I had?

The point that I was not confident on in my initial request, and which
therefore was my question, was whether a program that interfaced with
Linux' published API for creating a loadable module necessarily had to
be a derivative work of the Linux kernel.  If conforming to that
interface entails deriving enough from Linux that you're derivative of
Linux, then you really can't legally write a proprietary loadable
kernel module using that API.

Linus' opinion is that it is possible, though difficult.  He thinks
that it can happen, and has happened, for instance with the Andrew
File System.

I strongly suspect that you're confusing his answer to my question
with an answer to a different question.  While Linus accepts that it
is possible to avoid being derivative while you program to the kernel
module interface, he does _not_ believe that restricting yourself to
the kernel module interface is _sufficient_ to avoid being derivative.
 So saying, "Did I restrict myself to this interface?" is irrelevant
to the question of whether you're derivative.

Cheers,
Ben