Vicarious liblity (was: KDE not in Debian?)
Raul Miller <moth@debian.org> wrote:
> On Thu, Feb 03, 2000 at 12:38:51PM +0100, Marc van Leeuwen wrote:
> > I maintain that unless the distribution of dynamically linked binaries
> > itself is considered a copyright infringement, there's no vicarious
> > liability either. And to come back to the static/dynamic distinction:
> > an obvious and relevant difference with distribution of statically
> > linked binaries is that the user can execute those without also having
> > the library object file.
>
> Ok, let's pretend for a minute that distributing kghostscript is legal.
>
> What does that mean?
>
> Well, for one thing, it should be legal to make trivial changes to the
> source and redistribute. For example, adding -static to the CFLAGS in
> the makefile and redistributing should be perfectly legal. You've granted
> this right under the GPL.
I'll stop the example here because I think we are talking at cross purposes. I
do not want to discuss whether or not QPL'ed code enjoys the permissions that
the GPL demands for complete sources. Even less do I maintain that one could
distribute Qt with a GPL licence or kghostscript with a QPL licence. And
interpreting the example would at the very least require an interpretation of
"complete source" as defined in GPL section 3 with respect to dynamically
linked executables; I've just discussed that in another message.
The discussion in this branch of the thread (can one say that?) had, as far as
I could see, taken a different angle, namely whether statically and
dynamically linked binaries are different from the point of view of copyright
law, and if vicarious liability play a role there. Your example is too full of
distracting details (and unclear on some relevant ones) to single out those
questions very well. I'll just make this one comment.
If your point is that a distribution that in itself is not infringing on
anybody's copyright, could be considered vicariously liable of such
infringement because, after tweaking the makefile a bit, and then using it to
create an executable that is essentially different from anything present in
the original distribution, recipients could infringe copyright by distributing
that executable, then I must say this interpretation of vicarious liability
seems unacceptable to me. By the same token distributing source code of a very
plain GPL-ed C program would be vicariously liable of copyright infringement,
because (even without changing the makefile) users could compile and link it
on a platform with a proprietary libc, to create an executable, whose
distribution would not only violate the GPL of the C source, but the copyright
of the author of the libc as well. (The point I think should be clear:
creating and running the executable is fine, distributing it is not.) The fact
that the GPL grants you permission to modify and redistribute under certain
conditions does not mean you are allowed to do so if that is illegal for other
reasons.
I'll give an example that illustrates my point clearly, even if it is a bit
extreme. Suppose a company FdSE[*] distributes from its WWW-server a program
QRS in source form with the following copyright notice
Copyright 2000, Fin du Siecle Entreprises
All rights reserved.
Copying or redistributing this software, in source or binary, in original or
modified form, in any form, by anybody other than Fin du Siecle Entreprises,
are NOT authorised, and are prohibited by copyright law.
This prohibition does not affect your freedom to handle this copy in any way
you please within the confines of your personal equipment. See the README
file for some suggestions.
The README file says something like
You can use the C program as test input for your compiler; some dummy header
files are provided for this purpose. You may find more enjoyment however if
you procure yourself the Qt library, which is distributed by Troll Tech
(http://www.troll.no/) and many independent redistributors. If you do not
already have this library installed, but you have Internet connection, you
can achieve this by typing "make download-Qt". Then you can then compile and
link QRS by typing "make with-Qt". If after playing around with QRS you find
you get tired of retyping the same input again and again, you may want to
try adding the marvellous "readline" library developed by the Free Software
Foundation to your program. Again this library is available for free from
many independent redistributors. To make it easy for you, you can download
it automatically by typing "make download-readline". Then you can build a
new version of QRS by typing "make with-Qt-and-readline". Please remember
that while you can play with them as you like, you may not transfer the
resulting programs beyond the confines of your private equipment; you would
be infringing the copyrights of FdSE and others if you did. If you want to
take a copy elsewhere you must transfer a new copy of the sources directly
from the FdSE server and recompile.
This is a beta release. If you have any difficulty compiling or executing
the QRS program, please send a detailed report to FdSE by email and we'll
provide you with a fixed version free of charge as soon as possible.
Obviously, the distribution will not contain a scrap of Qt or readline code.
In fact, if Troll or FSF were to sue FdSE directly for copyright infringement,
they would be surprised to find that FdSE does not even have a copy of Qt or
readline themselves: it is in fact developing proprietary workalikes of Qt and
readline, and using the QRS beta distribution as a field test for
compatibility. So it cannot possibly be held to violate e.g. QPL section 6.
Would a user who installs a QRS executable by committing copyright
infringement? Well clearly he has fetched Qt and possibly readline, so he can
be held to abide by their copyright restrictions, but these do not cover the
actions of linking and executing, despite what the language of for instance
QPL section 5 suggests (since that section is just permitting that which it
could not forbid anyway, it does not really hurt, although it might cause
confusion). In fact QPL section 6 explicitly says: "These [linked against Qt]
items, _when_distributed_, are subject to the following requirements:" (my
emphasis); this is no coincidence, since the requirements would not be
enforceable without distribution. So as long as the user does no distribute
the binaries, as he has been expressly forbidden to, there is nothing wrong
with what he is doing.
So while Troll and the FSF may not like what FdSE is doing, it is neither
infringing their copyrights nor inviting users to do so, and I can see
absolutely no ground why they could sue.
Those who don't agree with me up to this point please stop reading here; there
is no point going on. Those who would argue that linking is a form of
modification, and therefore covered by copyright law, might take a look at
http://cr.yp.to/softwarelaw.html: it has been ruled that patching the software
in Nintendo game cartridges does not infringe Nintendo's copyrights, nor does
selling those patches. I can also not think of a single example where the mere
act of modifying a legally obtained (without shrinkwrap junk) copy of a work,
without public redistribution/performance/display, is not considered fair use;
surely I may tear pages from my own books, or make notes in them, if I like.
So the above being legal, and the distribution by FdSE of QRS-executables
statically linked against Qt and readline certainly not, one must draw the
line somewhere in between (by the way, FdSE could never distribute such
executables, because to avoid any legal trouble they will not touch a copy of
Qt and readline; they could distribute executables statically linked against
their own workalikes, but won't since they want to keep those proprietary).
I can think of two intermediate points (maybe there are more): distributing
precompiled unlinked object files, and distributing dynamically linked object
files. I maintain that both, if achieved without touching Qt or readline,
would be equally legal as the above, and for the same reasons. If both are
real possibilities (and here my technical knowledge fails) this would place
the dividing line between legal and illegal exactly between distributing
statically and dynamically linked executables, proving a point (sort of). I'm
fairly sure making unlinked object files that will properly link after
distribution against the "real" libraries is possible. All that is needed is
to have replacement interface header files with the right function names,
argument types, structure lay-out etc., none of which I think can be protected
by copyright. For the question of dynamic linking I really don't know, because
I don't really know what is done and not done during such linking; still my
guess is that with a very cleverly crafted replacement library it should be
possible to dynamically link against the replacement, and later load with the
real thing. The only kind of thing that would really prevent this is if the
dynamically linked object were to contain a checksum that has to match at
load/execution time, and which is long enough that forging the checksum would
be copyright infringement (how long must a number be to be copyrightable?).
Whatever the verdict may be, the dividing line is either between the unlinked
object and the dynamically linked one, or between the dynamically linked one
and the statically linked one; either way the practical difference is just one
of convenience. But I would prefer the latter, since it corresponds to a
difference that has obvious significance for copyright law: not containing any
part of the copyrighted material or containing a very significant part of it.
What is the relevance of all this for KDE/Qt? I don't know, it was not my
purpose to take position in that matter. But it doesn't hurt to have an idea
of what kind of things can or cannot be relevant.
Marc van Leeuwen
[*] This name is entirely fictitious. No relation with "Fiduciaire du Sud Est"
exists or is implied; in fact I learnt about their existence only by
looking up www.fdse.com after composing this message.
Reply to: