Re: On interpreting licences (was: KDE not in Debian?)
> On Thu, Feb 10, 2000 at 12:53:02PM -0500, Raul Miller wrote:
> > > > Either the program uses readline or it doesn't. If it does use readline,
> > > > and it's distributed with readline, then, strictly-speaking, it contains
> > > > readline.
> >
> > > I disagree.. If it was not built using one piece of readline (ie, none of
> > > readline's headers) it does not contain readline until it is run.
> >
> > The GPL doesn't say that a program has to be built using headers.
On Thu, Feb 10, 2000 at 06:41:11PM -0800, Joseph Carter wrote:
> You're right, it doesn't. I just don't see how the GPL has the right to
> affect use of the software (as opposed to development) given that use of
> software is beyond the GPL's scope.
>
> The GPL has no power to apply to non-GPL'd works which are not derivative
> in source or binary form from GPL'd works. We have already established
> this as true else the GPL would have failed the DFSG.
Are you claiming that a working copy of kghostscript is an example of a
non-GPL'd work which is not derivative in source or binary form from GPL'd
works?
If not, what relevance is the above line of thought?
> In order for you to apply the GPL's terms to this hypothetical program
> you must first establish that a derivative work is being distributed.
> In the case of a GPL'd KDE app that's easy. In the case of an app
> linked against GPL'd headers, that's easy again. An app which is not
> GPL'd and does not fall into either of the above categories is a bit
> more difficult---I don't see the derivision.
The distinction between compile time and run time is artificial -- it's
technology dependent. Build a new language, or maybe a new environment,
and you have a new set of distinctions to work with. There's nothing
fundamentally relevant to copyright law in this sort of distinction.
If you somehow manage to decide that you have a way of coming up with
a working copy of a program which is never distributed, you could apply
the same underlying principle to any other copyrighted work.
If a work only exists when the program is running, but millions of copies
of that work exist in the hands of millions of users, do you really think
that a court of law would accept the sleight of hand argument that those
copies were never distributed -- that they "just happened" to spring into
existence, by coincidence?
> > Your claim would mean that if, for example, I use a hex editor on a program to
> > alter the libraries it uses, that I would be able to build programs that
> > are built on GPLed code but which aren't bound by the GPL.
>
> I may not fully grasp the connection here, so let me extend this example
> to be sure I do actually understand your point:
>
> Instead of very late binding as mentioned previously, you would use late
> binding (ie, dynamic linking) by #include'ing say <myreadline/readline.h>
> or whatever files and have -lmyreadline in the makefile's LDFLAGS...
>
> This would produce a program linked against libmyreadline.so which happens
> to share GNU readline's ABI. Then to make it instead use GNU readline you
> would modify it such that ld.so would load the equivalent libreadline.so,
> much as I modified the pre-source release glquake binary to use libGL.so.1
> in place of libMesaGL.so.2.6..
>
> You are saying that this would not sit well with the GPL on GNU readline
> and be considered infringement. You might be right---I could not even
> begin to guess at how this would be handled. It's IMO right on the
> borderline and without a legal decision (it wouldn't have to be case law
> necessarily as this discussion is academic more than it is legal being
> that we're not lawyers) I'd say it's too close to call. If you've got a
> reference to a decision I'd love to read it though.
Making the modification is fine as long as you don't go about distributing
the result. If you're distributing lots of these the technical
details about how you did it are irrelevant. The point is that you're
distributing modified copies. The details of how you accomplished the
modifications are irrelevant.
[Unless you accept the idea that you can build technology to build distribution
channels which are beyond the reach of copyright law.]
> In the case of very late binding, it seems to be a little bit past
> that line IMO.. I think it would have to be decided by a judge on
> a case by case basis until there was some case law which firmly
> considered very late binding to be the same as dynamic binding (which
> clearly is the same as static binding because of the GPL'd API and the
> ABI symbols read from the shared object library..
If a document only exists when it's being displayed, but millions of users
get a copy of that document, would copyright law apply to it?
> I am curious how you think the BSDish readline would stack up in these
> examples. The BSDish readline replacement uses the name libreadline.
> It also places its headers in where GNU readline would. Essentially,
> they are two different libraries which do share a common interface
> in terms of API, ABI, and soname. I believe it can even be built as
> a wrapper for the BSD equivalent of readline to provide almost full
> feature compatibility.
I think it matters which one is being distributed.
Distributing the BSDish version and letting people swap in the GPLed
one is very different, legally, from distributing the GPLed one.
> This is a case where there are two alternatives for a library. One
> is GPL'd and is usually found on Linux systems, the other is not and
> _can_ be found on Linux systems but probably wouldn't be. It may or
> may not be found on other systems.
Being found doesn't matter -- if the distribution channels are truly
independent. But for Debian, for example, it matters what Debian is
distributing.
> > > The GPL can't control usage, only distribution.
> >
> > True. Which is why I pointed out that it matters how the program is
> > being distributed.
>
> Agreed.
>
> > > I am of the opinion that static vs dynamic linking is irrelivant
> > > because in Qt's case the inclusion of Qt happens before linking.
> >
> > I'm of the opinion that it doesn't matter because working copies of
> > the program are being distributed, and those working copies contain
> > both QPL and GPL licensed code.
>
> Even in a late binding situation the ABI symbols and headers are
> linked in. If you replace the headers you still have the symbols. If
> you replace the shared lib, well you have a more complex situation.
> libGL for example, if the API and ABI are the same for all Linux GL
> implementations, the fact that some of them may be under the GPL or
> other licenses cannot force binaries built against the generic API/ABI
> to be GPL'd. That'd just be seriously overreaching.
Once again: it's what's being distributed which matters.
> > The GPL doesn't care how the program is built -- that's not
> > something that matters to the GPL.
>
> Agreed. However the GPL has no say (whether it would care or not) if
> there is no derived work being distributed. It seems that very late
> binding would screw that up because there is never a derivision, not
> even headers or symbols.
Late binding is a form of compression. It's not the same kind of
compression as gzip, but you can easily build a decompression utility
which pulls big chunks of bits from referenced material.
Any copyright protection you get from late binding must therefore also
be available to anyone using an appropriate compression mechanism.
--
Raul
Reply to: