[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPLv3 comedy unfolding -- FSF hires new GPL compliance engineer

From: Alexander Terekhov
Subject: Re: GPLv3 comedy unfolding -- FSF hires new GPL compliance engineer
Date: Tue, 29 Aug 2006 00:09:31 +0200

true expert in "derivative works" under copyr^Hleft regime in the GNU

Dear Chris

I apologize for the delay in getting back to you. Your questions
generated some discussion over here, and I wanted to make sure we got
you the best possible answers.

> I have some questions below I am hoping you, or someone, can
> answer for me so that I can get some clearer understanding as
> to why they are a violation.

I've addressed your questions as best I can below. Please feel free to
reproduce in full any e-mail that I send you. I ask that you please
don't just quote specific portions of the mail, or omit any parts; the
context goes a long way to prevent confusion.

> > We believe that kernel modules are derivative works of Linux.
> Can you explain WHY you believe the kernel modules are
> derivative works of Linux? What actually makes them a derivative work?

The term "derivative work" is defined in copyright legislation,
including all the relevant case law. Put generally, one piece of
software is a derivative work of another if the first is combined with
the second to provide some functionality. This is true even if the
functionality is optional or not commonly used. For example, if a
program uses readline to provide support for rich command editing, it's
a derivative work of readline.

Note that this does require a dependency on a *specific* piece of
code, instead of on software that performs a particular function. A wide
variety of programs run on systems with the Linux kernel, but they're
not all derivative works of Linux: most simply require that the kernel
recognize certain system calls, which is more about functionality than
particular code. Likewise, web browsers have the capability to interact
with web servers, but this does not make the browser a derivative work
of any particular server.

There is admittedly a fuzzy line here; in close cases, deciding
whether one work is a derivative of another is a judgment call, which is
why we have courts. But let me be very clear about this: it is
impossible to write a kernel module for Linux that isn't a derivative
work of Linux. Even if we assume that all these proprietary drivers shun
Linux's implementations of common data structures, perform their own
memory management, and so on, they still have to register themselves as
modules. To do that, they have to use code in the kernel to call
functions like module_init(), and that's enough to make the software a
derivative work of Linux. The argument in the kerneltrap
link you provided that these modules make "no Linux specific calls" is
absurd on its face: if they made no Linux-specific calls, they wouldn't
be kernel modules.

> >If there weren't any special licensing considerations for
> > Linux, we would say that those modules must adhere to the
> > requirements set forth in the GPL.
> So is this due to your understanding that they ARE
> derivative works, and therefore also have to be GPL?

That's correct.

> > In particular, this means that they, too, would be licensed under the
> > GPL, and users would be able to obtain source when the work
> > is distributed in binary form. In such a case, if there were binary-only
> > modules, we would say they were violating Linux's license, along with
> > anybody who was distributing them.
> Would you be able explain why a binary-only module violates the license?

Because such a module is a derivative work, it's subject to the terms in
section 2 of the GNU GPL. Again, if there were no special licensing
considerations for Linux, binary-only modules would clearly violate
section 2(b) of the license.

> > Some kernel developers apparently agree with him. Others do not: I
> > was at OSCon last year, and I saw Greg Kroah-Hartman give a quick
> > presentation about kernel development where he flatly stated that
> > binary modules are illegal.
> Is this presentation available?

He doesn't really elaborate on this issue in the presentation, but
slides are available at
<>; in
particular, see the bottom of

> >It's not clear whether or not Linus' relaxed restrictions are
> > meant to apply to the entire Linux kernel, or just his contributions to
> > it.
> I would assume that he cannot speak for the copyright of code owned by
> other developers.

That's my understanding as well.

> But perhaps he does have some sort of overriding power because
> "Linux" is his trademark, I don't know.

To the best of my knowledge, this would not give him any special
standing. I would expect an argument along the lines of: "Contributors
provided code to Linux when it had this license exception, and so it's
reasonable to assume that they assented to licensing their code with
this exception as well if they didn't say otherwise." Like I said, I
think that's a poor argument, and I hope a court would agree, but it
probably wouldn't be dismissed out of hand.

Instead, we believe that, absent other arrangements, interactions
between developers are governed by the license provided in the code
being written. Under those terms, every programmer who writes a patch is
a licensee of everyone else, and every maintaner who merges that patch
is a licensee of the patch author. For most code in Linux, that's the
plain GPL, with no exceptions.

> Even if he disagrees on behalf of
> "Linux" I think that individual developers have the right to enforce
> their own copyright. Of course it would have to be a part
> against which the violation is occurring.
> Surely iptables cannot lay claim to a violation from
> a video driver if it has nothing to do with his code?

I'm reluctant to give your question a simple yes or no answer, because
copyright law sets a standard for "nothing to do with his code" that's
probably stricter than you think. To keep things simple, let's assume
for the purposes of this discussion that Linux is under the GPL without
any exceptions.

If you distribute a kernel that includes iptables, and makes use of
proprietary video drivers, the iptables developers could likely take
action against you. This is because you've distributed a derivative work
in violation of section 2 of the GPL -- since again, the whole
combination isn't being released under the GPL.

The iptables developers may be able to take action against ATI and
nVidia directly as well, even if their modules don't have any
relationship with iptables itself, by claiming it's contributory
infringement. It's against the law to provide material contribution to
activity that you know will infringe copyright. It's possible that these
companies are doing both: the way they distribute their modules makes it
easy to violate the GPL (which infringes the work's copyright), and it
seems like they must know this is happening, since expressly allow other
parties to distribute their work verbatim.

> > It also means that for a program with many copyright holders, like
> > Linux, it's at least conceivable that any single one of them could hold
> > you accountable for license violations, and that they may not intend
> > for their work to have exceptions in the GPL's requirements,
> > like Linus apparently does.
> Surely they can only lay claim to a violation if it is against their
> code?
> But I guess it needs some clarification on the copyright of Linux as a
> whole, and whether one single piece of code entitles that author to have
> copyright on the entire Linux code.

It does not.

I hope these clarifications help you understand our reasoning better.
Again, this is not legal advice. If you still have concerns, I'd be
happy to address those; just let me know.

Best regards,

Brett Smith
Free Software Foundation Licensing Team 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]