restrictions on web service linking?

[Clark C. Evans]

On Tue, Nov 21, 2006 at 08:53:47PM +0100, Arnoud Engelfriet wrote:
| Clark C. Evans wrote:
| > Then, one day, another person makes a different distribution of the
| > systems which causes FooBar to come configured to run with libbar.so
| > instead of libfoo.so (via a copy, symbolic link, or any other system
| > configuration at install time) as the FooBar author had anticipated.
| 
| If we assume dynamic linking is creating a derivative work,
| then that's not allowed. A derivative of GPL and oldstyle-BSD
| code cannot be distributed.

I think you're forgetting *when* the derived work is created.

| 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 kinda read OSD#9 more literally, that it doesn't place restrictions on
other software it is distributed along with.  That is what it says anyway.

Regardless, neither the dynamic linking case of the GPL nor the depend
license I'm proposing have a problem here, since the derivative work
does not yet exist at the "time of distribution" it isn't an issue.

This is why I don't see a problem with OSD#9 and what I'm trying to do.

| It seems that you see little to no difference between dynamic
| linking and your RPC/socket/pipe interface to other code. I
| agree that the boundaries may be blurry, but that's the distinction
| that I think is implicitly drawn in OSD 9. 

Correct.  I think that derivative work could easily be an artifact that
span multiple servers in different timezones, etc.  I mean, there is no
reason why you couldn't perform a symphony over the phone lines right...
although you'd have to work on your synchronization some.  Such a show of
talent should certainly be copyrightable, no?  Perhaps one that is
derived by the musicians' individual performances (and those are derived
from the score) as combined by the phone network.

| But the criterion for "derivative" is not "depends/needs the
| other work". Legally speaking something is a derivative if
| it incorporates all or part of the other, preexisting work.

Well, in my view, "performances" are either intimate (cause a dependency
which is important since it would prevent one of the participants from
operating independently), or casual.  Casual performances do not
cause dependency, so they should not result in any restrictions.

However, if one component simply cannot operate without another... it is
a completely different matter.  This the case I'm talking about.  It may
not be detect this case via a computerized algorithm, however, when
presented to a Judge, I think the distinction would quickly be obvious
(and would develop case law that clarifies the intent, if you didn't
include explicit examples in the license itself).

| Somewhat strained maybe, but in any case when I
| execute foobar, at some point code from libfoo will enter
| into foobar's address space. So at that time the derivative
| is certainly formed, as code is copied from libfoo.

Strained?  I'd say incorrect.  As I understand operating systems this
isn't how it works.  Consider the case where I'm running bing.exe with
shared library foo.dll.  So far so good the code for bing.exe and
foo.dll are happily in memory.   Now I load whap.exe which is also
linked to foo.dll, only... when I do this, another copy of foo.dll is
not in fact copied.  The currently loaded code is reused, or at least
that is how I understand it.

When one says that a library is "loaded into one's address space", your
talking about the library's code operating on a shared data segment...
so, you can think of it as a shared "performance". However, I don't
think it is shared "code". 

Of course, I'm not a systems programmer, I only write database
applications and don't even have a computer science degree ;)

Cheers!

Clark