This is an expanded version of my original response to this
message. Andreas indicated that he didn't understand why
what I was saying was significant.
On Mon, Feb 07, 2000 at 07:10:32PM -0500, Andreas Pour wrote:
> > 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.
The GPL uses the term "module" exactly once, and "component" and
"components" once each. Here's the paragraph where this happens:
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. 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.
Note that this paragraph follows a couple clauses which require the
complete corresponding source code for an executable before you
can distribute the executable:
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
...
If you bother to read that, you'll see that
(*) The source code must be complete.
(*) The source code must correspond to the machine code.
(*) Source code must be provided for every piece of the
program.
(*) There's a special exception for a proprietary libc if that libc
accompanies a major "component" of the operating system which is not
distributed with the GPLed program.
The requirement that the source code must be complete conflicts with the
idea that you can distribute a working copy of kghostscript yet fail to
distribute all the source code for a working copy of kghostscript.
I suppose that Andreas imagines that kghostscript being split up
into multiple files somehow makes a difference.
So, when Andreas says:
> 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.
I must assume that he's misread the GPL, because libc is not a "component"
in the sense that the GPL uses the term.
And (looking at the phrase "GPL'd component") the way the GPL uses the
term, a "component" wouldn't be licensed under the GPL.
In the terms of the GPL, a proprietary libc would be an "anything" that
is normally distributed with a major component of the operating system.
There's really no point discussing the logic of this sentence that
Andreas wrote -- it just plain doesn't relate to the GPL in any
meaningful fashion. If I rewrote it so that we called libc a "module"
which accompanies the GPLed module inside the executable, then the
sentence would make sense. But in that case it doesn't make any
interesting points...
Andreas goes on to say:
> 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
I have no disagreements with this, and am only quoting it so that
Andreas can't claim that I've ignored it.
> 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.
Likewise I have no problem with this as a definition.
> 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.
No problem there. But why would this be relevant, and to what?
The answer to that question seems to reside in Andreas's confusion
about what a "major component of the OS" is that the GPLed program
must not accompany for that special exception in the GPL to be
applicable.
> 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.
This is correct up till that last sentence. The GPL requires that
the major component (compiler, kernel, ...) does not accompany the
executable. It does not require that that part of the program not
accompany the executable. There's nothing in this paragraph (it's the
first quote from the GPL near the top of this message) that indicates
that you can't ship a working executable.
[I pointed this out in a previous message, and I assumed that Andreas
had bothered to read it (since he replied to that message). However,
in the interest of not being curt I'm repeating this point here.]
> The problem with your reading of accompany is that a lesser cannot
> accompany a greater.
I ignored this since for it to be relevant it must mean that
libc cannot accompany a compiler. So this sentence must either
be false or irrelevant.
[I don't see why should I waste time on this preposition when the
previous prepositions were obviously false. A very careful reading of
Andreas' message might imply that he somehow thinks >>I've<< asserted
this false-or-irrelevant statement. If that's the case, he's worded his
argument very poorly -- if nothing else, he's not quoted anything from
me that would support his idea that I said any such thing. Anyways,
since he doesn't come out and say that this is what I said it's probably
not worth wasting time arguing against this implication that he never
actually came out and said.]
> 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.
This seems irrelevant to the current discussion (or should I say
"non-sequitor"?).
> 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
Andreas didn't bother finishing his sentence, and I'm going to
limit myself to responding to what he actually said.
(1) I see nothing in my interpretation that distinguishes between
static and dynamic linkages.
(2) I don't see how my interpretation let's an OS Vendor distribute
the GPLed program -- essentially, the OS vendor must make sure that
they never distribute the GPLed program with the OS. If they ever
do, they lose all rights to distribute the GPLed program. So they
have to set up a distinct distribution channel for the GPLed program.
Which is roughly the same thing as saying that the OS Vendor isn't
distributing the GPLed program.
As an example of this, consider the web site: www.sunfreeware.com.
You can find GPLed programs on this site, which are precompiled for
running under Solaris. Yet, for some reason (guess what it is...)
you can't order any of those programs directly from sun.
> 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.
Once again, Andreas misses a most important point of that exception:
libc (whether libc-for-GPL-progs or libc-for-other-progs) must accompany
a major component of the OS: basically, that's either the compiler or
the kernel. So he's imagining this "loophole" where a company goes
to a lot of extra work to come up with a duplicate libc, but for
what? His loophole doesn't even relate back to the terms of the GPL.
A reasonable person might have come to expect this flaw in his logic
from my earlier message (where I pointed out that his reading of that
exception clause of the GPL was false).
> 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.)
As I pointed out earlier, it's the major OS component (kernel,
compiler,..) which can't accompany the GPLed program. This means that
the GPLed program can't be distributed in a way that ever lets the GPLed
program be distributed with the kernel (or compiler). Because otherwise
the OS Vendor would lose all rights to distribute the GPLed program.
Notice that "dynamic linking" doesn't even enter the picture.
> > 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.
I don't think that we're disagreeing about what "accompanies" means.
I think we're disagreeing about what it is that can't accompany the
GPLed program.
> 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!
I must say that it appears to me that your understanding of the english
language is what's at fault.
--
Raul
