Re: On interpreting licences (was: KDE not in Debian?)
Anthony Towns wrote:
> (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.
To the extent I try to comply with relevant legal obligations, what I think is most
relevant. But anyway that's not the issue. My interpretations are only as convincing as my
reasoning and my explanations. RMS' reasoning and explanations can of course be convincing
as well. The problem with your quote is, there was no reasoning or explanation, just a
conclusory assertion. I would expect my conclusory assertions not to convince anyone either.
Basically it's a matter of epistemology. I gain little knowledge from pronouncements from
the mountain top. I learn from debate, reflection and critical analysis.
> Do you not concede that RMS is something of an expert both in relation
> to software in general, and in relation to the GPL?
The former, yes. The latter, I am not sure. My take on it is that he has a view about what
he wants/wanted it to say, that most heavily guides his interpretation of what in fact it
does say. In other words, I do not believe he is objective in interpreting the language.
FWIW, I very much respect RMS as a programmer, and as an evangelist, but not as a lawyer. In
fact I still hope that something positive can come out of this debate -- that the
loopholes/mistakes in the GPL can be fixed. Why is it that you appear to be so against
admitting the problems with the GPL and fixing them?
> 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?
Absolutely not. When a court tries to interpret the license (since you agree it's a legal
document, in the end only a court's interpretation matters) the court will look to a
dictionary -- this is a quite common practice when courts interpret legal agreements. That
will be evidence in the case. RMS will not. His testimony will not be allowed, most likely
(things being different if his code is in fact at issue). This is for the exact same reason
that when the meaning of a statute is in question Congressmen are not called in to testify as
to its meaning. The contract is generally interpreted objectively (and if any subjective
component comes in it is that of the licensor -- the code author -- rather than the lawyer or
organization that did the drafting). Using a dictionary to interpret a license is objective
-- using RMS' opinion (or mine or anyone else's) is not.
> Does
> it not seem even with the realm of possibility that it might be the case?
Does it seem even within the realm of possibility that I know what I am talking about?
> 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.
Are you sure? At least I have obvious reasons for considering them separately. First, they
are not in fact part of the same work. It is no different than if you write a book, and then
I write a book reviewing yours. My book depends on your book, yet it is a totally different
work (assuming I only make "fair use" of excerpts from your book). Same holds true for
software. My program (kghostview) is a totally separate work from Qt, *especially* in source
code form.
Second, everyday practice confirms my point. Obviously MS prohibits people from distributing
Windows DLLs w/out their consent. Yet tons of companies and individuals distribute libraries
linked to their DLLs w/out their consent. Under your theory, Apache would need the consent
of MS to distribute Apache for NT, as would all other GPL'd software distributed for Windows
platforms.
Another example is Motif. While I have to buy a license to distribute Motif statically with
my app, I don't have to do so to distribute a program that links dynamically with Motif.
You can pick many other examples here.
> > 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.
Right, that's if you distribute their libraries, which you have to do w/ a Borland program.
That's not what I'm talking about. The example would be if you did not distribute any of
their libraries but assumed them present on the target computer and only distributed your
binary sans Borland libraries. Plus this situation could be complicated by the Borland
license. Their license could spec. prohibit you from doing that, although copyright law has
no problems with it (just like under your reading the GPL places restrictions on you that
copyright law would not). Remember, we are talking about plain old copyright law (whether a
DLL is the same "work" as the program when they are distributed separately and written by
separate authors).
> > > 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.
OK, I disagree with that, for reasons posted numerous times to the kde-licensing list.
> > > 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.
I think you have read this "compilation environment" clause into the GPL. Under that reading
you could not compile a GPL'd program w/ a "GPL-incompatible" (under your copacious reading
of that term) compiler. That's absurd -- how do you think GPL'd works are compiled for
Windows platforms? (And no, compiler's are not "major components" distributed with Windows
-- at least not my copy of Windows <grin>). Moreover, as I point out below, the GPL was
initially intended to work with proprietary compilers -- IIRC many *nixes did not have an
open source compiler in 1991
> 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.
Perhaps, but at a minimum it must "contain" the "module", which is not the case with a
dynamically-linked app.
> > > 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?
Dynamic libraries were not a "new innovation" in 1991. Give me a break -- even the Mac used
dlls -- in ROM no less -- for its user interface libraries in 1984. And even if dlls were
new, there were not a "new innovation" in 1998 when KDE was being distributed, and, unlike a
statute, a license is re-invigorated every time you use it (since obviously the license could
have been updated when this "new innovation" came out if the license did not adequately
address this "new innovation" -- that's why a court would not "update" the license for code
released later, though you might have a shot at the argument for code released prior to the
"new innovation". Essentially courts much prefer that parties update their agreements
themselves, rather than forcing the court to do it.).
> > > 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.
The GPL does not require you to distribute your compiler. The same problem, of course, is
faced by Windows users of GPL'd software -- they cannot modify the code and re-compile it b/c
they lack a "free" compiler.
As to righteous wrath, the Emacs authors may be entitled to that, but that's a
political/emotional, rather than a legal, issue.
And is your example much different from me translating GPL'd code into my compiler language,
making changes to it and redistributing? I don't see how that is forbidden . . . . The GPL
specifically refers to the "scripts" used to control compilation. I don't think your
hypothetical compiler is a script (unless of course it was written in Perl . . . .). The
reason for this is that it was intended to be able to use proprietary compilers (IIRC when
GNU was started that's all there was, people had to rely on proprietary Unix compilers).
As far as I can tell, the only effort made at avoiding intentional obfuscation of the code
was the requirement that the source code be in "the preferred form of the work for making
modifications to it". This was to prevent people from just distributing the assembler code;
but it does not impose any requirements on the language you in fact use to implement the
code. If you in fact write your code in assember, then that is "the preferred form of the
work for making modifications to it".
Just as an aside, being that someone has released the source code, unless the language
created is extremely obfuscating, the GPL would permit someone to convert/reverse engineer
the source code to some more popular language, and release the code in 'C' or 'C++' under the
GPL. So all is not lost . . ..
> > 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,
What do you mean? The "special exception"? That does not count if you in fact distribute
the kernel, and that's what distributions do.
> 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.
That's not the point. The point is that if in fact every program executed on a Linux system
is a derived work of the kernel, then each such program would be a "work based on the
Program" and under your reading you would need to *license* it under the GPL. In other
words, you could not distribute a proprietary program with the Linux kernel. But of course
almost every distribution has been doing this and, in fact, Linus permits distributing
proprietary *kernel modules*.
> > > 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.
Not sure what you are trying to prove here. Does not your "foo" include entire copyrightable
chunks of libc? I thought you were using the "fair use" approach and implying only small
bits of libc would be included. Here you are including entire functions, which are
copyrighted and licensed; in other words, you have modified libc and are including the
modified libc in your binary. So in fact some libc code -- still licensed under GPL/LGPL --
does "accompany" foo. (I think what you overlook is that the first chapter of the book is in
itself copyrighted and that this first chapter "accompanies" your anthology.)
In other words, if I modify my libc source code to include only the code necessary for
"printf" (as in your example), would not the modified result also be LGPL/GPL'd? Yes. Now
if I distribute foo, would this modified libc not accompany foo? Yes..
And you can of course modify a binary under the GPL as well. That's what you do when you
statically link only a few functions to your binary. But the resulting modified libc is
still licensed under the LGPL/GPL. Are you disagreeing with this?
Perhaps it would help if I revisited the context of these remarks. I was having a discussion
with Raul re: the difference b/w a statically linked emacs on Solaris systems (which he
thinks OK) and kghostview (which he thinks not OK). He thought emacs is OK b/c of the
"special exception" in Section 3 of the GPL. My response was that the special exception does
not apply if (1) you view libc as a major component of Solaris (which I do), and (2) you
statically link libc so that in fact it is included in what you distribute. The particular
point you were addressing is point (2). I suppose you could try to defeat point (2) by
saying not the *entire* component (libc) accompanies emacs (although I would guess that emacs
uses almost all libc functions). That would be a reasonable argument, and perhaps the one
you were trying to make (sorry if I missed that earlier).
I can respond to that by pointing out that the "special exception" only applies to things
*accompanying* the "major components", rather than to the major components themselves. If in
fact libc *is* a major component, the special exception does not apply to it. So point (2)
is not critical to my argument; point (1) is; in fact in retrospect it was a mistake to even
raise point (2) since it clearly is irrelevant to my argument.
In any event this particular debate I was having with Raul is not even central to the KDE/Qt
analysis; it assumes that Raul is correct in his interpretation of Section 2 of the GPL, with
which I disagree.
Ciao,
Andreas
Reply to: