(debian-legal brought back into the Cc list)
On Sat, Feb 12, 2000 at 04:02:35PM -0500, Andreas Pour wrote:
> Anthony Towns wrote:
> > > 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 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.
> First of all, what RMS thinks is not relevant [...]
But what you think is, of course.
Do you not concede that RMS is something of an expert both in relation
to software in general, and in relation to the GPL?
As such, do you not think he might understand some of the nuances in the
language of the GPL better than, say, the authors of your dictionary? Does
it not seem even with the realm of possibility that it might be the case?
Your second and third points are just restatements of this.
> Third, I challenge you to find a relevant case that says a program is the same "work",
> for copyright purposes, with a dynamically loaded library when it is not running.
*shrug* So show me some precedents for considering them separately. This is
pretty much a null argument.
> Of
> course, if that were the case, then every single MS Windows program would be a derived
> work of MS Windows dlls and would require the consent of Microsoft to be distributed.
It's been a long time since I've programmed on a commercial platform,
but way back when I did (using Borland compilers) their licenses did
specifically permit you to base your programs on their libraries, and
where necessary distribute the libraries with your program. I think
there was a non-compete clause of some sort in there too.
> > 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).
I should add: and as such, there's probably a reasonable chance that a
court would be willing to extrapolate the existing terms to cover a new
possibility that wasn't considered explicitly.
> > Now with dynamically liked GPL software we have three cases:
> > (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).
>
> > The final case, (c), which is what KDE fits under, doesn't have as
> > "easy" an out, though.
>
> This assumes that Qt is GPL-incompatible. I may or may not agree with that, it could
> really mean a wide range of things.
It means that it can't be distributed under the terms of sections 1 and
2 of the GPL. It means you can't make a statically linked binary linking
to it and distribute it. Etc.
> > 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.
>
> Not at all. If it's statically linked, then by definition its part of what you are
> distributing. And if you are distributing libqt.a, then libqt.a is one of the "modules"
> which the derived work "contains".
Ummm. You, uh, do realise this is what I said?
``Okay. Dynamic linking isn't specifically listed. But it is part of the
compilation environment, so therefore probably comes under this clause.
So therefore you probably have to distribute at least libqt.so under
terms 1 and 2, because that's good enough to recompile the software. But
just distributing libqt.a under terms 1 and 2 would be good enough too:
but you're specifically required to distribute the source code for it
(it's a "contained module" after all), so it'd probably be risky not to
distribute the source for libqt.so under terms 1 and 2 too.''
BTW, "modules it contains" isn't necessarily analogous to the "derived
work" of copyright law.
> > 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.
> Of course its exhaustive. It doesn't say "such as" or "including without limitation".
> It has a list, and that's all there's to it.
Then please respond to the Emacs/DVD hypothetical. Those weren't rhetorical
questions.
> > 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.
> I don't buy it.
And, as such, no judge in any country on Earth would buy it either,
and therefore no one should be at all concerned about distributing KDE
binaries, because it's perfectly legal in the court of Andreas Pour?
> > 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?
I await your response.
> A lot of problems come up if you take the general view that anything linked is a derived
> work. In a sense everything is linked to the kernel, since it jumps into and out of
> executing code; same can be said for the loader, which makes the initial jump into each
> programs "main()". So if you think that by linking you become a derived work, you
> obviously end up in absurdity.
Of course, the GPL specifically excludes the kernel, and in any case, on
GNU/Linux (or GNU/Hurd) systems we can distribute the kernel under terms
1 and 2 of the GPL anyway. Which doesn't strike me as particularly absurd.
> > 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.
> OK, if you find some magical way to include only part of libc in a static program, we
> may have something to debate here.
Eh?
] [aj@azure ~]$ cat foo.c
] #include <stdio.h>
]
] int main(void) {
] printf("Hello, world\n");
] return 0;
] }
] [aj@azure ~]$ gcc -o foo foo.c -static
] [aj@azure ~]$ strip foo
] [aj@azure ~]$ ls -l foo
] -rwxrwx--- 1 aj aj 199532 Feb 13 15:25 foo
] [aj@azure ~]$ ldd foo
] statically linked (ELF)
] [aj@azure ~]$ ls -l /lib/libc-2.1.2.so
] -rwxr-xr-x 1 root root 936696 Nov 9 04:55 /lib/libc-2.1.2.so
You'll note that foo contains bits of libc (the code for printf, for
example; you can check this using the nm(1) command, if you like), and
that it's smaller than libc. Is that enough demonstration? Feel free
to try it at home.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <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
Attachment:
pgp6UchBLC1Vu.pgp
Description: PGP signature