Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312031533530.2055@home.osdl.org>
Date: Thu, 4 Dec 2003 00:03:11 GMT
Message-ID: <fa.j5s4qd8.1ei8k8u@ifi.uio.no>

On Wed, 3 Dec 2003, Kendall Bennett wrote:
>
> I have heard many people reference the fact that the although the Linux
> Kernel is under the GNU GPL license, that the code is licensed with an
> exception clause that says binary loadable modules do not have to be
> under the GPL.

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard
system call interfaces aren't considered derived works, but even that
isn't an "exception" - it's just a statement of a border of what is
clearly considered a "derived work". User programs are _clearly_ not
derived works of the kernel, and as such whatever the kernel license is
just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same.
The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that
leads to any gray areas. There are areas that are not gray at all: user
space is clearly not a derived work, while kernel patches clearly _are_
derived works.

But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.

Basically:
 - anything that was written with Linux in mind (whether it then _also_
   works on other operating systems or not) is clearly partially a derived
   work.
 - anything that has knowledge of and plays with fundamental internal
   Linux behaviour is clearly a derived work. If you need to muck around
   with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem
module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to what other UNIXes did? Personally, I didn't feel that I could make that
judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
area.

Personally, I think that case wasn't a derived work, and I was willing to
tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work?
HELL NO! It has nothing to do with modules per se, except that non-modules
clearly are derived works (if they are so central to the kernel that you
can't load them as a module, they are clearly derived works just by virtue
of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just
one sign that _maybe_ it might have other arguments for why it isn't
derived.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312031614000.2055@home.osdl.org>
Date: Thu, 4 Dec 2003 00:24:47 GMT
Message-ID: <fa.j3c0pt9.1c28kop@ifi.uio.no>

On Wed, 3 Dec 2003, Linus Torvalds wrote:
>
> So being a module is not a sign of not being a derived work. It's just
> one sign that _maybe_ it might have other arguments for why it isn't
> derived.

Side note: historically, the Linux kernel module interfaces were really
quite weak, and only exported a few tens of entry-points, and really
mostly effectively only allowed character and block device drivers with
standard interfaces, and loadable filesystems.

So historically, the fact that you could load a module using nothing but
these standard interfaces tended to be a much stronger argument for not
being very tightly coupled with the kernel.

That has changed, and the kernel module interfaces we have today are MUCH
more extensive than they were back in '95 or so. These days modules are
used for pretty much everything, including stuff that is very much
"internal kernel" stuff and as a result the kind of historic "implied
barrier" part of modules really has weakened, and as a result there is not
avery strong argument for being an independent work from just the fact
that you're a module.

Similarly, historically there was a much stronger argument for things like
AFS and some of the binary drivers (long forgotten now) for having been
developed totally independently of Linux: they literally were developed
before Linux even existed, by people who had zero knowledge of Linux. That
tends to strengthen the argument that they clearly aren't derived.

In contrast, these days it would be hard to argue that a new driver or
filesystem was developed without any thought of Linux. I think the NVidia
people can probably reasonably honestly say that the code they ported had
_no_ Linux origin. But quite frankly, I'd be less inclined to believe that
for some other projects out there..

			Linus

Newsgroups: fa.linux.kernel
From: viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <20031204192452.GC10421@parcelfarce.linux.theplanet.co.uk>
Date: Thu, 4 Dec 2003 19:26:12 GMT
Message-ID: <fa.n2spa2m.1h1mpj2@ifi.uio.no>

On Wed, Dec 03, 2003 at 04:23:33PM -0800, Linus Torvalds wrote:

> Side note: historically, the Linux kernel module interfaces were really
> quite weak, and only exported a few tens of entry-points, and really
> mostly effectively only allowed character and block device drivers with
> standard interfaces, and loadable filesystems.
>
> So historically, the fact that you could load a module using nothing but
> these standard interfaces tended to be a much stronger argument for not
> being very tightly coupled with the kernel.
>
> That has changed, and the kernel module interfaces we have today are MUCH
> more extensive than they were back in '95 or so. These days modules are
> used for pretty much everything, including stuff that is very much
> "internal kernel" stuff and as a result the kind of historic "implied
> barrier" part of modules really has weakened, and as a result there is not
> avery strong argument for being an independent work from just the fact
> that you're a module.

	FWIW, it would be very nice if somebody did hard and messy work and
produced lists of in-tree modules using given symbols.  Ideally - automated
that, but that won't be easy to do (quite a few are used only via inlined
wrappers and in some cases - under an ifdef; many arch-specific exports
are of that sort).

	Aside of "hey, nothing uses that at all" and "only core uses it"
we'd get a bunch of "hmm, we really should've exported higher-level function
instead" and "WTF does that lone driver use this function?".  I'd played
with that for fs/* exports and so far results look interesting.  I'm using
grep, but that's pretty much hopeless - we have literally thousands of
exported symbols and any manual approach will break on that.

	Some approximation might be obtained by building all modules and
doing nm on them, with manual work for non-obvious cases.  I've done that
on x86 (allmodconf + enabling whatever could be enabled, even if broken).
Statistics is interesting, to put it mildly.

	First of all, there are ~3600 symbols used by some in-tree drivers.
~600 of them are have 10 users or more.  ~2000 have only one or two users.
And we have ~7500 EXPORT_... in the tree.  Now, that number is inflated by
duplicates between architectures (and other stats are deflated by incomplete
coverage).  And yes, there are things that have every reason to be exported,
but only a few modules care to use them.

	However, it certainly looks like a large fraction of export list
should go away.  Moreover, we probably should introduce
EXPORT_FOR(symbol, module list)
and use it for stuff like jbd poking very deep in buffer.c guts - deeper
than anybody else.  Ditto for ipv6 / ipv4 interaction - they really have
a special relationship and it makes no sense whatsoever to treat everything
in TCPv4 guts that happens to be shared with TCPv6 as public export.  There's
a lot of cases like that and I suspect that they cover ~50-60% of the in-tree
imports.

	Real interface is somewhere around 400-500 symbols and it can be
split into several more or less compact parts.  Having more than an order
of magnitude more than that, and having it as a big pile...  Not a good
thing(tm), IMO.

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312040753550.2055@home.osdl.org>
Date: Thu, 4 Dec 2003 15:59:35 GMT
Message-ID: <fa.j5ccqt9.1e20lop@ifi.uio.no>

On Thu, 4 Dec 2003, Jason Kingsland wrote:
> >  - anything that has knowledge of and plays with fundamental internal
> >    Linux behaviour is clearly a derived work. If you need to muck around
> >    with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?

It is really just documentation.

This is exactly so that it is more clear which cases are black-and-white,
and where people shouldn't even have to think about it for a single
second. It still doesn't make the gray area go away, but it limits it a
bit ("if you need this export, you're clearly doing something that
requires the GPL").

Note: since the kernel itself is under the GPL, clearly anybody can modify
the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
against the license per se. But it doesn't make a module that needs that
symbol any less needful of the GPL - exactly because the thing is just a
big cluehint rather than anything else.

			Linus

Newsgroups: fa.linux.kernel
From: "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <20031206153845.GA8552@thunk.org>
Date: Sat, 6 Dec 2003 15:41:03 GMT
Message-ID: <fa.e6sdcpa.g6e0ie@ifi.uio.no>

On Fri, Dec 05, 2003 at 09:14:33PM -0800, Larry McVoy wrote:
> Your view that "(b) is compiled into a Linux kernel module, then it
> _is_ part of (a+b) whether (a) is physically present or not." is not
> something that I have managed to seen in any caselaw.  On the other hand,
> it is widely held that you can't force licenses across an API and it's
> perfectly reasonable to see the loadable module interface as an API.

Well, whether or not you can force licenses across an API is not well
settled, as far as I know (IANAL) Microsoft and Apple still have
licenses that try to claim ownership across API's.  And to the extent
that the FSF still tries to claim that programs written to use the GNU
readline library must fall under the GPL, when two other BSD-licensed
implementations of the readline interface exist, they are claiming
exactly the same thing (although the FSF has been known to call for
boycotts of companies that try to claim interfacde copyrights; heh).

Which brings up an interesting point.  The moment someone implements
BSD-licensed code which implements a particular interface, it very
strongly weakens the case that anyone implementing code to that
interface is a derived work of the GPL'ed interface.  This is one of
the reasons why claiming that the GPL can infect across an interface
(whether it is a module interface, a system call interface, or
dynamically linked shared library interface) is bizarre at best.

For example, let me give the following example.  Debugfs of the
e2fsprogs library uses libss, which I recently enhanced to attempt to
dynamically load one of the following libraries via dlopen: readline
(GPL'ed), editline (BSD licensed), or libedit (BSD licensed), which
all export the same interface.  Libss dates back to 1985 or so, and
has a BSD-style license.  It is also used in Kerberos V5 (which is
also BSD licensed), and so Solaris has a proprietary derived version of
Krb5 whose administration client uses libss.  So if you compile the
latest version of e2fsprogs on Solaris, and Solaris' krb5 admin client
manages to use the new version of libss, then you could potentially
have in the single address space:

	* Solaris's proprietary admin client
	* The libss shared library (BSD)
	* The GPL'ed readline library

OK, riddle me this: is there a GPL violation, and if so, who committed
it?  The user, for running the admin client in this configuration?
But the GPL explicitly says that it's only about distribution, and
doesn't restrict usage in any way, and the end-user is only using the
code.

Solaris, the owner of the proprietary admin client?  But they weren't
involved in my enhancing the libss shared library to dynamically load
either a GPL'ed or a BSD-licensed library, and they created the admin
client before I added the libss enhancement.  And heck, the original
admin client was created by me while I was working at MIT, and is part
of the original MIT Kerberos V5 disitribution (although Sun has
modified it extensively since then).

Me, for modifying a BSD-licensed library to try to dynamically load a
GPL'ed library?  But I was trying to make a perfectly legitimate stack
work:

	* Debugfs (which is GPL'ed)
	* The libss shared library (BSD)
	* The GPL'ed readline library

and the reason why I used dynamic linking was because I wanted debugfs
to only optionally depend on readline library, since the readline
library is a monster (over 600k) and so it wouldn't fit on a rescue
floppy.

So trust me, you really don't want to claim that just because a
program was written to use a particular interface, the license infects
across the API.  Apple and Microsoft are playing that game, and a very
unsavory game it is.  And it leads to all sorts of paradoxes, such as
the one I described above.

						- Ted

Newsgroups: fa.linux.kernel
From: "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <20031206211900.GA9034@thunk.org>
Date: Sat, 6 Dec 2003 21:21:45 GMT
Message-ID: <fa.e6btb19.gme1a9@ifi.uio.no>

On Sat, Dec 06, 2003 at 09:50:41AM -0800, Larry McVoy wrote:
> The sticky one is the one where we started, kernel modules.  Linus is
> saying that kernel modules are covered by the GPL because they are
> combined with the kernel.  I think his reasoning is weak and unlikely
> to be upheld by the courts.  If we remove the issue of inline functions
> for a moment then we are talking about pure API's and there is no way
> that the courts are going to uphold that a copyright license can cross a
> pure API (famous last words).  Well, no way if both sides of the dispute
> have equally good lawyers, without that who knows.

I had a law professor from the MIT Sloan School of Technology, who
when I posed the question informally, said that the FSF would be
laughed out of court if they tried to claim that the GPL infected
across API's.  But Larry's right, in the U.S. at least, you get the
best justice money can buy, and with enough high-paid lawyers and
lobbyist, you can probably pervert the system any way you like ---
witness the RIAA and DMCA.

But that aside, does the Open Source community really want to push for
the legal principle that just because you write an independent program
which uses a particular API, the license infects across the interface?
That's essentially interface copyrights, and if say the FSF were to
file an amicus curiae brief support that particular legal principle in
an kernel modules case, it's worthwhile to think about how Microsoft
and Apple could use that case law to f*ck us over very badly.

It would mean that we would not be able to use Microsoft DLL's in
programs like xine.  It would mean that programs like Crossover office
wouldn't work.  It would mean that Apple could legally prohibit people
from writing enhancements to MacOS (for example, how do all of the
various extensions in Mac OS 9 work?  They link into the operating
system and modify its behaviour.  If they are therefore a derived work
of MacOS, then Apple could screw over all of the people who write
system extensions of MacOS.)

Be careful of what you wish for, before you get it.  The ramifications
of the statement that just because a device driver is written for
Linux, that it is presumptively a derived work of Linux unless proven
otherwise, is amazingly scary.  Fortunately, we can hope that the law
professor I talked to was right, and that such a claim would be
laughed out of court.  But if it isn't, look to Microsoft and other
unsavory companies to use that kind of case law to completely screw us
to the wall.....

						- Ted

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312041743530.6638@home.osdl.org>
Date: Fri, 5 Dec 2003 01:48:52 GMT
Message-ID: <fa.j7skq5c.1ci0k0k@ifi.uio.no>

On Thu, 4 Dec 2003, Paul Adams wrote:
>
> A work that is inspired by Linux is no more a derivative work than
> a programmatic musical composition inspired by a novel.  Having
> Linux in mind cannot be enough to constitute infringement.

But it does - you have to include the Linux header files in order to be
able to make any nontrivial module.

I'm not claiming that "thinking about Linux makes you tainted". It's not
about inspiration. But it's a bit like getting somebody pregnant: you have
to do a lot more than just think about it to actually make it happen, or
every high school in the world would be crawling with babies.

In other words: feel free to be inspired by Linux all you want. But if you
release a binary module that loads and works, you've been doing more than
just feeling inspired. And then you need to be _careful_.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312050853200.9125@home.osdl.org>
Date: Fri, 5 Dec 2003 17:22:23 GMT
Message-ID: <fa.j7c6q5a.182mk0o@ifi.uio.no>

On Fri, 5 Dec 2003, Peter Chubb wrote:
>
> As I understand it, SCO is/was claiming that JFS and XFS are derived
> works of the UNIX source base, because they were developed to match
> the internal interfaces of UNIX, and with knowledge of the internals
> of UNIX -- and they hold the copyrights of and are the licensor of UNIX.

Yes, and I'm not claiming anything like that.

I claim that a "binary linux kernel module" is a derived work of the
kernel, and thus has to come with sources.

But if you use those same sources (and _you_ wrote them) they do not
contain any Linux code, they are _clearly_ not derived from Linux, and you
can license and use your own code any way you want.

You just can't make a binary module for Linux, and claim that that module
isn't derived from the kernel. Because it generally is - the binary
module not only included header files, but more importantly it clearly is
_not_ a standalone work any more. So even if you made your own prototypes
and tried hard to avoid kernel headers, it would _still_ be connected and
dependent on the kernel.

And note that I'm very much talking about just the _binary_. Your source
code is still very much yours, and you have the right to distribute it
separately any which way you want. You wrote it, you own the copyrights to
it, and it is an independent work.

But when you distribute it in a way that is CLEARLY tied to the GPL'd
kernel (and a binary module is just one such clear tie - a "patch" to
build it or otherwise tie it to the kernel is also such a tie, even if you
distribute it as source under some other license), you're BY DEFINITION
not an independent work any more.

(But exactly because I'm not a black-and-white person, I reserve the right
to make a balanced decision on any particular case. I have several times
felt that the module author had a perfectly valid argument for why the
"default assumption" of being derived wasn't the case. That's why things
like the AFS module were accepted - but not liked - in the first place).

This is why SCO's arguments are specious. IBM wrote their code, retained
their copyrights to their code AND THEY SEVERED THE CONNECTION TO SCO'S
CODE (and, arguably the connections didn't even exist in the first place,
since apparently things like JFS were written for OS/2 as well, and the
Linux port was based on that one - but that's a separate argument and
independent of my point).

See the definition of "derivative" in USC 17.1.101:

	A "derivative work" is a work based upon one or more preexisting
	works, such as a translation, musical arrangement, dramatization,
	fictionalization, motion picture version, sound recording, art
	reproduction, abridgment, condensation, or any other form in which
	a work may be recast, transformed, or adapted. A work consisting
	of editorial revisions, annotations, elaborations, or other
	modifications which, as a whole, represent an original work of
	authorship, is a "derivative work".

And a binary module is an "elaboration" on the kernel. Sorry, but that is
how it IS.

In short: your code is yours. The code you write is automatically
copyrighted by YOU, and as such you have the right to license and use it
any way you want (well, modulo _other_ laws, of course - in the US your
license can't be racist, for example, but that has nothing to do with
copyright laws, and would fall under a totally different legal framework).

But when you use that code to create an "elaboration" to the kernel, that
makes it a derived work, and you cannot distribute it except as laid out
by the GPL. A binary module is one such case, but even just a source patch
is _also_ one such case. The lines you added are yours, but when you
distribute it as an elaboration, you are bound by the restriction on
derivative works.

Or you had better have some other strong argument why it isn't. Which has
been my point all along.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312050921500.9125@home.osdl.org>
Date: Fri, 5 Dec 2003 17:36:47 GMT
Message-ID: <fa.j8s8pd8.1bikloq@ifi.uio.no>

On Fri, 5 Dec 2003, Shawn Willden wrote:
>
> So copies to disk and RAM that are "an essential step in the utilization of
> the computer program" are non-infringing.

Absolutely. But you don't have the right to distribute them.

Put another way: nVidia by _law_ has the right to do whatever essential
step they need to be able to run Linux on their machines. That's what the
exception to copyright law requires for any piece of software.

And in fact you should be damn happy for that exception, because that
exception is also what makes things like emulators legal - software houses
can't claim that you can't use an emulator to run their programs (well,
they may _try_, but I don't know if it ever gets to court).

But what they do NOT have the right to do is to create derivative works of
the kernel, and distribute them to others. That act of distribution is not
essential _for_them_ to utilize the kernel program (while the act of
_receiving_ the module and using it may be - so the recipient may well be
in the clear).

So in order for nVidia to be able to legally distribute a binary-only
kernel module, they have to be able to feel damn sure that they can
explain (in a court of law, if necessary) that the module isn't a derived
work. Enough to convince a judge. That's really all that matters. Our
blathering matters not at all.

Now, personally, I have my own judgment on what "derivative works" are,
and I use that judgement to decide if I'd complain or take the matter
further.

And so _I_ personally think some binary modules are ok, and you've heard
my arguments as to why. That means that _I_ won't sue over such uses,
since in my opinion there is no copyright infringement IN THOSE CASES due
to me not considering them derivative.

My opinions are fairly public, and the stuff I say in public actually does
have legal weight in that it limits what I can do (if I say in public that
I think something is ok, I have a much harder time then making the
argument that it _isn't_ ok in front of a judge - this is what the
"estoppel" thing is all about).

But the thing is, my public opinions don't bind anybody else. So if Alan
Cox, or _any_ other kernel copyright holder, disagrees with me (and trust
me, people do), they have the right to complain on their own. Their case
would be weakened by my stance (simply because a defendant could point to
my opinions and the judge might be swayed by that).

And quite frankly, my largest reason for not complaining loudly has often
been that I'm lazy, and in several cases of sme people using GPL'd work
improperly I have been ready to join a lawsuit that somebody else
initiates. So far people have tended to back down.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: RE: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312051122190.9125@home.osdl.org>
Date: Fri, 5 Dec 2003 19:28:12 GMT
Message-ID: <fa.j7capd9.192mlop@ifi.uio.no>

On Fri, 5 Dec 2003, Kendall Bennett wrote:
>
> Right, and by extension of the same argument you cannot use kernel
> headers to create non-GPL'ed binaries that run IN USER SPACE!

This was indeed one of the worries that people had a long time ago, and is
one (but only one) of the reasons for the addition of the clarification to
the COPYING file for the kernel.

So I agree with you from a technical standpoint, and I claim that the
clarification in COPYING about user space usage through normal system
calls covers that special case.

But at the same time I do want to say that I discourage use of the kernel
header files for user programs for _other_ reasons (ie for the last 8
years or so, the suggestion has been to have a separate copy of the header
files for the user space library). But that's due to technical issues
(since I think the language of the COPYING file takes care of all
copyright issues): trying to avoid version dependencies.

> This exact reasoning is what RedHat (aka Cygnus) has been using for years
> with the Cygwin toolkit for Windows. Although 99% of the code built with
> the GNU compilers and Cygwin includes the glibc runtime library that is
> LGPL, every program *must* include the C runtime library startup code or
> it cannot function. *That* code is pure GPL, and by extension any program
> using the Cygwin libraries is a derived work and must be GPL. If you
> don't like that, by a commercially licensed version of Cygwin from
> RedHat/Cygnus instead.

And this is an area where I think the GPL just isn't the right license to
use - but on the other hand it obviously isn't my decision to make. I'm
not touching Cygwin with a ten-foot pole, and that has nothing to do with
licensing ;)

The GPL just doesn't make a lot of sense for library-like infrastructure.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312100809150.29676@home.osdl.org>
Date: Wed, 10 Dec 2003 16:24:30 GMT
Message-ID: <fa.iegrgjm.1h0m9i2@ifi.uio.no>

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> > kernel was compiled with certain options etc - then it pretty clearly is
> > very tightly integrated.
>
> So what?  Plugins have a nasty tendency to have to be updated when the
> main program is updated.

Sorry, but again, I repeat: technicalities don't actually matter much to a
judge.

There's a fundamental difference between "plugins" and "kernel modules":
intent.

If you write a program that tries to have a stable API to outside modules,
and you make and document a plugin interface that is documented to accept
proprietary modules, then that is an ABI. And linking against such a thing
is fine.

But when you have the GPL, and you have documented for years and years
that it is NOT a stable API, and that it is NOT a boundary for the license
and that you do NOT get an automatic waiver when you compile against this
boundary, then things are different.

And they are different even if from a _technical_ standpoint you do
exactly the same: you dynamically link against a binary.

Ask a lawyer. Really.

I know people on this list are engineers and programmers, and you think
that technology is all that matters, and that if you link in one situation
and do exactly the same motions ("walk around the computer three times
widdershins, and give the -dynamic option to 'ld'") then you are doing the
same thing.

But that's not how "the real world" works. In the real world, intent and
permission matter a whole lot. When you make love to your wife in the
privacy of your own home, the "real world" is perfectly ok with that. When
you do the same thing to somebody you didn't get permission from, it's a
major crime and you can be put into prison for decades - even though
technically the movements are pretty much the same.

See? Intent matters. How you do something _technically_ does not.

In fact, I will bet you that if the judge thinks that you tried to use
technicalities ("your honour, I didn't actually run the 'ln' program,
instead of wrote a shell script for the _user_ to run the 'ln' program for
me"), that judge will just see that as admission of the fact that you
_knew_ you were doing something bad. Which means that now it wasn't just
unintentional copyright infringement, now it is clearly wilful.

So those technicalities you might use to try to make things better
actually can make them WORSE.

The best you can do is to just ask for permission. Maybe you'll get it.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312100944190.29676@home.osdl.org>
Date: Wed, 10 Dec 2003 18:00:38 GMT
Message-ID: <fa.ieh5hjh.1h0c8if@ifi.uio.no>

On Wed, 10 Dec 2003, Chris Friesen wrote:
>
> Linus Torvalds wrote:
>
> > But also note how it's only the BINARY MODULE that is a derived work. Your
> > source code is _not_ necessarily a derived work, and if you compile it for
> > another operating system, I'd clearly not complain.
> >
> > This is the "stand-alone short story" vs "extra chapter without meaning
> > outside the book" argument. See? One is a work in its own right, the other
> > isn't.
>
> We currently have a situation where an external company supplies us with
> a device driver containing a binary blob that was explicitly written as
> OS-agnostic, and a shim that is gpl'd (at least the linux shim is) to
> get the appropriate os-specific services.  I guess this would fall under
> the "not made just for linux" category in which you've placed the Nvidia
> driver?
>
> Carrying on your analogy, this could be a generic love scene, with
> blanks in which to insert the character's names and location.

Yes. Depending on how it is done (ie is the support for other operating
systems really a major thing that you really care about, and not intended
just as a smoke-screen), I personally believe that this is likely a valid
way to show that some part of the code (the binary blob) is not a derived
work. Clearly it no longer depends on the kernel, and you can show that to
be true by the obvious argument.

And I think this argument is _especially_ strong for things like firmware
etc, and I've been on record as saying that I think it's ok to upload
standard firmware for a driver as long as you don't call it directly (ie
it really lives on the hardware itself).

(At this point I should probably point out that other people disagree, and
there are people who feel strongly that the kernel cannot contain binary
firmware. Whish is obviously part of the reason for having the firmware
loader interfaces for drivers - adding an extra layer of separation).

However, even that doesn't necessarily make the issue 100% clear. It
clarifies the status of the binary blob itself - but arguably the _other_
part of the story (eg the shim layer) is not a whole work, and it could be
argued that that part in itself violates the GPL.

At that point I just say "I'm personally a reasonable person, and quite
frankly, personally the _last_ thing I'd want to do is to complain in a
court of law".

Quite frankly, you'd have to really really try to actively irritate me
with some flagrant crap for me to decide that it's time to try to enforce
anything. But I'm only speaking for myself here, and there are other
copyright holders that might be more trigger-happy.

So while I may be arguing vehemently here against binary-only modules,
please realize that I haven't sued anybody over them, and in fact I'm a
big believer in trying to make sure everybody is pretty happy and not make
a big deal out of things.

Sometimes that "everybody is happy" means that I literally tell people
that they might want to use a *BSD kernel instead of Linux, if I don't see
them being able to make themselves _and_ the GPL people happy otherwise.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312101108150.29676@home.osdl.org>
Date: Wed, 10 Dec 2003 19:17:17 GMT
Message-ID: <fa.if0dgjl.1hg49i3@ifi.uio.no>

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> I can understand your touchiness, it's not much fun living through tons of
> messages where people try and figure out how to circumvent your license.

That's not really the issue.

I'd like to make it clear that I'm actually much softer on this than many
other people - I've been making it clear that I think that binary-only
modules _are_ ok, but that the burden of proof of ok'ness is squarely on
the shoulders of the company that makes them.

So please do get that part clear: I'm pretty well-known for allowing
binary-only modules in things like AFS and nVidia, where some people think
they shouldn't be allowed.

But the real issue here (and in the subject line in this whole discussion)
is about an "exception clause".

There is none. And I'm just saying that there is NO WAY that a binary-only
module is "automatically in the clear". They _may_ be, but it's on the
basis of something totally different than just "it's a module".

This is why I want to make it so clear that "moduleness" (which is not a
word, but should be one) is not the thing that matters. There's still a
strong "linkage" to a particular kernel in a binary module, and the act of
running the linker is not what determines whether a work is a derived
work.

In short, you should not see my arguments as a way of saying "all modules
are derived works". I'm clearly not saying that, since I _do_ allow binary
only modules and I don't claim they infringe.

So I'm not arguing for a very wide notion of derived works: I'm arguing
AGAINST the narrow notion that a module would somehow automatically _not_
be derived.

This is why I've said at least fifty times that a kernel module is to be
considered "derived by default". The non-derivedness comes from things
that have nothing to do with whether it is a module.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: RE: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312100923370.29676@home.osdl.org>
Date: Wed, 10 Dec 2003 17:45:03 GMT
Message-ID: <fa.ifh1h3g.1g0g928@ifi.uio.no>

On Wed, 10 Dec 2003, Hua Zhong wrote:
>
> > What has meaning for "derived work" is whether it stands on its own or
> > not, and how tightly integrated it is. If something works
> > with just one particular version of the kernel - or depends on things like
> > whether the kernel was compiled with certain options etc - then it pretty
> > clearly is very tightly integrated.
>
> Many userspace programs fall into this category too.

Absolutely.

Trust me, REAL LAWYERS WERE WORRIED about this. It wasn't just random tech
people discussing issues on a technical (or, right now, not-so-technical)
mailing list.

There's a reason for those lines at the top of the COPYING file saying
that user space is not covered, and there are literally lawyers who say it
would hold up in a court of law.

Exactly because you _can_ argue that user-space might be covered. It's an
argument that almost certainly would fail very quickly due to "documented
interfaces" and ABI issues, but it is an argument that lawyers have made,
and it's that argument that makes the disclaimer in COPYING be worth it.

In other words: even without that disclaimer of derivation, user space
would almost certainly (with a very high probability indeed) be safe from
a copyright infringement suit. Such a suit would most likely be thrown out
very early, exactly because the UNIX system call interface is clearly
extensively documented, and the Linux implementation of it has strived to
be a stable ABI for a long time.

In fact, a user program written in 1991 is actually still likely to run,
if it doesn't do a lot of special things. So user programs really are a
hell of a lot more insulated than kernel modules, which have been known to
break weekly.

Similarly, things like /proc etc are clearly intended to be ways to
interface to the kernel in user space, so there's a clear intent there
that nobody can reasonably deny (again, that intent is made _clearer_ by
the COPYING disclaimer, but it would be hard to argue against even in the
absense of that).

But even DESPITE these strong arguments that user-space clearly isn't a
derived work, and real lawyers worried, and felt much happier with the
explicit disclaimer in the COPYING file.

That should tell you something. In particular, it should tell you to be
careful: some courts have made so broad "derivative work" judgements that
it's scary - think about the "Gone With the Wind" parody (I think the
ruling was eventually overturned on First Amendment grounds, but the
point is that you should be very careful, and while source code has
the potential for First Amendment protection, binary modules sure as hell
do not).

And please note that I am _not_ arguing for those overly broad judgements:
I'm just pointing out that you should not assume that "derivative" is
something simple. If an author claims your work is derivative, you should
step very very lightly.

And I claim that binary-only kernel modules ARE derivative "by default",
by virtue of having no meaning without the kernel.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: RE: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312101452300.1273@home.osdl.org>
Date: Wed, 10 Dec 2003 23:14:03 GMT
Message-ID: <fa.j4c0rl2.1c28l0q@ifi.uio.no>

On Wed, 10 Dec 2003, Andre Hedrick wrote:
>
> How can the additional words alter the mean of GPL itself?

They can't.

But they _can_ alter your ability to sue. In particular, if you publicly
state that you will not sue anybody over something, they can now use that
statement to make future plans. If at a later date you decide to sue them
anyway, they can point the judge at your earlier statement, and claim
estoppel against you.

So note how the license itself didn't change - but your ability to
_enforce_ the license has changed by virtue of you stating that you won't.

So while I publicly say that I'm a lazy bastard, and the less I have to
do with lawyers, the better - I won't actually say that I will never sue
anybody. I'll say that it is "unlikely", or that people would have to
irritate me mightily.

For most developers that literally doesn't much matter what they say. Even
when _I_ say something, that doesn't really matter to what other
developers do, and while it could potentially limit me from enforcing _my_
copyrights, it doesn't stop others from enforcing theirs. So my random
email ramblings should really be construed as my opinions rather than any
legally relevant stuff.

However, the few extra lines in the main COPYING file end up being
somewhat binding to others, simply because they are _so_ public (they are,
after all, in the _main_ COPYING file) and they have been there pretty
much since the beginning, that they would basically end up being a very
strong argument in any legal case where some random kernel developer would
try to argue that it doesn't cover "their" code.

You don't have to agree to them, btw - you can remove them from the copy
of Linux you distribute, since the GPL in no way requires you to keep
them. They're not part of the copyright license per se, they are expressly
marked as being my personal viewpoint.  I suspect that if you do, you'll
find companies that would be slightly more nervous to work with you,
though.

But nobody has really ever argued against the clause, even originally. And
in this particular discussion, I don't believe anybody is actually arguing
against it now either. The legal meaning of it may be under discussion,
but I don't think anybody is really even _trying_ to argue that it should
be removed and that we should suddenly try to claim that any future user
programs have to be GPL'd.

Quite the reverse - I think everybody involved would argue that that would
just be crazy talk.

			Linus

Newsgroups: fa.linux.kernel
From: viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <20031210231309.GH4176@parcelfarce.linux.theplanet.co.uk>
Date: Wed, 10 Dec 2003 23:14:47 GMT
Message-ID: <fa.ngbkdkm.1mnc3ak@ifi.uio.no>

On Wed, Dec 10, 2003 at 02:36:46PM -0800, Kendall Bennett wrote:

> > In 2.7 we need to get the export list back to sanity.  Right now it's a
> > such a junkpile that speaking about even a relative stability for it...
> > Not funny.
>
> You miss my point. I was talking about a single kernel version. For a
> single kernel version, the ABI is both *published* and *stable*. Sure it
> may not be what you consider a *clean* or *good* ABI, but it *IS* an ABI.

The hell it is.  Change CONFIG_SMP or any number of other options and your
binary compatibility is toast.

> Given that it is a stable and published ABI for a single kernel version,
> then what makes a kernel module different from a user program? The fact

The utter lack of isolation in the former.  And that's a very practical
consideration - amount of efforts needed to tell whether any given bug is
in kernel or in an application is *way* less than for module vs. kernel.
Ditto for potential impact of changes on one side of "interface" upon the
other side.

Realistically there's no way to keep the module "API" fixed without a major
negative impact on kernel development, security and stability.  If somebody
has business model based on the expectation that this "API" will not be
changed whenever we find that useful - too bad, you can't possibly claim
that you had not been warned.

Again, lack of warranties regarding the module "API" is
	* deliberate
	* well-documented
	* older than binary-only modules
	* based on the very sound technical reasons

Live with it.  It's not going to change.

Of course some parts of the "API" are relatively stable; if nothing else,
we have in-tree drivers to consider whenever we make a change and well-behaving
3rd-party module won't take more efforts to update than a typical in-tree
driver.  But that's it - author of such module basically makes an educated
guess regarding the likeliness of change that would leave him in a bad
situation.  Generally, the deeper in kernel guts you play, the easier it
is to get burned.  And current set of exports goes very deep in said guts -
much deeper than it should have.

Anybody who does out-of-tree kernel work must understand the reality.
Modules are different from userland code in the ways that deeply affect
product cycle.  Pretending that there is no fundamental difference and
complaining about that difference signifies only one thing - lack of
basic research on part of complainers.  Don't pretend that you don't know
what you are getting into.

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Thu, 14 Dec 2006 04:17:04 UTC
Message-ID: <fa.uptFenZA61MQbAcOiwjVzIrL8Qc@ifi.uio.no>

On Wed, 13 Dec 2006, Greg KH wrote:
>
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright.  Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.

Btw, I really think this is shortsighted.

It will only result in _exactly_ the crap we were just trying to avoid,
namely stupid "shell game" drivers that don't actually help anything at
all, and move code into user space instead.

What was the point again?

Was the point to alienate people by showing how we're less about the
technology than about licenses?

Was the point to show that we think we can extend our reach past derived
work boundaries by just saying so?

The silly thing is, the people who tend to push most for this are the
exact SAME people who say that the RIAA etc should not be able to tell
people what to do with the music copyrights that they own, and that the
DMCA is bad because it puts technical limits over the rights expressly
granted by copyright law.

Doesn't anybody else see that as being hypocritical?

So it's ok when we do it, but bad when other people do it? Somehow I'm not
surprised, but I still think it's sad how you guys are showing a marked
two-facedness about this.

The fact is, the reason I don't think we should force the issue is very
simple: copyright law is simply _better_off_ when you honor the admittedly
gray issue of "derived work". It's gray. It's not black-and-white. But
being gray is _good_. Putting artificial black-and-white technical
counter-measures is actually bad. It's bad when the RIAA does it, it's bad
when anybody else does it.

If a module arguably isn't a derived work, we simply shouldn't try to say
that its authors have to conform to our worldview.

We should make decisions on TECHNICAL MERIT. And this one is clearly being
pushed on anything but.

I happen to believe that there shouldn't be technical measures that keep
me from watching my DVD or listening to my music on whatever device I damn
well please. Fair use, man. But it should go the other way too: we should
not try to assert _our_ copyright rules on other peoples code that wasn't
derived from ours, or assert _our_ technical measures that keep people
from combining things their way.

If people take our code, they'd better behave according to our rules. But
we shouldn't have to behave according to the RIAA rules just because we
_listen_ to their music. Similarly, nobody should be forced to behave
according to our rules just because they _use_ our system.

There's a big difference between "copy" and "use". It's exatcly the same
issue whether it's music or code. You can't re-distribute other peoples
music (because it's _their_ copyright), but they shouldn't put limits on
how you personally _use_ it (because it's _your_ life).

Same goes for code. Copyright is about _distribution_, not about use. We
shouldn't limit how people use the code.

Oh, well. I realize nobody is likely going to listen to me, and everybody
has their opinion set in stone.

That said, I'm going to suggest that you people talk to your COMPANY
LAWYERS on this, and I'm personally not going to merge that particular
code unless you can convince the people you work for to merge it first.

In other words, you guys know my stance. I'll not fight the combined
opinion of other kernel developers, but I sure as hell won't be the first
to merge this, and I sure as hell won't have _my_ tree be the one that
causes this to happen.

So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
first. This is not something where we use my tree as a way to get it to
other trees. This is something where the push had better come from the
other direction.

Because I think it's stupid. So use somebody else than me to push your
political agendas, please.

		Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 
	2.6.19]
Date: Thu, 14 Dec 2006 15:35:42 UTC
Message-ID: <fa.Vqw9nW91I4zxVAeESUVTj2MI3Pk@ifi.uio.no>

>But I would ask that they honour the licence on the code I release, and
>perhaps more importantly on the code I import from other GPL sources.

It's not a question of "honoring the license"; it's a matter of what
is the reach of the license, as it relates to derivitive works.  It's
a complicated subject, and very dependent on the local law; certainly
in the U.S., when I asked a Law Professor from the MIT Sloan School of
Management, who specialized in IP issues about the FSF theory of GPL
contamination by dynamic linking, after I explained all the details of
how dynamic linking work, she told me that it would be "laughed out of
the courtroom".

Now, is that a legal opinion?  No, because the facts of every single
case are different, and it was an opinion from someone over a decade
ago, and case law may have changed (although as far as I know, there
has been no court ruling directly on this particular point since
then).

The bottom line though is that it is not _nearly_ so clear as some
people would like to believe.  There is a lot of gray --- and that's a
GOOD thing.  If copyright contamination via dynamic linking was the
settled law of the land, then all of the Macintosh extensions that
people wrote --- WHICH WORK BY PATCHING THE OPERATING SYSTEM --- would
be illegal.  And given how much Apple hated people implying that the
UI as handed down from the mountain by the great prophet Steve Jobs
wasn't good enough, would we really have wanted Apple hounding
developers with lawsuits just because "they weren't honoring the
license" by daring to patch MacOS, and extending the OS by linking in
their code?

And what about people who link in a debugger into the Microsoft HAL or
other Microsoft DLL's in order to reverse engineer USB drivers for
Linux or reverse engineer protocols for Samba --- that's dynamic
linking of a sort too --- should that be illegal as well?  Imagine the
power that Microsoft could put into their EULA if copyright
contamination could be as easily achieved by dynamic linking.

Please, let's try to have a little sanity here,

						- Ted

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Thu, 14 Dec 2006 16:54:18 UTC
Message-ID: <fa.t4lVWEE2dt817jlcseCiLe1JWao@ifi.uio.no>

On Thu, 14 Dec 2006, David Woodhouse wrote:
>
> But I would ask that they honour the licence on the code I release, and
> perhaps more importantly on the code I import from other GPL sources.

This is a total non-argument, and it doesn't get any betetr by being
mindlessly repeated over and over and over again.

The license on the code you released talked about "derived works".

Not "everything I want to".

If a module owner can argue successfully in a court of law that a binary
driver isn't a derived work, then the GPL simply DOES NOT COVER IT!

In other words, people CAN "honor the license" and still not be required
to put their code under the GPL.

And no, including one header file in order to compile against something
does not automatically make something a "derived work". It may, or it may
not. It really isn't up to you to decide whether it does (and notice how
I'm not saying that it's up to _me_ either!).

For example, all the same people who clamor for free software get
absolutely RABID about "fair use". Guess what "fair use" actually MEANS?

Think about it for a moment. It expressly _limits_ the right of copyright
authors to claim "derived work". So if you argue that anything that ever
includes your header file (but none of your code) and compiles against it
is a "derived work", then you are basically very close to arguing that
"fair use" does not exist.

Do you really want to argue that "everything that has touched anything
copyrighted AT ALL is a derived work"? Do you feel lucky, punk?

THAT is why I think this discussion is so hypocritical. Either you accept
that "fair use" and copyrights aren't black-and-white, or you don't.

If you think this is a black-and-white "copyright owners have all the
rights", then you're standing with the RIAA's and the MPAA's of the world.

Me, personally, I think the RIAA and the MPAA is a shithouse. They are
immoral. But guess what? They are immoral exactly _because_ they think
that they automatically own ALL the rights, just because they own the
copyright.

That is what it boils down to: copyright doesn't really give you "absolute
power". This is why I have been _consistently_ arguing that we're not
about "black and white" or "good against evil". It simply isn't that
simple.

I don't like binary modules. I refuse to support them, and if it turns out
that the module was written using Linux code, and just for Linux, I think
that's a _clear_ copyright violation, and that binary module is obviously
a license violation.

But if the module was written for other systems, and just ported to Linux,
and not using our code, then it's very much debatable whether it's
actually a "derived work". Interfaces don't make "derived works" per se.

Now, is it something you could sue people over? Sure. I actually do
believe that it's very possible that a judge _would_ consider such a
module a derived work, and you can sue people. It probably depends on
circumstances too.

But don't you see the problem with a black-and-white technical measure?

Don't you see the problem with the DMCA and the DVD encryption?

Those kinds of things REMOVE the "reasonable thought" from the equation,
and turn a gradual process into a sharp "right or wrong" situation. AND
THAT IS WRONG. We simply do not LIVE in a world that is black and white.

So if you think somebody violates your copyright, send them a C&D letter,
and eventually take them to court. It's been done. Companies that mis-used
the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing.
I'm not arguing against that at all. What I'm arguing against is the
"blind belief" that you or I have the right to tell people what to do,
just because we own copyrights.

It's not a blind belief that I'm willing to subscribe to. Exactly because
I have _seen_ what that blind belief results in - crap like the DMCA and
the RIAA lawsuits.

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Thu, 14 Dec 2006 17:04:51 UTC
Message-ID: <fa.CahPSx89OmEM4ZJoZNuA8xxYoTw@ifi.uio.no>

On Thu, 14 Dec 2006, Jeff Garzik wrote:
>
> For the record, I also disagree with the sneaky backdoor way people want to
> add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need.

I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done
properly (and I think we use it fairly well).

I think we _can_ do things where we give clear hints to people that "we
think this is such an internal Linux thing that you simply cannot use this
without being considered a derived work".

It's really just a strong hint about what we consider to be internal. The
fact is, "intent" actually does matter, and as such our _intent_ in saying
"these are very deep and internal interfaces" is actually meaningful -
even in a court of law.

So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure",
I see it as being "documentation".

That said, I think that some people seem to be a bit over-eager to use it.
And I actually think that weakens the rest of them too (imagine a lawyer
saying in front of a judge:

  "Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd,
   but look, it's a standard function available everywhere else too, and
   you can implement it as one line of code, so a module that uses it
   clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not
   something that means anything"

So this is why I've actually argued in the past for some
EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly
because over-using them actually _weakens_ them, and makes them pointless
both from a documentation _and_ from a legal standpoint.

Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal
sense and has actually made people happier, for what its worth. Of course,
you can get <n*2> different opinions from <n> lawyers, so that may not be
all that meaningful ;)

				Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Thu, 14 Dec 2006 18:53:02 UTC
Message-ID: <fa.9W3hEu02rBLwr4zJSxxIGUeSI44@ifi.uio.no>

On Thu, 14 Dec 2006, Chris Wedgwood wrote:
>
> Calling internal symbols _INTERNAL is confusing?

Well, I'm not sure the _INTERNAL name is all that much better than the
_GPL one.

In many ways, the _GPL one describes the _effects_ better, and also points
out the reason _why_ something is marked differently. Sure, it's marked
becasue it's internal, but why is does that have to be pointed out at all?
Why not use the same EXPORT_SYMBOL? The answer to that is the "GPL" part,
ie the expectation that internal symbols are so internal that they have
license effects.

And if you were an external vendor doing binary only modules, would you
react to "internal"? It wouldn't have the same "oh, _that_ is what it is
all about" thing, would it?

So I do agree that we have probably done a bad job of explaining why that
_GPL thing makes sense, and what it means on a deeper level (the license
thing is a very superficial thing, but its worth naming just because the
superficial thing is also the biggest _impact_ - even if it may not be the
underlying deeper _reason_ for it).

So which makes more sense from a naming standpoint: the superficial impact
that is what _matters_ for people, or the more subtle issue that causes it
to have that impact?

I think that question is what it boils down to, and at least personally,
while I see both things as being worthwhile, I think the superficial thing
is the one that needs pointing out, because it's the one that may change
your behaviour (while the deeper _meaning_ is more of just an
explanation).

But I don't personally care that deeply. I mostly care about the fact that
changing the name now would just be inconvenient and unnecessary churn,
and that's probably my biggest reason to not want to do it ;)

			Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 
	2.6.19]
Date: Thu, 14 Dec 2006 17:19:30 UTC
Message-ID: <fa.dsbLOgnwyizjB5N0Huc5xI9mCzU@ifi.uio.no>

On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people
> > distributing the infringing software for 1 Euro at Ebay.
>
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.

.... or like Microsoft, who is threatening to make war on end-users
instead of settling things with vendors.  (One of the reasons why I
personally find the Microsoft promise not to sue _Novell_'s end users
so nasty.  Microsoft shouldn't be threatening anyone's users; if they
have a problem, they should be taking it up with the relevant vendor,
not sueing innocent and relatively shallow-pocketed end-users and
distributors.)

One of the things that I find so interesting about how rabid people
get about enforcing GPL-only modules is how they start acting more and
more like the RIAA, MPAA, and Microsoft every day....

						- Ted

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Thu, 14 Dec 2006 17:23:32 UTC
Message-ID: <fa.2dQGUWP4Y2nemuU0av8v162hhrM@ifi.uio.no>

On Wed, 13 Dec 2006, Alan wrote:
>
> He only owns a small amount of the code. Furthermore he imported third
> party GPL code using the license as sole permission. So he may have dug
> a personal hole but many of the rest of us have been repeatedly saying
> whenever he said that - that we do not agree.

[ The "he" being me in the above ]

Btw, I'd like to make it clear in this discussion too (as I have in
others), that I agree 100% with Alan here.

The thing is, my opinion is really just _my_ opinion. People shouldn't see
it as anything else. When I say "I don't think we should totally disallow
binary modules", you should always keep in mind that:

 - the fact that I think that _some_ binary modules may be perfectly legal
   does not mean that I think _all_ binary modules would be legal. I think
   there are lots of ways to make such a binary module that is obviously
   not ok.

 - I really _am_ just one of hundreds of copyright owners. The fact that
   _I_ am not necessarily all that eager to take things to court should in
   no way be seen as estoppel for _others_ who decide that they want to
   flex their legal rights.

So when I "may have dug a personal hole", please realize that this is
actually a personal - and conscious - choice. I've never wanted to do
copyright assignments, for several reasons: I think they are nasty and
wrong personally, and I'd hate all the paperwork, and I think it would
actually detract from the development model.

But one of the reasons I've never wanted copyright assignments is that I'm
personally actually _more_ comfortable with the system being co-owned. I
_like_ having my hands bound, and being in that hole. Not because of any
strange sexual hangups either, but simply because I think being personally
limited is something that makes people trust me more in the end - or
rather, it is something that means that people don't _have_ to trust me.

So people know that I can't unilaterally change the license. And they
_know_ that they can actually take things to court on their own. AND THAT
IS A GOOD THING. The last thing anybody _ever_ wants is to have me having
absolute powers. Not you guys, and certainly not me.

So you guys should always be happy, realizing that Linus may have his
quirks, but that my quirks can't ever really screw you guys up.

So I repeat: my opinions are _my_ opinions. Nobody else is legally bound
by them. And I'm certainly willing to bend my behaviour in the presense of
pressure (I think only mindless idiots can't change their mind - I
personally change some of my opinions several times a day just to keep
them fresh), but in something like this, where I _do_ have a fairly strong
opinion, I really think that this kind of patch has to be merged in
somebody elses tree than mine.

If, after a year, it turns out that my tree is the only one that doesn't
have that clause, I think I'll either get the hint, or people will realize
that I'm pointless and will just ignore me. It will have taken you long
enough to realize that ;)

Because one of the great things about the GPL is that _nobody_ has the
power to deny other peoples will. Not even me, not even for the kernel.

				Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Sat, 16 Dec 2006 02:55:49 UTC
Message-ID: <fa.FExMliE6EJkOThZwW3M5o5wtjRY@ifi.uio.no>

On Sat, 16 Dec 2006, karderio wrote:
>
> As it stands, I believe the licence of the Linux kernel does impose
> certain restrictions and come with certain obligations

Absolutely. And they boil down to something very simple:

	"Derived works have to be under the same license"

where the rest is just really fluff.

But the point is, "derived work" is not what _you_ or _I_ define. It's
what copyright law defines.

And trying to push that definition too far is a total disaster. If you
push the definition of derived work to "anything that touches our work",
you're going to end up in a very dark and unhappy place. One where the
RIAA is your best buddy.

And the proposed "we make some technical measure whereby we draw our _own_
lines" is exactly that total disaster.

We don't draw our own lines. We accept that the lines are drawn for us by
copyright law, and we actually _hope_ that the lines aren't too sharp and
too clearcut. Because sharp edges on copyright is the worst possible
situation we could ever be in.

The reason fair use is so important is exactly that it blunts/dulls the
sharp knife that overly strong copyright protection could be. It would be
a total disaster if you couldn't quote other peoples work, and if you
couldn't make parodies on them, and if you couldn't legally use the
knowledge you gained for them.

In other words, copyright MUST NOT be seen as some "we own this, and you
have no rights AT ALL unless you play along with our rules". Copyright
absolutely _has_ to allow others to have some rights to play according to
their rules even without our permission, and even if we don't always agree
with what they do.

And that is why it would be WRONG to think that we have the absolute right
to say "that is illegal". It's simply not our place to make that
judgement. When you start thinking that you have absolute control over the
content or programs you produce, and that the rest of the worlds opinions
doesn't matter, you're just _wrong_.

And no, "BECAUSE I'M GOOD" is _not_ an excuse. It's never an excuse to do
something like that just because you believe you are "in the right". It
doesn't matter _how_ much you believe in freedom, or anything else -
everybody _always_ thinks that they are in the right.  The RIAA I'm sure
is in a moral lather because they are protecting their own stronghold of
morality against the infidels and barbarians at the gate.

So don't go talking about how we should twist peoples arms and force them
to be open source of free software. Instead, BE HAPPY that people can take
advantage of "loopholes" in copyright protections and can legally do
things that you as the copyright owner might not like. Because those
"loopholes" are in the end what protects YOU.

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Sat, 16 Dec 2006 16:34:34 UTC
Message-ID: <fa.rLbgMHN9n9znuNqaSCUozxklxhs@ifi.uio.no>

On Sat, 16 Dec 2006, Rafael J. Wysocki wrote:
>
> I think the most important problem with the binary-only drivers is that we
> can't support their users _at_ _all_, but some of them expect us to support
> them somehow.

Actually, I do think that we've made our position on that side pretty
clear.

I think people do by-and-large know that if they load a binary module,
they simply can't get supported by the kernel developers.

We make that fairly clear at module loading time, and I think it's also
something that people who have read linux-kernel or seen other peoples
bug-reports are reasonably aware of.

I realize that a lot of people never read the kernel mailing list, but
they probably don't look at www.kernel.org either - they got their kernel
from their distribution. The only way they realize is probably by looking
at where they got whatever binary modules they use.

That said - it should be noted that a lot of the time when you use a
binary module and have an oops, the oops doesn't necessarily have anything
to do with your binary module. If I recognize the oops from other reports,
I certainly won't say "I'm not going to help you, because you used a
binary module". If I can tell where the problem is, the binary module is a
non-issue.

It's only when we try to debug things that we say "You've got a binary
module, you need to reproduce this problem _without_ it, because otherwise
we can't bother to waste our time on trying to debug something that may be
due to somebody else".

			Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 
	2.6.19]
Date: Sat, 16 Dec 2006 14:50:01 UTC
Message-ID: <fa.iEgWDwI+jSM6462dOcqFgQuyGJk@ifi.uio.no>

On Sat, Dec 16, 2006 at 07:43:44AM +0100, Willy Tarreau wrote:
> All this is about "fair use", and "fair use" comes from compatibility
> between the author's intent and the user's intent.

That is NOT TRUE.  If the author's intent is that anyone who is using
a TV with a screen larger than 29" and with two chairs is a theatrical
performance, and so anyone with a large screen TV must ask permission
from the MPAA first and pay $$$ before they crack open a DVD, would
you think that they should be allowed to claim that watching a DVD
isn't fair use unless you obey their rules?

I thought not.

						- Ted

P.S.  For people who live in the US; write your congresscritters; the
MPAA wants to propose new legislation stating exactly this.

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 
	2.6.19]
Date: Sat, 16 Dec 2006 20:23:45 UTC
Message-ID: <fa.JjL+bVYAZ4XzBTAZEsp388cER7c@ifi.uio.no>

On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote:
> I don't think this is the same case. The film _author_'s primary goal is
> to have a lot of families buy his DVD to watch it. Whatever the MPAA says,
> I can consider it "fair use" if a family of 4..8 persons watch the DVD at
> the same time.

"You can consider it"?  But you're not the author.  This is the
hypocrisy that Linus was talking about.  At the same time that you're
trying to dictate to other other people can use their copy of the
Linux kernel, when it comes to others people's copyrighted work, you
feel to dictate what is and isn't "fair use".

That's the big thing about dynamic linking.  The GPL has always said
it is about distribution, not about use.  The dynamic linking of a
kernel module happens in the privacy of someone's home.  When we try
to dictate what people are doing in the privacy in their home, we're
no better than the MPAA or the RIAA.

As far as whether or not someone is allowed to distribute a binary
module that can be linked into the Linux kernel, that's a question of
whether the binary module is a derived work or not.  And that's not up
to us, that's up to the local laws.  But before you decide that you
want the most extreme form of anything that wanders close to one
person's code or header files is a derived work, and to start going to
work lobbying your local legislature, recall that there have been
those who have claimed that Linux is a derived work of Unix because we
used things like #define's for errno codes and structure definitions
of ELF binaries.  You really sure you want to go there?

						- Ted

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Sat, 16 Dec 2006 16:29:13 UTC
Message-ID: <fa.kZH6BCqh/06NAOnhrP3iF9bd5Rg@ifi.uio.no>

On Sat, 16 Dec 2006, Willy Tarreau wrote:
>
> All this is about "fair use", and "fair use" comes from compatibility
> between the author's intent and the user's intent.

No. "fair use" comes from an INcompatibility between the author's intent
and the users intent.

In other words, "fair use" kicks in EXACTLY when an author says "you can't
copy this except when you [payme, stand on your head for two hours, give
your modifications back]", and the user _disagrees_.

Users still have rights under copyright law even when the author tries to
deny them those rights.

Of course, all reasonable true authors tend to agree with fair use. People
who actually do "original work" tend to all realize that everybody really
feeds off of each others works, and that we're all inspired by authors etc
that went before us. So I doubt a lot of real authors, musicians or
computer programmers will actually disagree with the notion of fair use,
but it's important to realize that fair use is exactly for when the users
and the authors rights clash, and the user DOES have rights. Even rights
that weren't explicitly given to them by the author.

> For this exact reason, I have added a "LICENSE" file [1] in my software
> (haproxy) stating that I explicitly permit linking with binary code if
> the user has no other choice (eg: protocols specs obtained under NDA),
> provided that "derived work" does not steal any GPL code (include files
> are under LGPL). On the other hand, all "common protocols" are
> developped under GPL so that normal users are the winners, and everyone
> is strongly encouraged to use the GPL for their new code to benefit from
> everyone else's eyes on the code.
>
> This clarifies my intent and let developers decide whether *they* are
> doing legal things or not.

I think that's fine, and I think it may make some of your users happier,
and breathe more easily. I don't disagree with that kind of clarification.

But:

> Don't you think it would be a good idea to add such a precision in the
> sources ?

I think it would be a hell of a lot better idea if people just realized
that they have "fair use" rights whether the authors give them or not, and
that the authors copyrights NEVER extend to anything but a "derived work".

I find the RIAA's position and the DMCA distasteful, and in that I
probably have a lot of things in common with a lot of people on this list.
But by _exactly_ the same token, I also find the FSF's position and a lot
of GPL zealots' position on this matter very distasteful.

Because "fair use" is NOT something that should be specified in the
license. It's very much something that people have DESPITE any license
claiming otherwise.

And I'd rather teach people that fundamental fact, than try to confuse the
issue EVEN MORE by saying that my copyright only extends to derived works
in the license text. That will just make people think that if the license
does NOT say that, they don't have fair use. AND THAT IS WRONG.

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Sat, 16 Dec 2006 17:20:57 UTC
Message-ID: <fa.BtR3BrSRXfA/j9LF1x2KHzoOstE@ifi.uio.no>

On Sat, 16 Dec 2006, Willy Tarreau wrote:
>
> I understand your point, but not completely agree with the comparison,
> because I think that you (as the "author") are in the type of authors
> you describe below :
>
> > Of course, all reasonable true authors tend to agree with fair use.

Sure. Sadly, in this day and age, "copyright owner" and "author" only bear
a very passing resemblance to each other.

In a lot of areas, the AUTHOR may be a very reasonable person, and realize
that fair use is a good thing, and perhaps even realize that in some
places even unfair use can be a good thing (do you really think you should
pay $20 for a DVD if you make $3 a month in a sweatshop in china? Maybe
piracy sometimes is simply better..)

But the author may also have his own reasons for wanting to _deny_ fair
use. Maybe he's just a royal a-hole, and wants to milk his work for
whatever it's worth. But maybe he's a person with an agenda, and wants to
ignore fair use because he wants to "improve the world for everybody",
never mind that he tries to deny people a fundamental right in the
process. I call those people a-holes too (in all fairness, they return the
favor, so we're all even ;)

But even more commonly, the author simply doesn't control the copyright at
all any more. In many areas (and software is one - including even large
swaths of free software), the copyrights of a work is not really
controlled by the author of the work, but by companies or foundations that
have no reason to really try to educate people about "fair use".

So I actually think that the authors that actually UNDERSTAND fair use,
and realize that people can use portions of their work without permission,
AND that actually control their work is a very very very small subset of
authors in general.

This has nothing to do with software per se, btw. Pick up one of the
Calvin & Hobbes books by Bill Watterson - I think it may have been the "10
year anniversary" one - where he talks about the disagreements he had with
the people who actually controlled the copyrights (and I think also some
of the people who used his artwork without any permission - the line
between "fair use" and "illegal" really is a murky one, and while we
should celebrate that murkiness, it's also why people disagree).

> > And I'd rather teach people that fundamental fact, than try to confuse the
> > issue EVEN MORE by saying that my copyright only extends to derived works
> > in the license text. That will just make people think that if the license
> > does NOT say that, they don't have fair use. AND THAT IS WRONG.
>
> That's a valid point. What is really needed is to tell them that if they
> doubt, they just have to ask the author and not be advised by any GPL zealot.

Well, in open source, there often isn't any one "the author". So you can't
do that. And when there is, as mentioned, he may not actually even have
the legal right any more to give you any license advice. And even when he
does hold the copyrights, he may change his mind later.

So in the end, the thing you can and should depend on is: the license text
itself (and happily, the GPLv2 very clearly talks about the real line
being "derived work" - it may be a murky line, and they seem to want to
change that to something harder in the GPLv3, but it's a good line), a
separate signed contract, or simply a legal opinion, preferably by a judge
in a court of law.

Of course, it very seldom gets to that kind of issue. People tend to just
walk very gently around it all.

If you want to be safe, you NEVER do any binary modules. The only
_obviously_ safe thing is to always do only what the license very
explicitly allows you to, and in the case of the GPLv2, that's to release
all modifications under the same GPLv2.

Anything else, you have to make some really scary decisions. Can a judge
decide that a binary module is a derived work even though you didn't
actually use any code? The real answer is: HELL YES. It's _entirely_
possible that a judge would find NVidia and ATI in violation of the GPLv2
with their modules.

Judges have done stranger things. And it's not my place to say what the
limit of "derived work" actually is. It all probably depends on a lot of
circumstances, and there simply isn't an easy answer.

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
Date: Sat, 16 Dec 2006 21:01:39 UTC
Message-ID: <fa.5D1zK/nyYrPLC4P9ezoC+0PxiT4@ifi.uio.no>

On Sat, 16 Dec 2006, Ricardo Galli wrote:

> As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried
> to change or restrict "fair use". GPL[23] covers only to "distibution" of the
> covered program. The freedom #0 says explicitly: "right to use the program
> for any purpose".

I'm sorry, but you're just rewriting history.

The FSF very much _has_ tried to make "fair use" a very restricted issue.
The whole reason the LGPL exists is that people realized that if they
don't do something like that, the GPL would have been tried in court, and
the FSF's position that anything that touches GPL'd code would probably
have been shown to be bogus.

In reality, if the FSF actually believed in "fair use", they would just
have admitted that GNU libc could have continued to be under the GPL, and
that any programs that link against it are obviously not "derived" from
it.

But no. The FSF has very much tried to confuse and muddle the issue, and
instead have claimed that projects like glibc should be done under the
"Lesser" GPL.

That's just idiocy, but it works as a way to defuse the problem that the
FSF has always had with admitting that not only _they_ have "fair use"
rights, but others have them too.

Do you REALLY believe that a binary becomes a "derived work" of any random
library that it gets linked against? If that's not "fair use" of a library
that implements a standard library definition, I don't know what is.

And yes, the FSF really has tried to push that totally insane argument.

So don't tell me that the FSF honors "fair use". They say they do, but
they only seem to honor it when it helps _their_ argument, not when it
helps "those evil people who try to take advantage of our hard work".

The fact is, if you accept fair use, you have to accept it for other
people to take advantage of too. Fair use really isn't just a one-way
street.

		Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 
	2.6.19]
Date: Sun, 17 Dec 2006 04:10:53 UTC
Message-ID: <fa.F8nFk0vcGRyIGSkXStE95ZKR6AM@ifi.uio.no>

On Sun, Dec 17, 2006 at 01:22:12AM +0100, Ricardo Galli wrote:
> OK, let assume your perspective of the history is the valid and real one,
> then, ¿where are all lawsits against other big GPL only projects? For example
> libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold
> in court.

There's no need for lawsuits against things like libqt.  The question
is whether someone who writes a commercial program that happens to
dynamically link against libqt is in fact in violation of copyright
claims.  In such a case, the owners of libqt would have to sue the
commercial application writer, not the other way around.  There
haven't been any such cases, mostly because (a) the FUD generated by
the FSF about GPL vs. LGPL has generally been enough to cause
application authors to avoid using GPL'ed code even if it would be
legally defensible in court, and (b) I personally suspect that the FSF
has deliberately not tried to make a test case out of a commercial
application dynamically linking against a GPL'ed library.

In point of fact, if you compile libss from e2fsprogs on a Solaris
machine, and then let the Sun Enterprise Authentication Mechanism (a
proprietary version of Kerberos v5) link against that version of libss
(as opposed to the one derived from the MIT Kerberos version of
libss), you can have a proprietary Sun binary linking against libss
which will called will dynamically pull in the GPL'ed version of
readline (or the BSD licensed editline library, whichever one it finds
first in its search path).  Quick!  Is there a GPL violation involved,
and if so, who should the FSF try to sue first?

There are indeed plenty of cases where the GPL has been upheld in a
court of law, but usually it's some straightforward case of an
embedded version of Linux being used without releasing source.  As far
as I know, there has been no case on point about GPL and dynamic
linking, and I personally suspect it's at least partially because the
FSF is afraid it would lose such a case.  (As I've said, at least one
law professor of mine from the MIT Sloan School of Management has told
me that in her opinion the FSF's theory would be "laughed out of
court").

						- Ted

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules
Date: Sun, 17 Dec 2006 18:01:03 UTC
Message-ID: <fa.VSWCKHCsdQKhyBZVoHkD9HTOYPA@ifi.uio.no>

On Sun, 17 Dec 2006, Alexandre Oliva wrote:

> On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > The whole reason the LGPL exists is that people realized that if they
> > don't do something like that, the GPL would have been tried in court, and
> > the FSF's position that anything that touches GPL'd code would probably
> > have been shown to be bogus.
>
> Or that people would feel uncomfortable about the gray area and avoid
> using the GPLed code in cases in which this would be perfectly legal
> and advantageous to Free Software.

I agree. A lot of it is about "comfort". But you can _easily_ handle that
comfort level in other ways.

For example, many programs already do have clarifications that certain
uses do not introduce any GPL dependency what-so-ever. The kernel COPYING
makes it clear that user space is not a derived work of the kernel, for
example. You don't actually need to use a different license for this case:
if all you're looking for is "comfort", then you really can comfort people
other ways.

For example, glibc could easily have just come out and said the thing that
is obvious to any sane person: "using this library as just a standard
library does not make your program a derived work".

There really wassn't much need for the LGPL, I think.

> There are many factors involved and you're oversimplifying the issue.

Sure. It's never clear-cut. It's never black and white.

> Some claim that, in the case of static linking, since there part of
> the library copied to the binary, it is definitely a case of derived
> work.

No, the sane way to think about it is that linking just creates an
"aggregate" work. It's no less "aggregate" than creating a CD-ROM that
contains the library and some random program: you "link" them together
with "mkisofs".

Why do people think that using "ln" is _any_ different from using
"mkisofs". Both create one file that contains multiple pieces. What's the
difference - really?

Of course, the _aggregate_ still needs permission from all the copyright
holders in order to be distributed, that goes without saying. But the
GPLv2 clearly allows aggregation.

And don't get me wrong: I do not say that "linking" _never_ creates
derived works. I'm just saying that "linking" is just a technical step,
and as such is not the answer to whether something is derived or not.
Things can be derived works of each other _without_ being linked, and they
may not be derived works even if they _are_ linked.

So "linking" basically has very little to do with "derived" per se.

Linking does have one thing that it implies: it's maybe a bit "closer"
relationship between the parts than "mkisofs" implies. So there is
definitely a higher _correlation_ between "derived work" and "linking",
but it's really a correlation, not a causal relationship.

For example, if you link two object files together where neither is a
"library" with standard interfaces, then the result is most likely a
derived work from both. But it wasn't the "act of linking" that caused
that to happen, but simply the fact that they were part of a bigger whole,
and were meaningless apart from each other.

Think of this in the sense of a book. Does binding pages together create a
"derived work"? Not always: you can have anthologies (which are
*aggregations* of works with *independent* copyright), and the binding of
pages together didn't really do anything to the independent pieces. But
clearly, if you're talking about individual pages in one story, then each
individual page is not an independent work in itself.

Linking is the same way. Are the two pieces you link "independent works"
on their own? If so, the end result is really just an aggregate, no
different from using "mkisofs". They are still clearly separable: you
could have built either piece AGAINST SOMETHING ELSE.

> Some then take this notion that linking creates derived works and
> further extend the claim that using dynamic linking is just a trick to
> avoid making the binary a derived work, and thus it shouldn't be taken
> into account, even if there still is *some* information from the
> dynamic library that affects the linked binary.

See how this whole "trick" discussion becomes a totally moot point once
you realize that "mkisofs" and "ld" aren't really all that different.

Does "mkisofs" create a derived work, or an aggregate? Does "ld" create a
derived work or an aggregate? The answer in BOTH cases is the same: it's
not about the name of the command, or some technical detail about how the
pieces are bound together. Copyright law doesn't concern itself with
"mkisofs" vs "ld". It would be totally INSANE if it did, wouldn't you say?

So if it isn't about "mkisofs" vs "ld", then _what_ is it about?

I gave you one answer above. Feel free to make your own judgements. I'm
just saying that anybody who thinks that copyright law cares about
"mkisofs" vs "ld" is just obviously misguided.

So I think the "dynamic vs static" linking argument is a red herring. It
_is_ meaningful in two ways:

 - static linking obviously means that even at a MINIMUM, the result will
   _contain_ both things, so at a minimum, you do need the permission to
   distribute the pieces as parts of an aggregate work.

   In contrast,  in dynamic linking, since you're not _actually_
   distributing the thing you linked against, you don't need to have the
   license to distribute it as an aggregate work.

   This particular thing is a non-issue wrt the GPLv2, since you always
   have the right to do distribution of aggregates, but it does come up in
   some OTHER licenses.

 - you can (quite validly, in my opinion) argue that dynamic linking is a
   sign of separation, and as such if you're able to do dynamic linking
   against an unmodified second work, you have a much stronger argument
   that they really can be seen as two independent works. But notice how
   this was not a technical argument about the _linking_ per se: this
   comes back to a much more important (and much more fundamental) issue
   of whether things are independent (and being independent is certainly
   one _requirement_ for them not being derived works)

   In other words: the _ability_ to do dynamic linking is certainly
   meaningful, not because of the linking itself, but because of what it
   implies from a perspective of "independence".

So to get back to the example of glibc: if a program _could_ have been
linked against some other library, then that pretty clearly shows that
it's really independent of glibc, and the linking is "mere aggregation"
exactly the same way "mkisofs" is generally considered "mere aggregation".

And that is actually true whether you link dynamically or statically.
Since the GPLv2 allows aggregation, I think you can very much argue in
front of a judge that you could have linked statically against even a
GPL'd glibc.

But notice how the thing changes if you talk about a specialized library
like libqt - and notice how it again doesn't really matter whether you do
dynamic or static linking. Libqt is still a work in its own right, but
what about the program that links _to_ it? You can't generally really
claim that it could equally well have been built against some other
library, so now that program - whether linked dynamically or statically -
obviously cannot stand on its own independently of libqt.

As a result, something that links against libqt is very different from
something that links against glibc.

But note how it wasn't "static" vs "dynamic" that mattered AT ALL. What
mattered was whether they had independent lives.

And finally, in case it's not clear: I'm not a lawyer, and I don't play
one on TV, and if I did, I'd be better looking and wouldn't spend my time
on some technical discussion forum. So I'm not claiming that my viewpoint
is "Right(tm)".

But I _am_ claiming that it makes a hell of a lot more sense as a
viewpoint than the "linking is magic" argument does.

			Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: GPL only modules
Date: Mon, 18 Dec 2006 17:03:27 UTC
Message-ID: <fa.FWN6VMDlhzRXDEW2uwyvVj9cofY@ifi.uio.no>

On Mon, Dec 18, 2006 at 10:38:38AM -0500, Dave Neuer wrote:
> I think this is the key, both with libraries and w/ your book example
> below; the concept of independent "meaning." If your code doesn't do
> whatever it is supposed to do _unless_ it is linked with _my_ code,
> then it seems fairly clear that your code is derivative of mine, just
> as your sequel to my novel (or your pages added onto my book) don't
> "mean" anything if someone hasn't read mine.

That's a wonderful theory, but I don't believe it's recognized by the
courts.  I'm also pretty sure you don't want to go there.  Consider
folks who create add-ons to Tivo player, or extensions to MacOS.  They
don't _do_ anything unless they are used with the Tivo player.  Or a
game meant for a Playstation 3; it won't _do_ anything unless it's
calls the BIOS and system functions provided by the PS3.  Does that
automatically make them derived works?

What about a GPL'ed program which interfaces with the iTunes server?
It won't _do_ anything unless it can connect across the network and
talks to iTunes code.  Does that make it a derived work?

If the answer is no --- or should be no --- then maybe you should be
more careful before making such statements.

For myself, I believe we actually get the largest amount of
programming freedom if we use a very tightly defined definition of
derived code, and not try to create new expansive definitions and try
to ram them through the court system or through legislatures.  In the
end, we may end up regretting it.

						- Ted