[Archivist's note: The correct name for the copyright-law concept Torvalds has in mind is 'derivative work', not 'derived work'. In discussions of licensing law, I can spot the Linux techies who have absolutely no idea what copyright law really says, by the fact that they pick up Torvalds's slight malapropism and don't know better. In fairness, when Torvalds began addressing the topic, he was attempting to refer to GPLv2 section 2's wording about a work 'derived from the Program'.]




From: torvalds@cc.Helsinki.FI (Linus Torvalds)
Subject: Re: [Q] GPL violation.
Date: 1995/12/17
Message-ID: 4b0rbb$5iu@klaava.helsinki.fi#1/1
Sender: torvalds@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$7ag@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 that could be
> dynamically linked with Linux or statically linked with it.
>
> Some people, namely Linus himself, stated that it was fair use of
> the GPLd 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 dependence.

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 LGPLd 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 GPLd 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




RM notes: The following is excerpted from Alexandro Rubini's interview with Linus Torvalds, published in the September 1998 issue of Linux Gazette:

Alessandro: What is your position about the availability of Linux modules in binary-only form?

Linus: I kind of accept them, but I never support them and I don't like them.

The reason I accept binary-only modules at all is that, in many cases, you have, for example, a device driver that is not written for Linux at all, but, for example, works on SCO Unix or other operating systems, and the manufacturer suddenly wakes up and notices that Linux has a larger audience than the other groups. And as a result he wants to port that driver to Linux.

But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn't feel that I had the moral right to require that it be put under the GPL, so the binary-only module interface allows those kinds of modules to exist and work with Linux.

That doesn't mean that I would accept just any kind of binary-only module: there are cases where something would be so obviously Linux-specific that it simply wouldn't make sense without the Linux kernel. In those cases, it would also obviously be a derived work, and as such the above excuses don't really apply any more, and it falls under the GPL license.




Date: Fri, 19 Oct 2001 13:16:45 -0700 (PDT)
From: Linus Torvalds (torvalds@transmeta.com)
To: Barnes
Subject: Re: GPL, Richard Stallman, and the Linux kernel

[ This is not, of course, a legal document, but, if you want to forward it to anybody else, feel free to do so. And, if you want to argue legal points with me or point something out, I'm always interested. To a point ;-]

On Fri, 19 Oct 2001, Barnes wrote:

> I've been exchanging e-mail with Richard Stallman for a couple of
> weeks about the finer points of the GPL.

I feel your pain.

> I've spent time pouring through mailing list archives, Usenet,
> and Web search engines to find out what's already been covered about
> your statement of allowing dynamically loaded kernel modules with
> proprietary code to co-exist with the Linux kernel. So far, I've
> been unable to find anything beyond vague statements attributed to
> you. If these issues are addressed somewhere already, please refer
> me.

Well, it really boils down to the equivalent of "all derived modules have to be GPLd". An external module doesn't really change the GPL in that respect.

There are (mainly historical) examples of UNIX device drivers and some UNIX filesystems that were pre-existing pieces of work, and that had fairly well-defined and clear interfaces and that I personally could not really consider any kind of "derived work" at all, and that were thus acceptable. The clearest example of this is probably the AFS (the Andrew Filesystem), but there have been various device drivers ported from SCO too.

> Issue #1
> ========
> Currently the GPL version 2 license is the only license covering the
> Linux kernel. I cannot find any alternative license explaining the
> loadable kernel module exception that makes your position difficult
> to legally analyze.

> There is a note at the top of www.kernel.org/pub/linux/kernel/COPYING,
> but that states "user programs", which would clearly not apply to
> kernel modules.
>
> Could you clarify in writing what the exception precisely states?

Well, there really is no exception. However, copyright law obviously hinges on the definition of "derived work", and as such anything can always be argued on that point.

I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (i.e., it is not acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel.

Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work.

What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-contained that doesn't really have any impact on the rest of the kernel. A device driver that was originally written for something else, and that doesn't need any but the standard UNIX read/write kind of interfaces, for example.

> Issue #2
> ========
> I've found statements attributed to you that you think only 10% of
> the code in the current kernel was written by you. By not being the
> sole copyright holder of the Linux kernel, a stated exception to
> the GPL seems invalid unless all kernel copyright holders agreed on
> this exception. How does the exception cover GPLd kernel code not
> written by you? Has everyone contributing to the kernel forfeited
> their copyright to you or agreed with the exception?

Well, see above about the lack of exception, and about the fundamental gray area in any copyright issue. The "derived work" issue is obviously a gray area, and I know lawyers don't like them. Crazy people (even judges) have, as we know, claimed that even obvious spoofs of a work that contain nothing of the original work itself, can be ruled to be "derived".

I don't hold views that extreme, but at the same time I do consider a module written for Linux and using kernel infrastructures to get its work done, even if not actually copying any existing Linux code, to be a derived work by default. You'd have to have a strong case to not consider your code a derived work.

> Issue #3
> ========
> This issue is related to issue #1. Exactly what is covered by the
> exception? For example, all code shipped with the Linux kernel
> archive and typically installed under /usr/src/linux, all code under
> /usr/src/linux except /usr/src/linux/drivers, or just the code in
> the /usr/src/linux/kernel directory?

See above, and I think you'll see my point.

The "user program" exception is not an exception at all, for example; it's just a more clearly stated limitation on the "derived work" issue. If you use standard UNIX system calls (with accepted Linux extensions), your program obviously doesn't "derive" from the kernel itself.

Whenever you link into the kernel, either directly or through a module, the case is just a lot more muddy. But as stated, by default it's obviously derived — the very fact that you need to do something as fundamental as linking against the kernel very much argues that your module is not a stand-alone thing, regardless of where the module source code itself has come from.

> Issue #4
> ========
> This last issue is not so much a issue for the Linux kernel
> exception, but a request for comment.
>
> Richard and I both agree that a "plug-in" and a "dynamically
> loaded kernel module" are effectively the same under the GPL.

Agreed.

The Linux kernel modules had (a long time ago), a more limited interface, and not very many functions were actually exported. So, five or six years ago, we could believably claim that "if you only use these N interfaces that are exported from the standard kernel, you've kind of implicitly proven that you do not need the kernel infrastructure".

That was never really documented, either (more of a guideline for me and others when we looked at the "derived work" issue), and, as modules were more-and-more used not for external stuff, but just for dynamic loading of standard linux modules that were distributed as part of the kernel anyway, the "limited interfaces" argument is no longer a very good guideline for "derived work".

So, these days, we export many internal interfaces, not because we don't think that they would "taint" the linker, but simply because it's useful to do dynamic run-time loading of modules, even with standard kernel modules that are supposed to know a lot about kernel internals, and are obviously "derived works".

> However, we disagree that a plug-in for a GPLd program falls
> under the GPL, as asserted in the GPL FAQ found in the answer:
> http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins.

I think you really just disagree on what is derived, and what is not. Richard is very extreme: anything that links is derived, regardless of what the arguments against it are. I'm less extreme, and I bet you're even less so (at least you would like to argue so for your company).

> My assertion is that plug-ins are written to an interface, not a
> program. Since interfaces are not GPLd, a plug-in cannot be GPLd
> until the plug-in and program are placed together and run. That is
> done by the end user, not the plug-in creator.

I agree, but also disrespectfully disagree ;)

It's an issue of what a "plug-in" is — is it a way for the program to internally load more modules as it needs them, or is it meant to be a public, published interface?

For example, the "system call" interface could be considered a "plug-in interface", and running a user mode program under Linux could easily be construed as running a "plug-in" for the Linux kernel. No?

And there, I obviously absolutely agree with you 100%: the interface is published, and it's meant for external and independent users. It's an interface that we go to great lengths to preserve as well as we can, and it's an interface that is designed to be independent of kernel versions.

But maybe somebody wrote his program with the intention to dynamically load "actors" as they were needed, as a way to maintain a good modularity, and to try to keep the problem spaces well-defined. In that case, the "plug-in" may technically follow all the same rules as the system call interface, even though the author doesn't intend it that way.

So I think it's to a large degree a matter of intent, but it could arguably also be considered a matter of stability and documentation (i.e., "require recompilation of the plug-in between version changes" would tend to imply that it's an internal interface, while "documented binary compatibility across many releases" implies a more stable external interface, and less of a derived work).

Does that make sense to you?

> I asked Richard to comment on several scenarios involving plug-ins
> to explain whether or not they were in violation of the GPL. So far, he
> has addressed only one, and has effectively admitted a hole. This is
> the one I asked that he's responded to:
>
> [A] non-GPLd plug-in writer writes a plug-in for a non-GPLd
> program. Another author writes a GPLd program, making the
> first author's plug-ins compatible with his program. Are now
>the plug-in author's plug-ins now retroactively required to be
> GPLd?
>
> His response:
>
> No, because the plug-in was not written to extend this program.
>
> I find it suspicious that whether or not the GPL would apply to the
> plug-in depends on the mindset of the author.

The above makes no sense if you think of it as a "plug-in" issue, but it makes sense if you think of it as a "derived work" issue, along with taking "intent" into account.

I know lawyers tend to not like the notion of "intent", because it brings in another whole range of gray areas, but it's obviously a legal reality.

OK, enough blathering from me. I'd just like to finish off with a few comments, just to clarify my personal stand:

The "v2 only" issue might change some day, but only after all documented copyright holders agree on it, and only after we've seen what the FSF suggests. From what I've seen so far from the FSF drafts, we're not likely to change our v2-only stance, but there might of course be legal reasons why we'd have to do something like it (i.e., somebody challenging the GPLv2 in court, and part of it to be found unenforceable or similar would obviously mean that we'd have to reconsider the license).

Linus

P.S.: Historically, binary-only modules have not worked well under Linux, quite regardless of any copyright issues. The kernel just develops too quickly for binary modules to work well, and nobody really supports them. Companies like Red Hat etc. tend to refuse to have anything to do with binary modules, because if something goes wrong there is nothing they can do about it. So I just wanted to let you know that the legal issue is just the beginning. Even though you probably don't personally care ;)





From: Greg KH (greg@kroah.com)
To: linux-elitists@zgp.org
User-Agent: Mutt/1.4i
X-Operating-System: Linux 2.2.21 (i586)
Subject: [linux-elitists] Issues regarding Linux closed source drivers
Date: Wed, 12 Jun 2002 09:35:37 -0700

Wow, the number of people who emailed me privately about getting this information was amazing. Seems there are lots of people working at companies who are struggling with this issue right now.

So feel free to print this out with pretty fonts on heavy paper to impress the management types, and distribute it widely.

If anyone wants any point expanded on, or has any other things that should be added, please let me know. The support section should be expanded some more by people who know more about the Linux support business.

In the end, this document is a place to help start discussion with people who do not know about all of the different kinds of issues that keeping a Linux driver source closed entails. This is quite common with companies that are used to writing their own drivers for other operating systems.

thanks,

greg k-h

--------------------------

Issues regarding Linux closed source drivers

First off, consult an IP lawyer. If it isn't worth the money to consult a lawyer, then just release the code under the GPL, it must not be worth that much to your company.

Legal issues around closed source drivers:

Support Issues:

Technical issues:




From: Linus Torvalds (torvalds@transmeta.com)
To: Christoph Hellwig (hch@infradead.org)
Subject: Re: [PATCH] make LSM register functions GPLonly exports
Date: Thu, 17 Oct 2002 10:08:19 -0700 (PDT)
Cc: Crispin Cowan (crispin@wirex.com), Greg KH (greg@kroah.com), linux-kernel@vger.kernel.or