Subject: Re: Meaning of "combined work"?
Date: Wed, 27 Dec 2000 11:34:04 -0800
Wed, 27 Dec 2000 11:34:04 -0800
on Wed, Dec 27, 2000 at 10:39:10AM -0500, Jonathan S. Shapiro ( wrote:
> On a completely different subject...
> I would appreciate some help and input from this group concerning the 
> meaning of "combined work" in a component-based system. The context is 
> that I am trying to describe how GPL is to be interpreted in the context 
> of EROS, which is a component system. The issues that EROS raises are as 
> follows:
> 1. Applications tend to be made up of multiple, independently compiled 
> programs (which we call components) that call each other using local 
> RPC. It is not clear when such a collection of components should be 
> considered a combined work. It is therefore unclear when the entirety 
> must be distributed under GPL.  For those of you more familiar with 
> Windows in this context, a reasonable analogy is to imagine a world of 
> COM components in which all components are implemented as out of process 
> servers.
> 2. Because applications can be split into components this way, there is 
> a natural temptation to dodge the bullet by arguing that components do 
> not constitute a combined work.
> 3. Some of the things that collaborators will want to add to the system 
> go into places that are security critical, and I strongly wish to ensure 
> that the trusted computing base remains purely open source.
> Roughly speaking, (1) and (2) are basically the same issues raised by 
> dynamic linking, but the binding between the components is even weaker 
> than the binding provided by dynamic linking. The very notion of 
> combination therefore becomes slippery.
> I have attempted to give a set of yardsticks at
> I would very much appreciate comments, revisions, additions, or 
> criticisms.
> Jonathan

My understanding is that this is an area of open debate.  The issues you
are describing for EROS seem to be similar to those concerning object
broker architectures as well.  This is seen as a potential weakness of
the current version of the GNU GPL and is one of the areas being
addressed in the work leadin to GPL v3.  There's been some recent
coverage of this, I believe it was posted either to this list or the OSI
license-discuss list in the past quarter.  I'd look for clarification
from the FSF and v3 group (if any exists) on this.

Again my understanding, in the case of object broker architectures, is
that the GPL would currently treat object components as separate works,
and that intent is to close this loophole in GPL v3.

A possible out for the *author* of a particular work might be to include
a legal disclaimer, along the lines of the one provided by Linus
Torvalds for the Linux kernel, allowing for linkages to GPLd code in
specific instances.  For the kernel, this is limited to device drivers.

Another out might be to limit the definition of what the work (in your
case EROS) is or what does or does not constitute a derived work.  If
enforcement of copyright law is predicated on the initiative of the
copyrightholder to persue legal protections, then a self-limiting
statement might be a way to go.

The problem with both of the above two options is that while they may
limit the scope of copyright protections as applied to a specific work,
they may limit the ability to use third-party GPLd code in the work.
The development project essentially becomes a code source, not a code
sink, and there is limited ability to leverage external GPLd development
efforts.  While I'd think that this is the case WRT the Linux kernel as
well, it's not a topic I've seen discussed.

Other datapoints might include Sun's licenses.  Their many warts are in
some degree results of trying to address a similar issue -- particularly
interoperability and standards conformance.  Interface definition is
probably most key.  Note also that the FSF exempts functional
incorporation of headers and such from coverage under GPL, provided the
*content* is sufficiently small.  Caselaw may also argue for this, as
copyright law does not provide functional protections.

I'll note also that the question of what constitutes a "computer
program" has been raised in recent discussion, including, IIRC, on the
CNI-COPYRIGHT list, particularly in regard to multimedia works
comprising in part programmatic elements, and questions of whether 17 USC
117 exemptions apply to such works.  The central issue appears to be
defining what a "work" is, and what derivatives or combined works would
be in conjunction with it.  Distinctions seem grey here.

IANAL, this is not legal advice.

Karsten M. Self <>
 Evangelist, Zelerate, Inc.            
  What part of "Gestalt" don't you understand?      There is no K5 cabal

["application/pgp-signature" not shown]