On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: > Right, but for the analysis to be complete you must include the definition of > what > the complete source code is. This is provided in the second sentence of the > ultimate para. in Section 3, which provides
Could you please limit your line lengths to around 75 characters? Anything
else makes it painful to read and awkward to quote.
> For an executable work, complete source code means all the
> source code for all modules it *contains*, plus any associated
> interface definition files, plus the scripts used to control
> compilation and installation of the executable.
Emphasis yours.
>
> The key part being the reference to "all modules it *contains*", rather than
> all
> modules which may at run-time be linked to it. To substantiate the point, I
> again
> refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and
> look-up
> "contain", quoting the relevant definitions:
>
> (1) to have in it; hold; enclose or include.
> (2) to have the capacity for holding.
What does (2) mean?
``This bucket contains four gallons of water. No, it doesn't have any
water in it, but it has the capacity for holding four gallons, so
therefore it contains four gallons.''
That doesn't make sense at all in this context as far as I can see.
Leaving that aside, though...
The intention of the authors (GNU and rms) is fairly clear, and they make
their interpretation fairly clear in the LGPL's (written by the same authors)
preamble:
When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. [...]
As such, I'm not really sure how you can say ``But that's not what RMS
meant, coz that's not what he wrote, see, this is what the dictionary
says and everything!'' and expect to be taken seriously.
Hmmm.
Actually, that's not entirely the whole story.
The LGPL (Library GPL) version 2, dated June 1991 (which is the same as
the GPL), had the following text in the preamble:
The reason we have a separate public license for some libraries is that
they blur the distinction we usually make between modifying or adding to a
program and simply using it. Linking a program with a library, without
changing the library, is in some sense simply using the library, and is
analogous to running a utility program or application program. However, in
a textual and legal sense, the linked executable is a combined work, a
derivative of the original library, and the ordinary General Public License
treats it as such.
That is, it didn't differentiate between statically linked executables
(which clearly makes a combined work under copyright law), and dynamically
linked binaries (which is less clear).
Now with dynamically liked GPL software we have three cases:
(a) A GPLed binary linked against a GPLed library
(b) A GPL-incompatible binary linked against a GPLed library.
(c) A GPLed binary linked against a GPL-incompatible library
(dynamic linking in all cases)
We'll note that in no case is the library a derived work (in any sense)
based on the binary (it doesn't include any code from the binary, it's
perfectly usable without the binary having ever been written, and so on).
It's probably arguable whether the binary is a derived work based on the
library or not. At best, it may contain portions of the library's interface
definitions (header files and what-not), however these are probably not
copyrightable [0].
Now, for (a) presumably we don't have any issues at all, and everyone's
happy. Of course, it would only apply to KDE if there was a (L)GPLed Qt
clone about.
Now (b) is clearly not the case for KDE. However it's probably the most
questionable one. Clearly, there aren't any issues with distributing
the library on its own. As far as distributing the binary is concerned,
it seems to me that you'd have to make one of the following arguments
to get the GPL to apply:
(1) the dynamically linked binary is a derived work (under
copyright law) of the library, as well as the binary's source
code, because it includes portions of the headers in the
resultant binary. (section 0 of the GPL)
(2) the dynamically linked binary is a derived work (under
copyright law) of the library, because it doesn't work without
the library.
(3) static linking is obviously bad, and since dynamic linking
is just the same as static linking except for a command line
option, and some random techincal things, both must be bad.
(4) while it's okay to distribute the binary and the library,
once you've got them you're not allowed to actually execute
the binary, because doing so would create a derived work
(in memory) in a manner that the GPL doesn't permit you to.
(1) is probably dodgy, since it's based on interface definitions being
copyrightable, or APIs being licensable, or similar.
(2) certainly makes *sense*, but copyright law doesn't actually seem to
justify it, and there's some case law which almost certainly refutes it.
(3) also makes sense, but copyright doesn't support it at all. Maybe it
should.
And for (4), you probably don't *need* the GPLs permission, since you're
not going to distribute it, and it's almost certainly fair use anyway.
The final case, (c), which is what KDE fits under, doesn't have as
"easy" an out, though. When you're distributing KDE, you obviously
have to obey the GPL since you're distributing a whole bunch of GPLed
software. Now, to obey the GPL, you need to (be able to) distribute the
`complete corresponding machine-readable source code' (3a).
To clarify this ("what's source code?", "what do you mean by complete?"),
the GPL then continues:
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
You could probably argue, based on this, that nowhere does it actually say
you have to make the compiler itself available, eg: it's not a module
contained in the source code, it's not an interface definition file, and
it's not a script. I suspect it's proper to treat the above as examples
rather than an exhaustive list, since both the kernel and the compiler
are exempted in the very next sentence.
So lets ask ourselves what this is meant to mean. The way I figure it,
it's basically asking for the source code, along with any bits of the
compilation environment that aren't standard bits of the OS itself.
I'm not really sure which of `look, I don't care what they *meant*, or
what people usually understand it to mean, but this is what it *says*
dammit, just look at the dictionary!' and `look, it's a bit dodgy,
sure, but if you squint and just go with me here, this is obviously what
they mean' is more legally valid, really.
At the very least, by this reading, you need to be able to make libqt.so
available --- it's part of the compilation environment, since you can't
compile KDE without libqt.so. You could argue that you don't actually
need to distribute the source code to libqt.so --- you don't need it
to build a binary, afterall. But the same argument would apply equally
well to .a files for static linking, and they've already been specifically
required to have source code available.
This interpretation is a little tenuous, depending on whether interpreting
`all modules it contains, plus any associated interface definitions
files, plus the scripts used to control compilation and installation'
as not exhaustive is reasonable or not. I'm inclined to think it is.
You'll also note that this was written in '91 at around the same time as
the LGPL, which, you'll recall, was a bit vague on the differences between
statically and dynamically linked libraries. So it's possibly reasonable
to interpret shared libraries as a `new innovation' (heh. right), and
extrapolate from the listed items to shared libraries as well.
Let me put this another way. Suppose one day you think to yourself
"Hey, this whole DVD on Linux thing is pretty trendy, I think I'll add
*licensed* DVD support to Emacs! That'll be so cool!" So off you go and
get a key and a license and whatever else from Sata^H^H^H^Hthe MPAA,
and design some suitably funky decryption code that's utterly painful
to reverse engineer. Next, you code a little compiler that as well
as compiling your bitblitting stuff much better than gcc ever could,
adds your really funky decryption code in at the appropriate place. You
then get your emacs binary, and distribute it. Someone asks you for
the source, under GPL clause 3, and you give them everything but your
homespun-compiler thing, along with a little note "I'm not distributing
the add_dvd binary to you, since I don't want to and it's not a module
contained in emacs, nor an interface definition file, nor a script. So
nyeah."
Do the Emacs authors have a right to a certain righteous wrath? Do they
have a legal leg to stand on? Is the GPL thus forever doomed?
Richard, I wonder if you could point out the holes in the above analysis,
since it seems to contradict the comments in the latest LGPL (which
doesn't seem to be up on the fsf website under the LGPL link, weirdly),
or pass it on to your legal guys, and/or point me/us to an in-depth
FAQ/analysis as to how copyright allows the GPL to apply even when one
piece of software simply references another (as the dynamically linked
binary does).
> Care to explain why not? You think "component" cannot be read to mean a
> library?
> The quote says, "the major components (compiler, kernel, and so on) of the
> operating system". Why does libc not get caught up in "and so on"?
And, indeed, it must. For if it didn't, back in the bad old days before
Linux or BSD, in order to distribute, say, Emacs, you'd need to distribute
a binary statically linked to a proprietry libc, which clearly comes
under the `complete source code for all modules it contains', and thus
had better come under the exemption as well.
And note that libc doesn't have to *be* a major component: it merely has
to be distributed with them. If Sun happen to distribute a little rot13
binary on their Development CD along with cc, and ld and some debuggers
and stuff, then you can make use of the rot13 binary, just as you can
make use of the compiler.
> Sure it does. If in the Libc Hypothetical libc were not statically linked,
> libc
> clearly would not "accompany" the executable and so the "special exception"
> would
> apply.
Erm, you're really arguing that if you make a derived work, `foo', from
`bar', and `quux'; then whenever you distribute `foo', you'll find `quux'
accompanying it?
This is plainly false. Take, for example, the two copyrighted works
_1984_ and _A Brave New World_ (the books). Now make a derived work,
based on both of these: write an analysis of the first chapter or so
of each, incorporating both chapters. This is a derived work. If you
distribute it, you can reconstruct the first chapter of both books,
with a little bit of work. That's *all* you can reconstruct.
And again, note that the GPL is really written for statically linked
programs. If what you said were true, you'd never have been able to
distribute Emacs binaries for Solaris.
> I have an excellent grasp of the English language and excellent reasoning
> skills,
And you've obviously got humility to spare, too. Yay you.
Cheers,
aj
[0] http://www.debian.org/Lists-Archives/debian-legal-9911/msg00068.html
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgpSeGuoUIyMP.pgp
Description: PGP signature
