Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote:
> On Mon, Feb 07, 2000 at 06:14:15PM -0500, Andreas Pour wrote:
> > Where does it say that (in the GPL, that is). It only says you have to make
> > available the complete source code to what you are in fact distributing.
>
> I don't think we're disagreeing on this point.
>
> However, I think that you are imagining that people are distributing
> kghostscript executables and not distributing Qt.
>
> That's certainly not what Debian would do, if Debian included kghostscript
> in "main".
So don't put the binary in "main" :-); it's not so hard to have users compile the
2-3 apps that fall within the "KDE developers borrowed GPL code from another
project" category.
> > > > > > The next sentence reads:
> > > > > >
> > > > > > However, as a special exception, the source code distributed need
> > > > > > not include anything that is normally distributed (in either
> > > > > > source or binary form) with the major components (compiler,
> > > > > > kernel, and so on) of the operating system on which the executable
> > > > > > runs, unless that component itself accompanies the executable.
> > > > >
> > > > > Ok, so you are aware of the part of the GPL which lets the proprietary
> > > > > libc be used.
> > > > >
> > > > > > This sentence can easily be read to support the dynamic/static
> > > > > distinction.
> > > > >
> > > > > Eh? You can link the proprietary libc statically and this special
> > > > > exception would still be just as applicable.
> > > >
> > > > No, it would not, b/c then you would actually be distributing the
> > > > executable proprietary libc, and the next clause kicks in (the
> > > > exception ("unless . . .") to the special exception) to require the
> > > > source code to be distributed for the libc part as well.
> > >
> > > Yes, you would be distributing the proprietary libc. But that's legal
> > > if (1) the libc would also be distributed with a major component of the
> > > operating system, and (2) that major component of the operating system
> > > would not accompany the GPLed executable.
> >
> > Right, but if it's statically linked by definition it does accompany the
> > executable.
>
> "it" meaning the GPLed program?
Right.
> If so, why do you use the phrase "accompany the executable"? Aren't you
> talking about the executable of the GPLed program?
Right.
> What does it mean for a program to accompany itself? Why do you raise
> this point?
It's not that the program accompanies itself. The paragraph of Section 3 in
question deals in terms of "components" and "modules", not entire executables. So
in the hypothetical case we discuss, libc is a "component" (although statically
linked, the library is a separate binary inside the "executable", if I understand
the linking process correctly) which accompanies the GPL'd component inside the
executable.
In any event, as I look up the definition of "accompany" in Webster's New Universal
Unabridged Dictionary (2d ed. 1983), I get:
(1) to go with or attend as a companion or associate on a journey, a walk,
etc.; as, a man *accompanies* his friend to church, or on a tour.
(2) to be with, as connected; to attend; as, pain *accompanies* disease.
Syn: attend
And attend means (taking the only relevant definition):
(3) to accompany as a circumstance or result; to be consequent to, from
connection of cause, as fever *attends* a cold; a measure *attended* with ill
effects.
Looking to the first definition of "accompany", I think it fair to say that the
libc "goes with" or "attends as a companion" the GPL executable as it is
distributed.
If you look at Section 3, it refers to "For an executable work, complete source
code means all the source code for all *modules* it contains", with an exception
for "anything that is normally distributed . . . with the major *components* . . .
of the operating system . . . , unless that *component* itself accompanies the
executable." OK, so you need all source code to all modules except for modules
normally distributed with the major components of the OS, unless that component
"accompanies"-- "goes with" -- the executable. In our hypothetical, the module is
libc. Hence, you need the source code to libc, except if libc is normally
distributed with the OS and it does not "accompany" -- "go with" -- the executable.
The problem with your reading of accompany is that a lesser cannot accompany a
greater. However, this is not the case: "I" can accompany my "family", although I
am part of my family, a "component" of my family. Similarly, when you have a set
of components/modules, any one can "accompany" the others, even if they are all
linked together. This is even more the case with GPL, since it is in copyright
universe, and certainly if you have a book composed of essays you can say each
essay "accompanies" the book, although each essay forms part of the book it is
accompanying.
Under your reading, even the OS vendor could get away distributing GPL'd code with
a static proprietary libc or other system library, so long as there is no dynamic
libc (and perhaps, depending on your reading, no program which is non-GPL'd using
that libc), since in each case the GPL'd program will not be accompanied by
So, I guess a clever distributor, under your reading, could create two proprietary
libcs, a "libc-for-GPL-progs" and a "libc-for-other-progs", and for the sake of
argument let's assume they are in fact different libraries (let's say one is
Company X libc and another is Company Y libc). Then the OS vendor could link all
the GPL'd programs to the former (and not have to include the source code to libc
b/c the libc does not, under your reading, "accompany" the GPL'd code), and all the
non-GPL'd programs to the latter (being a different library it does not fall under
the "unless" clause). And to be even cleverer, perhaps both libcs can come from
the same Company, as long as they are different so that for copyright purposes they
are not the same "work". Again, your reading is opening a hole in the GPL.
Another way to state it is, under your reading, under OSs that lack dynamic
linking, no library would every "accompany" any executable, and hence presumably no
library source code need by included regardless of how many GPL'd programs the
vendor distributes. (I hope you do not suggest that a library statically linked in
another executable satisfies the "accompany" term, b/c that is really a stretch.)
> If "it" doesn't mean the GPLed program, what is it that you say would
> be statically linked?
>
> > > There's nothing in that exception which says that libc can't accompany
> > > the GPLed executable.
> >
> > Of course it can, but then you have to include the source code.
>
> Sure -- you not only have to include the source code, but you have to
> make sure it's distributed under GPL terms... but then we wouldn't be
> talking about that proprietary libc.
>
> > > The requirement is that the GPLed executable
> > > can't be accompanied by the major component of the operating system
> > > which includes the cannonical copy of libc.
> > >
> > > Stated even more informally, that exception says: you can use a
> > > proprietary libc if everyone already has it, but then the the OS vendor
> > > (who stuck everyone with this proprietary libc) can't distribute the
> > > GPLed program.
> >
> > I don't see any reference to OS vendor, whether explicit or implicit,
> > in the language of Section 3 of the GPL. The only distinction on the
> > system component exception is whether the system component accompanies
> > the executable or not: if not, you are excused from including the
> > source code for that component, if it does, you are not excused
>
> It seems to me that you'd call someone distributing major components of
> a proprietary OS an OS vendor. I'm sure you could construct examples
> which are exceptions to that rule. But I made it very clear that I was
> talking informally -- I was talking about the usual case, not trying to
> be so general that I was covering all potential issues.
I still have a problem with your "accompanies" interpretation. I guess that is the
root of our particular disagreement here.
And this makes me reiterate my point made many times before: GPL is drafted very
poorly. You can reasonably disagree on just about anything. Time to clean it up!
Ciao,
Andreas
Reply to: