Question Regarding GPL
btilly at gmail.com
Sat Jan 21 07:33:30 UTC 2006
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.
> > 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
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.
> > 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
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.
More information about the License-discuss