restrictions on web service linking?

[Arnoud Engelfriet]

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.

> The author of FooBar finds out about this, and demands that the one
> distributing FooBar /w libbar.so cease and desist, since his code has
> been incorporated into a whole which includes a part that is not
> licensed under the GPL license (and more so, even incompatible).

Exactly right. Again, assuming the dynamic linking of FooBar
with libbar is a derivative work of libbar. Then the
distribution of these two files is not permitted by the GPL,
since the distributor cannot satisfy the GPL obligations
for the libbar part.

> Either I don't understand the GPL well enough, this isn't possible, 
> I still don't get OSD#9, or, the GPL actually doesn't pass OSD#9 as it
> being currently described.  Thoughts?

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".

The explanation then says "Software linked with GPLed libraries only
inherits the GPL if it forms a single work", which is a confirmation
of the above. It tries to say in lay terms that linked software
is a derivative work of what you link it with. The phrase
"single work" perhaps should be changed to "derivative work".

So: you can't distribute a medium with FooBar and libbar.so 
both on them, because that is a derivative work created outside
the GPL license scope. You can distribute FooBar with bazd, a
server with which FooBar talks SQL over a socket. 

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. 

> I have tried to address this issue with the notion of Dependency, which
> simulates the relationship between an application and a library upon
> which it depends for its normal operation.

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.
If I copy&paste some of your source into my program, I create
a derivative. If I statically link libfoo with my FooBar, I
create a derivative - the executable contains compiled libfoo.

Like I said, arguably the same is true if I dynamically link.
We'll just have to assume it doesn't matter that libfoo
and foobar are different files instead of a single static
binary. 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.

With a server, that just never happens. When foobar talks
SQL to bazd, code from bazd is not combined with code from
foobar. They just exchange messages. Without code being
combined or borrowed, you can't say a derivative work is
being formed. 

Arnoud

-- 
Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/