Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote:
> > > You're claiming here that even though Qt must be linked with
> > > kghostscript that the executing program doesn't contain Qt?
>
> On Mon, Feb 07, 2000 at 05:17:56PM -0500, Andreas Pour wrote:
> > Well, this is funny indeed. When it suits your desired interpretation,
> > you can change words rather freely; yet at other times you insist on
> > strict reading of the words. Although it is obvious, I will repeat
> > myself: I said "executable work", as used in the GPL, not "executing
> > program". The reference to "executable work" in Section 3, which I
> > quoted above, must be the "Program . . . in . . . executable form"
> > mentioned in the beginning of Section 3 (why? b/c the quoted sentence
> > is defining the term). In short, the term refers only to what is
> > being "copied and distributed", rather than what the user ends up
> > "executing". If you read Section 3 with a fair eye I think you will
> > see what I mean.
>
> It's true that you do not have to distribute in object form everything
> that's going to go into the complete program.
>
> However, it's also true that you must distribute the source for the
> complete program.
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'm asserting that kghostscript without Qt is not the complete program.
>
> You do not appear to be disagreeing with me on that point. Instead,
> you appear to be quibbling that the GPL doesn't require that the entire
> executable be distributed.
That for sure it does not -- the only "complete" requirement pertains to source
code.
> > > > 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.
> 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.
> 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
> The underlying idea is that the OS vendor ought to have the capability
> to fix the license on the proprietary libc, but users of that OS wouldn't
> be able to fix the license.
While I may agree that this is a nice theory, it is not reflected in the
language of the GPL. This only goes to prove how poorly the GPL is drafted, as
we can disagree even on this relatively elementary point.
Ciao,
Andreas
Reply to: