Subject: Re: derived works (Re: Who holds the copyright?)
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Fri, 19 Nov 1999 18:07:57 +0900 (JST)

I don't expect any immediate answer, unless I wrote something
obviously stupid, in which case a correction would be appreciated.
But I hope these comments will inform Jonathan's inquiries to "those
whose business it is to know".

>>>>> "shapj" == shapj  <shapj@us.ibm.com> writes:

    shapj> [In re defining a work]
    shapj> I'm not entirely clear on the details, but I believe the
    shapj> system call boundary does constitute a work boundary.

OK.

    shapj> 1. It is *intended* as a work boundary.

OK.  BTW: was there supposed to be a "2." here?

    shapj> 3. In proprietary systems, from which the determining case
    shapj> law will have come, the issue is influenced by licenses
    shapj> that specify which pieces of an OS may be redistributed as
    shapj> part of a program without royalty. Given a zero-cost
    shapj> license to distribute, the problem of work derivation
    shapj> largely evaporates.

But the GNU GPL is not a "zero-cost" license to distribute (unless
that's merely an informal wording for "without explicit royalty," but
then I don't see that the problem "evaporates").  If you want to
distribute a derived work, you must contribute it to the community, at
a potentially large opportunity cost in revenues.

So does your argument imply that existing case law will not bear on
the GNU GPL, at least not directly?

    shapj> Case (c) is clearly a derived work, because the statically
    shapj> bound material is incorporated within the work.  This case

This is true for the linked executable.  It is not true for the source
or for the partially linked objects.  I don't think this is a specious 
distinction.

To take a leading case, I don't see that an Aladdin Ghostscript
distributed with a "clean-room" readline implementation (with an
Aladdin-defined API) and a README.Aladdin-Ghostscript+GNU-readline
describing how to link the Aladdin-API-to-GNU-readline interface
distributed with GNU Ghostscript into Aladdin Ghostscript is a derived
work of GNU readline.  It contains _no_ GNU readline code.

It is even legal for individuals to follow those instructions under
the GNU GPL.  And Aladdin should be allowed to distribute GNU
Ghostscript and GNU readline alongside Aladdin Ghostscript (and
README.Aladdin-Ghostscript+GNU-readline) under "mere aggregation" (any
medium containing GNU readline and GNU Ghostscript is of course a
derived work of both).

Given RMS's opposition, it would be cheeky of Aladdin to do so (a la
Abbie Hoffman _Steal This Book_).  But I really don't see where RMS
has a (legal) leg to stand on in attempting to prohibit it.

I don't see how you can argue that the intent is to circumvent the GNU
GPL.  Aladdin has created a satisfactory implementation of user input;
it provides and the Makefile links that as the standard.  I believe
that the Ghostscript-to-GNU-readline module is a user contribution,
and it certainly could be---I independently thought of it but didn't
contribute it because when I looked, it already existed.  :-)

I think it is entirely in the spirit of free software to point out
that there is a better way of inputting to Ghostscript that Aladdin
cannot distribute, but you can build and use in the privacy of your
own workstation (but not distribute).  Given the existence of the
Ghostview/gv GUI, I see no reason why Aladdin should develop a better
CLI, but I think it's really nice of the Ghost to inform me that I can
add one with very little trouble.

It is of course an attempt to circumvent RMS's overall strategy (make
it as hard as possible for people to use free software and non-free
software in the same application) for encouraging broader adoption of
free software, of which the GNU GPL is a part.  But IMO that is
separate from the issues of free software and the restrictions
inherent in the GNU GPL itself.

    shapj> is usually addressed by license (as noted above). Because
    shapj> it is covered by license, statements by RMS about glibc are
    shapj> relevant.  To the extent that RMS speaks for FSF he has the
    shapj> authority to grant you the right to redistribute.

I'm not contesting that statements of the copyright holder bearing on
his or her intention are relevant; they are.  I'm asking whether RMS's
statements about the GPL in general bear on Linus Torvalds's work.  I
believe they do not, except as they are informed by the actual law.

    shapj> Case (a) is clearly NOT a derived work, as there is no
    shapj> incorporation of content as a result of the binding, and

Not clear to me.  They must be physically contained within a single
medium, the virtual memory of the host, otherwise the program cannot
run.  Sounds like a single work has been assembled to me, at least as
one of the eight things the Red Queen assigned me to believe before
breakfast.  Especially by analogy to a shared dll, see comment on 2)
below.

Of course, I stipulate that "exec is a work boundary" is a
well-established precedent, and logic, however valid, will not be
allowed to overturn it.  (Ie, in court.  This is a good thing; once a
rule becomes established, it should only be changed by explicit
legislation.  Otherwise FUD and the deeper pockets rule.)  But the
logic of denying that copying has taken place is not completely
convincing to me.

    shapj> the intent is that the operating system and application are
    shapj> separate.

So the only way to justify the work boundary here is on the basis of
intent (and precedent) AFAICT.

    shapj> Case (b) is currently ambiguous. I do NOT know the case law
    shapj> but I believe that libraries bound intentionally by the
    shapj> application at runtime are clearly derived works, because
    shapj> the perform an act of incorporation by the act of
    shapj> binding. This might be altered by law concerning
    shapj> interfaces; I shall try to find out. 

I think this has to be the critical issue.  See the comment on 4)
below.

    shapj> The question then devolves to dynamic libraries such as
    shapj> libc.so.  I believe that the following line of argument
    shapj> would prove compelling in court:

I think it can be attacked at multiple weak points.  :-)  I suspect
your argument is precisely the advice that RMS's lawyers have given
him, so I don't have all that much confidence that the attacks would
be successful in a court challenge.  I do think they introduce a lot
of fear, uncertainty, and doubt about whether one could successfully
prohibit dynamic linking of GPLed libraries to proprietary works, at
least for those libraries that are alternative implementations of
other works that do permit such linking.

Given the current behavior of Debian (turning practically everything
in GNU/Linux into a raft of dll's plus small executable wrappers) and
the fact that XEmacs can (at least in principle, don't know if current
versions actually support this although the Makefiles claim to) be
turned into a dll and linked into an Xt application as a widget, the
implications are staggering.  (Or maybe _I_ am, though I haven't had a
drop to drink yet today.  :-)

    shapj> 1) Linking of static libraries creates a derived work.

OK.  Logic and clear precedent.

    shapj> 2) Dynamic libraries are simply a mechanism providing a
    shapj> more efficient means of accomplishing what static libraries
    shapj> accomplish.

False, I believe.  For one thing, an analogous argument would make
every academic paper which uses language like "the remainder of this
proof can be conducted exactly as the proof of Theorem 3.2.A in
Turnbull and Shapiro [1999], substituting X for Y throughout" a
derived work.

More specifically, you should[1] be able to do the following:

# copying libGNotif.so into memory
$ LD_PRELOAD=/gnu/lib/libgnotif.so xemacs &
# clearly legal based on my OSF license
$ LD_PRELOAD=/usr/lib/X11/libXm.so MSIEforLinux &
# look ma, no copying!
$ LD_PRELOAD=/gnu/lib/libgnotif.so MSIEforLinux &

So dynamic libraries do a lot more than merely make linking efficient,
and they need not involve physical copying.  Certainly not of any
given work.  Also consider the use made of dynamic libraries in the
"plug-ins" common in multimedia programs and web servers, where
basically you incorporate a whole external program into a given
application.  How do you distinguish in practice between the
traditional "libdl.so as efficient ld" and this new "libdl.so as
efficient exec" approach?  It makes it hard to see how either the
libdl == ld argument or the libdl == exec argument takes precedence.

The above example also makes it clear that to claim that dynamic
libraries involve implicit copying opens up a can of worms regarding
the philosophical foundation of the "exec doesn't create a derived
work" argument.  (I still stipulate that precedent and intent will
rule on that.)  The point is that the alleged copying process does not
own the space where the dll lives, it is granted access to it by the
OS---just as in exec'ing a separate program (to which could offer
shared memory for IPC, to muddy the water still further).

    shapj> 3) The introduction of a mechanism that sidesteps the
    shapj> literal intent of the law on a technicality generally does
    shapj> not confer immunity from the intent of the law.

Stipulated.  IANAL.

    shapj> 4) The program, in the absence of the dynamic library, is
    shapj> useless; it is clearly shipped with the intent that its
    shapj> execution will bind these libraries, and therefore with the
    shapj> intent that the resulting executable is a derived work.

False.  See 2) above.  It must bind _some_ dynamic library (even this
is untrue for plug-ins), but it need not bind a _given_ work
implementing the .so's interface.

This is not to deny that in a given case, where there is only one
implementation of the interface in existence, or where all
implementations are encumbered (eg, by a patent---although that's a
whole different mare's nest), such intent could be demonstrated.  But
it's not prima facie.

    shapj> 5) A derived work has therefore been created. The question
    shapj> is whether it is created by the user or the program author.

Derived, maybe---but from OSF Motif or from GNU GNotif or some as yet
unwritten implementation of Motif?  How do you argue that dynamic
linking makes a program a derivative of a library that did not exist
when the program was written?  (Eg, hello.c when linked to a
hypothetical GNU GPLed glibc.  Yes, I know about crt1.o and friends,
so you might be able to get me on that.  Suppose they didn't exist, or 
were specified in POSIX and provided by the OS kernel distribution?)

The point is that as long as there is an alternative implementation of
the library that the user could theoretically be licensed to use, the
vendor of the program is delegating the choice of implementation to
the user.  I don't see how you can legally stop the user from
performing the dynamic link to the GPLed implementation, or to any
implementation to which they have a valid license, and it is the
user's choice.

    shapj> 6) The program, by invoking libdl.so, is performing an
    shapj> action not controlled by the user.

All decent systems today put the lie to this.  Eg, one of the most
important Linux applications in Japan is "Muriyari[2] Netscape."  It
functions by preloading certain internationalization functions as a
dll, turning on the ability to talk to the external input methods
without which it is impossible to input Japanese in X11.  Same
Netscape binary you can download from Netscape.com; the magic is all
in the dynamic linking.  The decision to use Muriyari Netscape is a
user decision; it is still possible to use the standard Netscape.
Given Muriyari's propensity to crash, I know a number of people who
search and shop in Muriyari, and browse in the standard one---the
dynamic linking really is under conscious user control.

Of course, users rarely consciously use such control.  Is that a
legally compelling argument?


Footnotes: 
[1]  Of course the syntax would be different on non-Linux systems.
And you actually can't in the case of Motif AFAIK because of
differences in function vs. macro implementation, but this kind of
thing is definitely possible with the various Athena-widget-alikes.

[2]  "Abuse it 'til it works."  Ie, mung.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."