Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote:
[ ... ]
> 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.
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
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.
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.
(3) to be equal or equivalent to; as, a gallon *contains* four quarts;
Now, please explain how the "executable work" which I am distributing (kghostview
which is dynamically linked to Qt) "has in it", "holds", "encloses or includes",
"has the capacity for holding", or is "equal or equivalent to", the Qt library.
Sure, the Qt library can later be added to it -- like sugar to the gallon of water
-- but is not contained in it. That's why when you distribute a dynamically-linked
kghostview you don't have to distribute Qt source code. Now of course this
executable work no more contains Qt if it is distributed on the same CD. (However,
in case it is on the same CD, the "special exception" would not apply.)
If you don't like that result, I suggest you talk to FSF about changing the
language of the GPL.
> (*) The source code must correspond to the machine code.
> (*) Source code must be provided for every piece of the
> program.
Of course this depends on how you define program. As Section 3 defines it,
"Program" is the GPL'ed work, and "work based on" the Program would be kghostview
(but not Qt, since that is not a work based on ghostview). If this is confusing,
bear in mind that the "Program" refers only to source code -- the ghostview code in
the example is source code, and it has been modified by adding some more code, but
Qt has not been added to it. For copyright purposes, kghostview source code is not
a "derived work" of Qt, any more than the Yahoo directory is a derived work of the
Internet.
> (*) 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.
Lbc *is* a "major component" of the OS.
> 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.
Two flaws in this analysis. First, you don't have to distribute a working copy of
kghostscript; in fact it would defeat the idea of dynamic linking to do so.
Kghostscript will not work w/out libc, libstdc++, libX and a bunch of other libs
which generally are distributed separately, unless of course you are the OS
vendor. In case you are the OS vendor, of course, you are subject to the
exception.
Second, insofar as you do not distribute a "working copy", you don't have to
distribute the source code to the working copy. The source code, as I quoted
above, is only to the executable work you are distributing. That's why if you
distribute just, say, The Gimp, you are under no obligation to make the X and libc
source code available (in case you want to argue that you are, then I will point
out then that virtually *everybody* violates the GPL, w/out protest from the FSF,
and that's been going on since the GPL was first released, so its a pretty
untenable argument).
> I suppose that Andreas imagines that kghostscript being split up
> into multiple files somehow makes a difference.
Of course it does! That is an aspect of copyright law you may not like, but
copyright law deals in terms of "works", and yes, "works" can be split up by the
author.
> 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.
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"? If "component"
was meant to refer only to applications, rather than libraries, it should have said
so (i.e., used the term "major applications" or "major non-libraray components".
And in any event we both know that the application itself (even a compiler) need
only be a two-line program:
main(int argc, char** argv)
{ libfunc(argc, argv); }
And everything else can be in the library; the only point of an application is to
provide an entry point for the system loader. So I do not see the distinction b/w
library and executable in the term "component".
> And (looking at the phrase "GPL'd component") the way the GPL uses the
> term, a "component" wouldn't be licensed under the GPL.
Actually, all it says is that you don't have to distribute the "source code". It
doesn't say anything about not having to be licensed under the GPL. If in fact
Section 2(b) requires you to license the full source code under the GPL, this would
apply to the "component" as well -- the "special exception" only relieves you of
the obligation to distribute the source code, not of any other obligation the GPL
has with respect to that component. If in fact the GPL meant to relieve you of all
obligations w/r/t the component, it should have read:
However, as a special exception, the obligations of this License, including
the obligation to distirbute source code, do not apply to 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
More proof for my contention that Section 2(b) does not require the entire work to
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.
Or it could be a "major component" in its own right.
> 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...
Just to drive home the point, I looked up the definition of "component" in
Webster's (same edition as last time):
"a part; a constituent; an ingredient".
Now, can you seriously argue that libc is not a "part" or a "constituent" of the
OS? Of course not. Now, can you seriously argue it is not a "major" part? Let's
see, given the history of how long it took to write libc, and its size (4MB binary
vs. 1.5MB uncompressed binary for the Linux kernel and 3.2MB binary for cc1 and
cc1plus combined), I think it's pretty impossible to say it's not "major".
Hence, if libc is one of the "major components" of the OS, and it is distributed
with the GPL'd executable, the exception does not apply.
> 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.
Right, and why am I "confused"?
> > 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.
Not sure your summary makes sense. But in any event libc does accompany the
executable, in your statically-linked GPL code/proprietary libc hypothetical.
> It does not require that that part of the program not
> accompany the executable.
Not following that sentence.
> 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.
Of course you can, but only in compliance with the terms of the GPL.
> [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.]
Thanks :-). Perhaps I did not agree with you any more then than I do now :-).
>
> > 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.
That sentece was not directed at the compiler issue. Rather, you had questioned,
as quoted at the top of this e-mail, "What does it mean for a program to accompany
itself?" This question was in reference to my assertion that libc accompanies the
GPL'd program when statically linked. So I was demonstrating how a proprietary
libc would "accompany" the GPL'd work. Perhaps I misunderstood your question, feel
free to clarify what you were asking if that is the case.
The reason I complain about your curt posts, Raul, is that they lose context. Just
to be clear, I am quoting the exchange leading up to your question, using '#'
instead of '>' for quoting and "A:" to designate my comments and "R:" to designate
Raul's:
A: # # # # # # The next sentence reads:
A: # # # # # #
A: # # # # # # However, as a special exception, the source code distributed
need
A: # # # # # # not include anything that is normally distributed (in either
A: # # # # # # source or binary form) with the major components (compiler,
A: # # # # # # kernel, and so on) of the operating system on which the
executable
A: # # # # # # runs, unless that component itself accompanies the executable.
R: # # # # #
R: # # # # # Ok, so you are aware of the part of the GPL which lets the proprietary
R: # # # # # libc be used.
R: # # # # #
A: # # # # # # This sentence can easily be read to support the dynamic/static
A: # # # # # # distinction.
R: # # # # #
R: # # # # # Eh? You can link the proprietary libc statically and this special
R: # # # # # exception would still be just as applicable.
A: # # # #
A: # # # # No, it would not, b/c then you would actually be distributing the
A: # # # # executable proprietary libc, and the next clause kicks in (the
A: # # # # exception ("unless . . .") to the special exception) to require the
A: # # # # source code to be distributed for the libc part as well.
R: # # #
R: # # # Yes, you would be distributing the proprietary libc. But that's legal
R: # # # if (1) the libc would also be distributed with a major component of the
R: # # # operating system, and (2) that major component of the operating system
R: # # # would not accompany the GPLed executable.
A: # #
A: # # Right, but if it's statically linked by definition it does accompany the
A: # # executable.
R: #
R: # "it" meaning the GPLed program?
R: #
R: # If so, why do you use the phrase "accompany the executable"? Aren't you
R: # talking about the executable of the GPLed program?
R: #
R: # What does it mean for a program to accompany itself? Why do you raise
R: # this point?
So obviously the debate we were engaged in was whether a libc statically linked to
a GPL'd program "accompanies" that program. My point, in the e-mail you were
responding to, was to claim that it does. Somehow, you turned this into meaning
(quoting from you right above):
R: I ignored this since for it to be relevant it must mean that
R: libc cannot accompany a compiler. So this sentence must either
R: be false or irrelevant.
That is precisely why I get frustrated debating with you. How does my line or
arguing conceivably lead to the conclusion that for it to be relevant "it must mean
that libc cannot accompany a compiler"? My arguments, quite to the contrary, would
imply that it is possible.
It seems perhaps that our real disagreement, and the cause of a few
miscommunications, is whether libc is a "major component" of the OS.
[ ... ]
> > 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.
Well, if you now agree that a statically linked libc *does* accompany the GPL'd
executable, then we can get back to our prior point in the debate. The quetion
was, can (under your reading of the GPL) a GPL'd program be distributed statically
linked to a proprietary libc. For brevity, I will refer to the scenario of
distributing a GPL'd program with a statically linked proprietary libc as the "Libc
Hypothetical". The relevant sentence is:
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.
You now agree that libc "accompanies the executable" in the Libc Hypothetical. So,
we are at the point now where you could not distribute the Libc Hypothetical if
libc is a "major component . . . of the operating system on which the executable
runs". I think that is the last outstanding issue, please correct me if I have
missed something.
I think I argued above why I think libc is such a major component. I will not
repeat those arguments here. In the end you may not agree with my arguments, but
certainly you must concede that a court certainly could. That is why I keep
raising the point that the GPL is drafted poorly and needs to be rewritten.
> > 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.
Are you stripping "and so on" from the GPL? The list of compiler and kernel is
exemplary only; by using "and so on" it is not at all an exclusive list and you
really have to look back to the defining term, "major component". This issue -- of
whether an enumerated list following a general concept is exclusive or illustrative
-- actually arises in legal documents quite a bit. To me, throwing in the "and so
on" is equivalent to adding "without limitation" to after "including". To
illustrate:
Currently written:
the major components (compiler, kernel, and so on) of the
operating system
Equivalent:
the major components of the operating system, including
without limitation the compiler and kernel
To be contrasted with:
the major components (compiler, kernel) of the
operating system
Equivalent:
the major components of the operating system, including
the compiler and kernel
In the latter two examples, there could be debate whether compiler and kernel are
the only ones implicated; in the first two examples, there cannot be.
To me there is overwhelming evidence that libc is a "major compoenent" of the OS,
so much so that I think you need a "desired result" approach in order to disagree
with that.
> 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.
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. The reason the "special exception" does not apply in the Libc Hypothetical
is b/c the "unless" clause kicks in when the component accompanies the executable.
[ ... ]
> I must say that it appears to me that your understanding of the english
> language is what's at fault.
I have an excellent grasp of the English language and excellent reasoning skills,
but thanks for asking.
Ciao,
Andreas
Reply to: