Subject: Re: Meaning of "combined work"?
From: "Jonathan S. Shapiro" <>
Date: Fri, 29 Dec 2000 14:18:00 -0500


On rereading your note, I realize that I may have misunderstood your
criteria for DB, and I would like to understand them.

In the Perl/DB context, I can see that the "binding" test is fatally flawed.
If statically compiled, the perl interpreter may incorporate DB and thereby
be constrained, but a perl script that does not call the DB interface should
not be forced to open source by the mere accident of being executed by a
statically linked copy of perl. Indeed, this is something that the script
programmer is entirely unable to control, and I cannot imagine that it would
be your intention to have this case be an issue to the script programmer.

However, I am very surprised that you did not resolve this by using the
"call" rule -- indeed, when I first read your note I took this to be what
you were saying:

> If you **call** the Berkeley DB API

When I first read this statement, I took it to mean "if you (dynamically)
call the Berkeley DB API". Form your subsequent comments I take it that you
meant "if you (staticallly) call the Berkeley DB API".

Can you explain why SleepyCat adopted the position that you did? It might be
informative in the EROS context, as the issues are surely similar. Invoking
a capability protected interface is essentially performing a dynamic call.

Also, perhaps you will be gracious enough to respond to a hypothetical, but
one that might truly arise in EROS. Suppose, using the logic of your Perl
example, that I embed the DB library in a small application that takes the
existing interface and simply encapsulates an instance of a DB database
behind an RPC interface. In point of fact, this would be a very natural
thing for a reasonable programmer to do in EROS, as programs are often used
as objects. The predecessor, KeyKOS, had a "record collection" object of
similar kind.

Under the embedding logic you suggest, it seems to me that the wrapper
program must be open source, but that a caller (which is calling the
container program, not DB directly) would appear to escape the requirement
to distribute under OSD. This is, in some sense, a textbook example of the
issue I am trying to address with the "combined work" rules. Perhaps by
talking through this example we will arrive at a better framing of the EROS

So: how would the SleepyCat rules be interpreted in the EROS context?