1 Date: Thu, 29 Apr 2004 14:10:41 -0700 (PDT)
2 From: Linus Torvalds <torvalds@osdl.org>
4 cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
5 Subject: Re: [hsflinux] [PATCH] Blacklist binary-only modules lying about
7 Message-ID: <Pine.LNX.4.58.0404291404100.1629@ppc970.osdl.org>
9 On Thu, 29 Apr 2004, Giuliano Colla wrote:
11 > Let's try not to be ridiculous, please.
13 It's not abotu being ridiculous. It's about honoring peoples copyrights.
15 > As an end user, if I buy a full fledged modem, I get some amount of
16 > proprietary, non GPL, code which executes within the board or the
17 > PCMCIA card of the modem. The GPL driver may even support the
18 > functionality of downloading a new version of *proprietary* code into
19 > the flash Eprom of the device. The GPL linux driver interfaces with it,
22 Indeed. Everything is kosher, because the other piece of hardware and
23 software has _nothing_ to do with the kernel. It's not linked into it, it
24 cannot reasonably corrupt internal kernel data structures with random
25 pointer bugs, and in general you can think of firmware as part of the
26 _hardware_, not the software of the machine.
28 > On the other hand, I have the misfortune of being stuck with a
29 > soft-modem, roughly the *same* proprietary code is provided as a binary
30 > file, and a linux driver (source provided) interfaces with it. In that
31 > case the kernel is flagged as "tainted".
33 It is flagged as tainted, because your argument that it is "the same code"
34 is totally BOGUS AND UNTRUE!
36 In the binary kernel module case, a bug in the code corrupts random data
37 structures, or accesses kernel internals without holding the proper locks,
38 or does a million other things wrong, BECAUSE A KERNEL MODULE IS VERY
39 INTIMATELY LINKED WITH THE KERNEL.
41 A kernel module is _not_ a separate work, and can in _no_ way be seen as
42 "part of the hardware". It's very much a part of the _kernel_. And the
43 kernel developers require that such code be GPL'd so that it can be fixed,
44 or if there's a valid argument that it's not a derived work and not GPL'd,
45 then the kernel developers who have to support the end result mess most
46 definitely do need to know about the taint.
48 You are not the first (and sadly, you likely won't be the last) person to
49 equate binary kernel modules with binary firmware. And I tell you that
50 such a comparison is ABSOLUTE CRAPOLA. There's a damn big difference
51 between running firmware on another chip behind a PCI bus, and linking
52 into the kernel directly.
54 And if you don't see that difference, then you are either terminally
55 stupid, or you have some ulterior reason to claim that they are the same
56 case even though they clearly are NOT.
58 > Can you honestly tell apart the two cases, if you don't make a it a case
61 It has absolutely nothing to do with religion.
65 Date: Fri, 5 Dec 2003 09:19:52 -0800 (PST)
66 From: Linus Torvalds <torvalds@osdl.org>
68 cc: linux-kernel@vger.kernel.org
69 Subject: Re: Linux GPL and binary module exception clause?
70 Message-ID: <Pine.LNX.4.58.0312050853200.9125@home.osdl.org>
72 On Fri, 5 Dec 2003, Peter Chubb wrote:
74 > As I understand it, SCO is/was claiming that JFS and XFS are derived
75 > works of the UNIX source base, because they were developed to match
76 > the internal interfaces of UNIX, and with knowledge of the internals
77 > of UNIX -- and they hold the copyrights of and are the licensor of UNIX.
79 Yes, and I'm not claiming anything like that.
81 I claim that a "binary linux kernel module" is a derived work of the
82 kernel, and thus has to come with sources.
84 But if you use those same sources (and _you_ wrote them) they do not
85 contain any Linux code, they are _clearly_ not derived from Linux, and you
86 can license and use your own code any way you want.
88 You just can't make a binary module for Linux, and claim that that module
89 isn't derived from the kernel. Because it generally is - the binary
90 module not only included header files, but more importantly it clearly is
91 _not_ a standalone work any more. So even if you made your own prototypes
92 and tried hard to avoid kernel headers, it would _still_ be connected and
93 dependent on the kernel.
95 And note that I'm very much talking about just the _binary_. Your source
96 code is still very much yours, and you have the right to distribute it
97 separately any which way you want. You wrote it, you own the copyrights to
98 it, and it is an independent work.
100 But when you distribute it in a way that is CLEARLY tied to the GPL'd
101 kernel (and a binary module is just one such clear tie - a "patch" to
102 build it or otherwise tie it to the kernel is also such a tie, even if you
103 distribute it as source under some other license), you're BY DEFINITION
104 not an independent work any more.
106 (But exactly because I'm not a black-and-white person, I reserve the right
107 to make a balanced decision on any particular case. I have several times
108 felt that the module author had a perfectly valid argument for why the
109 "default assumption" of being derived wasn't the case. That's why things
110 like the AFS module were accepted - but not liked - in the first place).
112 This is why SCO's arguments are specious. IBM wrote their code, retained
113 their copyrights to their code AND THEY SEVERED THE CONNECTION TO SCO'S
114 CODE (and, arguably the connections didn't even exist in the first place,
115 since apparently things like JFS were written for OS/2 as well, and the
116 Linux port was based on that one - but that's a separate argument and
117 independent of my point).
119 See the definition of "derivative" in USC 17.1.101:
121 A "derivative work" is a work based upon one or more preexisting
122 works, such as a translation, musical arrangement, dramatization,
123 fictionalization, motion picture version, sound recording, art
124 reproduction, abridgment, condensation, or any other form in which
125 a work may be recast, transformed, or adapted. A work consisting
126 of editorial revisions, annotations, elaborations, or other
127 modifications which, as a whole, represent an original work of
128 authorship, is a "derivative work".
130 And a binary module is an "elaboration" on the kernel. Sorry, but that is
133 In short: your code is yours. The code you write is automatically
134 copyrighted by YOU, and as such you have the right to license and use it
135 any way you want (well, modulo _other_ laws, of course - in the US your
136 license can't be racist, for example, but that has nothing to do with
137 copyright laws, and would fall under a totally different legal framework).
139 But when you use that code to create an "elaboration" to the kernel, that
140 makes it a derived work, and you cannot distribute it except as laid out
141 by the GPL. A binary module is one such case, but even just a source patch
142 is _also_ one such case. The lines you added are yours, but when you
143 distribute it as an elaboration, you are bound by the restriction on
146 Or you had better have some other strong argument why it isn't. Which has
147 been my point all along.
152 Date: Wed, 10 Dec 2003 09:10:18 -0800 (PST)
153 From: Linus Torvalds <torvalds@osdl.org>
155 Subject: Re: Linux GPL and binary module exception clause?
157 On Wed, 10 Dec 2003, Larry McVoy wrote:
159 > Which is? How is it that you can spend a page of text saying a judge doesn't
160 > care about technicalities and then base the rest of your argument on the
161 > distinction between a "plugin" and a "kernel module"?
163 I'll stop arguing, since you obviously do not get it.
165 I explained the technicalities to _you_, and you are a technical person.
167 But if you want to explain something to a judge, you get a real lawyer,
168 and you make sure that the lawyer tries to explain the issue in _non_
169 technical terms. Because, quite frankly, the judge is not going to buy a
170 technical discussion he or she doesn't understand.
172 Just as an example, how do you explain to a judge how much code the Linux
173 kernel contains? Do you say "it's 6 million lines of C code and header
174 files and documentation, for a total of about 175MB of data"?
176 Yeah, maybe you'd _mention_ that, but to actually _illustrate_ the point
177 you'd say that if you printed it out, it would be a solid stack of papers
178 100 feet high. And you'd compare it to the height of the court building
179 you're in, or something. Maybe you'd print out _one_ file, bind it as a
180 book, and wave it around as one out of 15,000 files.
182 But when _you_ ask me about how big the kernel is, I'd say "5 million
183 lines". See the difference? It would be silly for me to tell you how many
184 feet of paper the kernel would print out to, because we don't have those
185 kinds of associations.
187 Similarly, if you want to explain the notion of a kernel module, you'd
188 compare it to maybe an extra chapter in a book. You'd make an analogy to
189 something that never _ever_ mentions "linking".
191 Just imagine: distributing a compiled binary-only kernel module that can
192 be loaded into the kernel is not like distributing a new book: it's more
193 like distributing a extra chapter to a book that somebody else wrote, that
194 uses all the same characters and the plot, but more importantly it
195 literally can only be read _together_ with the original work. It doesn't
198 In short, your honour, this extra chapter without any meaning on its own
199 is a derived work of the book.
201 In contrast, maybe you can re-write your code and distribute it as a
202 short-story, which can be run on its own, and maybe the author has been
203 influenced by another book, but the short-story could be bound AS IS, and
204 a recipient would find it useful even without that other book. In that
205 case, the short story is not a derived work - it's only inspired.
207 Notice? This is actually _exactly_ what I've been arguing all along,
208 except I've been arguing with a technical audience, so I've been using
209 technical examples and terminology. But my argument is that just the fact
210 that somebody compiled the code for Linux into a binary module that is
211 useless without a particular version of the kernel DOES MAKE IT A DERIVED
214 But also note how it's only the BINARY MODULE that is a derived work. Your
215 source code is _not_ necessarily a derived work, and if you compile it for
216 another operating system, I'd clearly not complain.
218 This is the "stand-alone short story" vs "extra chapter without meaning
219 outside the book" argument. See? One is a work in its own right, the other
225 Please read the FAQ at http://www.tux.org/lkml/
226 Date: Thu, 4 Dec 2003 22:43:42 -0800 (PST)
227 From: Linus Torvalds <torvalds@osdl.org>
229 cc: linux-kernel@vger.kernel.org
230 Subject: RE: Linux GPL and binary module exception clause?
232 On Thu, 4 Dec 2003, David Schwartz wrote:
234 > Yes, but they will cite the prohibition against *creating* derived
239 The same prohibition exists with the GPL. You are not allowed to create
240 and distribute a derived work unless it is GPL'd.
242 I don't see what you are arguing against. It is very clear: a kernel
243 module is a derived work of the kernel by default. End of story.
245 You can then try to prove (through development history etc) that there
246 would be major reasons why it's not really derived. But your argument
247 seems to be that _nothing_ is derived, which is clearly totally false, as
248 you yourself admit when you replace "kernel" with "Harry Potter".
252 Date: Wed, 3 Dec 2003 16:00:21 -0800 (PST)
253 From: Linus Torvalds <torvalds@osdl.org>
255 cc: linux-kernel@vger.kernel.org
256 Subject: Re: Linux GPL and binary module exception clause?
258 On Wed, 3 Dec 2003, Kendall Bennett wrote:
260 > I have heard many people reference the fact that the although the Linux
261 > Kernel is under the GNU GPL license, that the code is licensed with an
262 > exception clause that says binary loadable modules do not have to be
265 Nope. No such exception exists.
267 There's a clarification that user-space programs that use the standard
268 system call interfaces aren't considered derived works, but even that
269 isn't an "exception" - it's just a statement of a border of what is
270 clearly considered a "derived work". User programs are _clearly_ not
271 derived works of the kernel, and as such whatever the kernel license is
274 And in fact, when it comes to modules, the GPL issue is exactly the same.
275 The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
276 anything that is a derived work has to be GPL'd. It's that simple.
278 Now, the "derived work" issue in copyright law is the only thing that
279 leads to any gray areas. There are areas that are not gray at all: user
280 space is clearly not a derived work, while kernel patches clearly _are_
283 But one gray area in particular is something like a driver that was
284 originally written for another operating system (ie clearly not a derived
285 work of Linux in origin). At exactly what point does it become a derived
286 work of the kernel (and thus fall under the GPL)?
288 THAT is a gray area, and _that_ is the area where I personally believe
289 that some modules may be considered to not be derived works simply because
290 they weren't designed for Linux and don't depend on any special Linux
294 - anything that was written with Linux in mind (whether it then _also_
295 works on other operating systems or not) is clearly partially a derived
297 - anything that has knowledge of and plays with fundamental internal
298 Linux behaviour is clearly a derived work. If you need to muck around
299 with core code, you're derived, no question about it.
301 Historically, there's been things like the original Andrew filesystem
302 module: a standard filesystem that really wasn't written for Linux in the
303 first place, and just implements a UNIX filesystem. Is that derived just
304 because it got ported to Linux that had a reasonably similar VFS interface
305 to what other UNIXes did? Personally, I didn't feel that I could make that
306 judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
309 Personally, I think that case wasn't a derived work, and I was willing to
310 tell the AFS guys so.
312 Does that mean that any kernel module is automatically not a derived work?
313 HELL NO! It has nothing to do with modules per se, except that non-modules
314 clearly are derived works (if they are so central to the kenrel that you
315 can't load them as a module, they are clearly derived works just by virtue
316 of being very intimate - and because the GPL expressly mentions linking).
318 So being a module is not a sign of not being a derived work. It's just
319 one sign that _maybe_ it might have other arguments for why it isn't
325 Date: Wed, 3 Dec 2003 16:23:33 -0800 (PST)
326 From: Linus Torvalds <torvalds@osdl.org>
328 cc: linux-kernel@vger.kernel.org
329 Subject: Re: Linux GPL and binary module exception clause?
332 On Wed, 3 Dec 2003, Linus Torvalds wrote:
334 > So being a module is not a sign of not being a derived work. It's just
335 > one sign that _maybe_ it might have other arguments for why it isn't
338 Side note: historically, the Linux kernel module interfaces were really
339 quite weak, and only exported a few tens of entry-points, and really
340 mostly effectively only allowed character and block device drivers with
341 standard interfaces, and loadable filesystems.
343 So historically, the fact that you could load a module using nothing but
344 these standard interfaces tended to be a much stronger argument for not
345 being very tightly coupled with the kernel.
347 That has changed, and the kernel module interfaces we have today are MUCH
348 more extensive than they were back in '95 or so. These days modules are
349 used for pretty much everything, including stuff that is very much
350 "internal kernel" stuff and as a result the kind of historic "implied
351 barrier" part of modules really has weakened, and as a result there is not
352 avery strong argument for being an independent work from just the fact
353 that you're a module.
355 Similarly, historically there was a much stronger argument for things like
356 AFS and some of the binary drivers (long forgotten now) for having been
357 developed totally independently of Linux: they literally were developed
358 before Linux even existed, by people who had zero knowledge of Linux. That
359 tends to strengthen the argument that they clearly aren't derived.
361 In contrast, these days it would be hard to argue that a new driver or
362 filesystem was developed without any thought of Linux. I think the NVidia
363 people can probably reasonably honestly say that the code they ported had
364 _no_ Linux origin. But quite frankly, I'd be less inclined to believe that
365 for some other projects out there..
372 Date: Thu, 17 Oct 2002 10:08:19 -0700 (PDT)
373 From: Linus Torvalds <torvalds@transmeta.com>
374 To: Christoph Hellwig
375 Cc: <linux-kernel@vger.kernel.org>
376 Subject: Re: [PATCH] make LSM register functions GPLonly exports
377 In-Reply-To: <20021017175403.A32516@infradead.org>
378 Message-ID: <Pine.LNX.4.44.0210170958340.6739-100000@home.transmeta.com>
380 Note that if this fight ends up being a major issue, I'm just going to
381 remove LSM and let the security vendors do their own thing. So far
383 - I have not seen a lot of actual usage of the hooks
384 - seen a number of people who still worry that the hooks degrade
385 performance in critical areas
386 - the worry that people use it for non-GPL'd modules is apparently real,
387 considering Crispin's reply.
389 I will re-iterate my stance on the GPL and kernel modules:
391 There is NOTHING in the kernel license that allows modules to be
394 The _only_ thing that allows for non-GPL modules is copyright law, and
395 in particular the "derived work" issue. A vendor who distributes non-GPL
396 modules is _not_ protected by the module interface per se, and should
397 feel very confident that they can show in a court of law that the code
400 The module interface has NEVER been documented or meant to be a GPL
401 barrier. The COPYING clearly states that the system call layer is such a
402 barrier, so if you do your work in user land you're not in any way
403 beholden to the GPL. The module interfaces are not system calls: there
404 are system calls used to _install_ them, but the actual interfaces are
407 The original binary-only modules were for things that were pre-existing
408 works of code, ie drivers and filesystems ported from other operating
409 systems, which thus could clearly be argued to not be derived works, and
410 the original limited export table also acted somewhat as a barrier to
411 show a level of distance.
413 In short, Crispin: I'm going to apply the patch, and if you as a copyright
414 holder of that file disagree, I will simply remove all of he LSM code from
415 the kernel. I think it's very clear that a LSM module is a derived work,
416 and thus copyright law and the GPL are not in any way unclear about it.
418 If people think they can avoid the GPL by using function pointers, they
419 are WRONG. And they have always been wrong.
423 ------------------------------------------------------------------------
424 Date: Fri, 19 Oct 2001 13:16:45 -0700 (PDT)
425 From: Linus Torvalds <torvalds@transmeta.com>
427 Subject: Re: GPL, Richard Stallman, and the Linux kernel
429 [ This is not, of course, a legal document, but if you want to forward it
430 to anybody else, feel free to do so. And if you want to argue legal
431 points with me or point somehting out, I'm always interested. To a
434 On Fri, 19 Oct 2001, Barnes wrote:
436 > I've been exchanging e-mail with Richard Stallman for a couple of
437 > weeks about the finer points of the GPL.
441 > I've have spent time pouring through mailing list archives, usenet,
442 > and web search engines to find out what's already been covered about
443 > your statement of allowing dynamically loaded kernel modules with
444 > proprietary code to co-exist with the Linux kernel. So far I've
445 > been unable to find anything beyond vague statements attributed to
446 > you. If these issues are addressed somewhere already, please refer
449 Well, it really boils down to the equivalent of "_all_ derived modules
450 have to be GPL'd". An external module doesn't really change the GPL in
453 There are (mainly historical) examples of UNIX device drivers and some
454 UNIX filesystems that were pre-existing pieces of work, and which had
455 fairly well-defined and clear interfaces and that I personally could not
456 really consider any kind of "derived work" at all, and that were thus
457 acceptable. The clearest example of this is probably the AFS (the Andrew
458 Filesystem), but there have been various device drivers ported from SCO
463 > Currently the GPL version 2 license is the only license covering the
464 > Linux kernel. I cannot find any alternative license explaining the
465 > loadable kernel module exception which makes your position difficult
466 > to legally analyze.
468 > There is a note at the top of www.kernel.org/pub/linux/kernel/COPYING,
469 > but that states "user programs" which would clearly not apply to
472 > Could you clarify in writing what the exception precisely states?
474 Well, there really is no exception. However, copyright law obviously
475 hinges on the definition of "derived work", and as such anything can
476 always be argued on that point.
478 I personally consider anything a "derived work" that needs special hooks
479 in the kernel to function with Linux (ie it is _not_ acceptable to make a
480 small piece of GPL-code as a hook for the larger piece), as that obviously
481 implies that the bigger module needs "help" from the main kernel.
483 Similarly, I consider anything that has intimate knowledge about kernel
484 internals to be a derived work.
486 What is left in the gray area tends to be clearly separate modules: code
487 that had a life outside Linux from the beginning, and that do something
488 self-containted that doesn't really have any impact on the rest of the
489 kernel. A device driver that was originally written for something else,
490 and that doesn't need any but the standard UNIX read/write kind of
491 interfaces, for example.
495 > I've found statements attributed to you that you think only 10% of
496 > the code in the current kernel was written by you. By not being the
497 > sole copyright holder of the Linux kernel, a stated exception to
498 > the GPL seems invalid unless all kernel copyright holders agreed on
499 > this exception. How does the exception cover GPL'd kernel code not
500 > written by you? Has everyone contributing to the kernel forfeited
501 > their copyright to you or agreed with the exception?
503 Well, see above about the lack of exception, and about the fundamental
504 gray area in _any_ copyright issue. The "derived work" issue is obviously
505 a gray area, and I know lawyers don't like them. Crazy people (even
506 judges) have, as we know, claimed that even obvious spoofs of a work that
507 contain nothing of the original work itself, can be ruled to be "derived".
509 I don't hold views that extreme, but at the same time I do consider a
510 module written for Linux and using kernel infrastructures to get its work
511 done, even if not actually copying any existing Linux code, to be a
512 derived work by default. You'd have to have a strong case to _not_
513 consider your code a derived work..
517 > This issue is related to issue #1. Exactly what is covered by the
518 > exception? For example, all code shipped with the Linux kernel
519 > archive and typically installed under /usr/src/linux, all code under
520 > /usr/src/linux except /usr/src/linux/drivers, or just the code in
521 > the /usr/src/linux/kernel directory?
523 See above, and I think you'll see my point.
525 The "user program" exception is not an exception at all, for example, it's
526 just a more clearly stated limitation on the "derived work" issue. If you
527 use standard UNIX system calls (with accepted Linux extensions), your
528 program obviously doesn't "derive" from the kernel itself.
530 Whenever you link into the kernel, either directly or through a module,
531 the case is just a _lot_ more muddy. But as stated, by default it's
532 obviously derived - the very fact that you _need_ to do something as
533 fundamental as linking against the kernel very much argues that your
534 module is not a stand-alone thing, regardless of where the module source
535 code itself has come from.
539 > This last issue is not so much a issue for the Linux kernel
540 > exception, but a request for comment.
542 > Richard and I both agree that a "plug-in" and a "dynamically
543 > loaded kernel module" are effectively the same under the GPL.
547 The Linux kernel modules had (a long time ago), a more limited interface,
548 and not very many functions were actually exported. So five or six years
549 ago, we could believably claim that "if you only use these N interfaces
550 that are exported from the standard kernel, you've kind of implicitly
551 proven that you do not need the kernel infrastructure".
553 That was never really documented either (more of a guideline for me and
554 others when we looked at the "derived work" issue), and as modules were
555 more-and-more used not for external stuff, but just for dynamic loading of
556 standard linux modules that were distributed as part of the kernel anyway,
557 the "limited interfaces" argument is no longer a very good guideline for
560 So these days, we export many internal interfaces, not because we don't
561 think that they would "taint" the linker, but simply because it's useful
562 to do dynamic run-time loading of modules even with standard kernel
563 modules that _are_ supposed to know a lot about kernel internals, and are
564 obviously "derived works"..
566 > However we disagree that a plug-in for a GPL'd program falls
567 > under the GPL as asserted in the GPL FAQ found in the answer:
568 > http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins.
570 I think you really just disagree on what is derived, and what is not.
571 Richard is very extreme: _anything_ that links is derived, regardless of
572 what the arguments against it are. I'm less extreme, and I bet you're even
573 less so (at least you would like to argue so for your company).
575 > My assertion is that plug-ins are written to an interface, not a
576 > program. Since interfaces are not GPL'd, a plug-in cannot be GPL'd
577 > until the plug-in and program are placed together and run. That is
578 > done by the end user, not the plug-in creator.
580 I agree, but also disrespectfully disagree ;)
582 It's an issue of what a "plug-in" is - is it a way for the program to
583 internally load more modules as it needs them, or is it _meant_ to be a
584 public, published interface.
586 For example, the "system call" interface could be considered a "plug-in
587 interface", and running a user mode program under Linux could easily be
588 construed as running a "plug-in" for the Linux kernel. No?
590 And there, I obviously absolutely agree with you 100%: the interface is
591 published, and it's _meant_ for external and independent users. It's an
592 interface that we go to great lengths to preserve as well as we can, and
593 it's an interface that is designed to be independent of kernel versions.
595 But maybe somebody wrote his program with the intention to dynamically
596 load "actors" as they were needed, as a way to maintain a good modularity,
597 and to try to keep the problem spaces well-defined. In that case, the
598 "plug-in" may technically follow all the same rules as the system call
599 interface, even though the author doesn't intend it that way.
601 So I think it's to a large degree a matter of intent, but it could
602 arguably also be considered a matter of stability and documentation (ie
603 "require recompilation of the plug-in between version changes" would tend
604 to imply that it's an internal interface, while "documented binary
605 compatibility across many releases" implies a more stable external
606 interface, and less of a derived work)
608 Does that make sense to you?
610 > I asked Richard to comment on several scenarios involving plug-ins
611 > explain whether or not they were in violation of the GPL. So far he
612 > as only addressed one and has effectively admitted a hole. This is
613 > the one I asked that he's responded to:
614 > [A] non-GPL'd plug-in writer writes a plug-in for a non-GPL'd
615 > program. Another author writes a GPL'd program making the
616 > first author's plug-ins compatible with his program. Are now
617 > the plug-in author's plug-ins now retroactively required to be
621 > No, because the plug-in was not written to extend this program.
623 > I find it suspicious that whether or not the GPL would apply to the
624 > plug-in depends on the mindset of the author.
626 The above makes no sense if you think of it as a "plug in" issue, but it
627 makes sense if you think of it as a "derived work" issue, along with
628 taking "intent" into account.
630 I know lawyers tend to not like the notion of "intent", because it brings
631 in another whole range of gray areas, but it's obviously a legal reality.
633 Ok, enough blathering from me. I'd just like to finish off with a few
634 comments, just to clarify my personal stand:
636 - I'm obviously not the only copyright holder of Linux, and I did so on
637 purpose for several reasons. One reason is just because I hate the
638 paperwork and other cr*p that goes along with copyright assignments.
640 Another is that I don't much like copyright assignments at all: the
641 author is the author, and he may be bound by my requirement for GPL,
642 but that doesn't mean that he should give his copyright to me.
644 A third reason, and the most relevant reason here, is that I want
645 people to _know_ that I cannot control the sources. I can write you a
646 note to say that "for use XXX, I do not consider module YYY to be a
647 derived work of my kernel", but that would not really matter that much.
648 Any other Linux copyright holder might still sue you.
650 This third reason is what makes people who otherwise might not trust me
651 realize that I cannot screw people over. I am bound by the same
652 agreement that I require of everybody else, and the only special status
653 I really have is a totally non-legal issue: people trust me.
655 (Yes, I realize that I probably would end up having more legal status
656 than most, even apart from the fact that I still am the largest single
657 copyright holder, if only because of appearances)
659 - I don't really care about copyright law itself. What I care about is my
660 own morals. Whether I'd ever sue somebody or not (and quite frankly,
661 it's the last thing I ever want to do - if I never end up talking to
662 lawyers in a professional context, I'll be perfectly happy. No
663 disrespect intended) will be entirely up to whether I consider what
664 people do to me "moral" or not. Which is why intent matters to me a
665 lot - both the intent of the person/corporation doign the infringement,
666 _and_ the intent of me and others in issues like the module export
669 Another way of putting this: I don't care about "legal loopholes" and
672 - Finally: I don't trust the FSF. I like the GPL a lot - although not
673 necessarily as a legal piece of paper, but more as an intent. Which
674 explains why, if you've looked at the Linux COPYING file, you may have
675 noticed the explicit comment about "only _this_ particular version of
676 the GPL covers the kernel by default".
678 That's because I agree with the GPL as-is, but I do not agree with the
679 FSF on many other matters. I don't like software patents much, for
680 example, but I do not want the code I write to be used as a weapon
681 against companies that have them. The FSF has long been discussing and
682 is drafting the "next generation" GPL, and they generally suggest that
683 people using the GPL should say "v2 or at your choice any later
686 Linux doesn't do that. The Linux kernel is v2 ONLY, apart from a few
687 files where the author put in the FSF extension (and see above about
688 copyright assignments why I would never remove such an extension).
690 The "v2 only" issue might change some day, but only after all documented
691 copyright holders agree on it, and only after we've seen what the FSF
692 suggests. From what I've seen so far from the FSF drafts, we're not likely
693 to change our v2-only stance, but there might of course be legal reasons
694 why we'd have to do something like it (ie somebody challenging the GPLv2
695 in court, and part of it to be found unenforceable or similar would
696 obviously mean that we'd have to reconsider the license).
700 PS. Historically, binary-only modules have not worked well under Linux,
701 quite regardless of any copyright issues. The kernel just develops too
702 quickly for binary modules to work well, and nobody really supports them.
703 Companies like Red Hat etc tend to refuse to have anything to do with
704 binary modules, because if something goes wrong there is nothing they can
705 do about it. So I just wanted to let you know that the _legal_ issue is
706 just the beginning. Even though you probably don't personally care ;)