restrictions on web service linking?

[Clark C. Evans]

Hello John.  Haven't written to you since the good old xml-dev days, I
hope things are well and such.

On Wed, Nov 22, 2006 at 03:13:08AM -0500, John Cowan wrote:
| Even so, AFAIK most databases are accessed using a linked library,
| even if the database product itself runs in a separate process;
| the client-side library handles communication with the database.
| That returns us to a derivative-work situation.

Well, from my perspective there are far too many ways to work around
this sort of situation; it also has a simple work-around that uses an
intermediate stub.   *sigh*


On Tue, Nov 21, 2006 at 04:11:57PM -0500, Matthew Flaschen wrote:
| Arnoud Engelfriet wrote:
| > What OSD 9 tries to do is draw a line between derivative works
| > and "other works". A license can put restrictions on derivatives
| > but not on those "other works".
| 
| I agree completely here.  Based on the rationale ("Yes, the GPL is
| conformant with this requirement. [...]") and the fact that the GPL was
| around before the OSD, I think OSD 9 is meant to stop about where the
| GPL does. 

I think we're caught up on derivative works still.  Could we dismiss
this sub-topic, for now, by considering the Depend proposal as a limit
only on *use* of my software.  I've asserted earlier that this limit
would certainly not prevent its distribution with other software.

Or almost equivalently, could I ask that OSD#9 restriction be taken off
the table, for now, so that we could work out exactly what is so special
about this particular boundary?

} Where then, does the GPL stop (in restricting third-party
| software)?  It could be clearer but again the sentence "Thus, it is not
| the intent of this section to claim rights or contest your rights to
| work written entirely by you" essentially means non-derivative works can
| be distributed alongside the GPL under proprietary/incompatible licenses.

Yes, but the GPL goes on to talk about "But when you distribute the same
sections as part of a whole which is a work based on the Program, the
distribution of this whole must be on the terms of the License".   While
the GPL triggers on "distribution", which just won't work given your
interpretation of "derived work", the limiting word, in my mind is on
the word "whole" - as in "complete system".

I see my application as merely a component in a larger system that
consists of a database.  I define the word "whole" to include, at run
time (not when making a CDROM distribution, for example) as including
the database to which it is intimately connected and dependent upon.

| Clark, you're right in saying no one knows for sure whether dynamic
| linking forms a derivative work (it probably depends, and courts will
| probably eventually clarify this).  I think OSD 9 allows the GPL
| regardless; it does this by allowing any derivative (single) works to be
| restricted.

Given the "up in the air" nature of this boundary based on the current
legal interpretation of "derivative work", don't you think that a more
theoretical boundary would be appropriate -- one that stands on a moral
principle rather than a legalistic determination?

| Thus, the GPL complies with OSD 9 because it does not attempt to
| restrict software that clearly doesn't form a derivative work.  The
| Depend clause does attempt to restrict such non-derivative software, and
| so is non-compliant.

If worded as a restriction on use (and not on distribution) it would
not, as I contend, violate the letter of OSD#9 since it would not
prevent distribution on a CDROM of my work and that of a proprietary
database, such as Oracle.

You may still argue that it violates the spirt, that I'm limiting the
use of "other works".  But I wish you to consider this limitation 
regardless, since it only limits the ability of the other work to be
arranged with my work to make a "whole system" under a very limited
sort of interaction that is not typical when using programs together.

| I believe it is already overwhelmingly clear that this relationship
| is insufficient.

In this case, I'm willing to Gamble.  If you see nothing wrong with the
boundary being drawn by the limits of "derivative works", then the OSI
should approve my clause (after further work) but simply mark it as "not
recommended", with a particular note that you believe that the license
is not enforceable.   We can then leave it up to the *law* to draw the
boundary, as you suggest.

| However, as Arnoud stated, none of the creative work
| (code) is shared between the client and server; thus there can no
| copyright derivation.  That is partially why OSD #9 exists, and why I
| still think we have to reject this clause.

Otherwise, could we consider a Depend license based on usage, where we
find a better moral/theoretical basis for where to draw this line (which
I agree should be drawn, and should be quite close to the covered code).
I'd ask that you keep an open mind in this case.

The advantage of this approach is that it prepares us for the future; if 
it turns out that "dynamic linking" is not enforceable distinction for
the creation of a derivative work, we then have this prior work upon
which to justify a boundary based on other rationale.

That said... I'm off for Thanksgiving.  It has been delightful
conversation so far.  I hope that a few days of thought will give
us time to think about this a bit more.

Cheers,

Clark