restrictions on web service linking?

[Clark C. Evans]

On Tue, Nov 21, 2006 at 08:06:42AM +0100, Arnoud Engelfriet wrote:
| Clark C. Evans wrote:
| > On Mon, Nov 20, 2006 at 11:42:49PM +0100, Arnoud Engelfriet wrote:
| > | OSD #9 says that you can impose restrictions on derivative works
| > | of your software, but not on other software that it interacts with.
| > 
| > If I'm distributing foo.exe that is dynamically linked to bar.dll, does
| > not the GPL insist that bar.dll is also "GPL compatible"?  Or is the OSI
| > explicitly viewing the GPL to apply only to statically linked libraries?
| 
| Whether a dynamically linked library is a "derivative" or
| "other software interacting with" is an often-debated question.
| But yes, if it's *not* derivative then the GPL would not apply
| to the linked library.

I'm extremely confused how OSD#9 is compatible with the GPL license in
the case of a dynamically linked library.  Could you explain in much
more detail?  

In particular, the "derivative work" vs "mere aggregation" seems a bit
problematic, at a practical level.  Could a CDROM be inspected to
enumerate the derivative works created by GPL'd executables?  Do the
derivative works actually exist on a typical CD-ROM distribution?  What
if a GPL'd executable was written so it could call any other dynamic
library on the CDROM - would that executable be in violation of OSD#9?

If it were found out, in a court of law, that dynamic linking does not
in fact create a derivative work, and if the FSF still asserted that the
GPL is still enforceable though other means and this were upheld, would
this situation force the OSI to de-certify the GPL?

In other words, what is the bigger picture here?  The explanation of
OSD#9 seems to rest only upon the current state of this dynamic linking
controversy, rather than on any higher-level principle.   

What sort of situations does the OSD#9 prevent that caused it to be
added to the definition, and how do those situations differ from what
I am currently proposing?

| > I would perhaps be completely thrilled with a license that acts like the
| > GPL, but one where the test was on "dependency" rather than on "static
| > linking".  Let's define an Depend license as something following...
| 
| That's what I thought. The problem is that that simply goes
| against OSD 9. You're just not supposed to have an OSI-certified
| open source license that extends this far. You can make demands
| about derivative works, but that's it. You cannot ask that a
| database server, operating system or BIOS firmware be open source
| just like your software.

My reading of OSD#9 differs.  It says in the rationale, that "Software
linked with GPLed libraries only inherits the GPL if it forms a single
work, not any software with which they are merely distributed".

In the proposal here, it would takes much more than simply being on the
same CDROM with my application for an "inherited" license to trigger: a
run-time dependency necessary for the normal operation of the covered work
would have to be formed during its performance (thanks David Woolley).

Alternatively, you could view it as a legal question up to a judge: does
a derivative work form when a connection is made between two systems
such that one simply cannot operate without the other.  In this case,
why would the OSI need to reject the license outright, since it may fall
cleanly under the same rule that allows the GPL.

Further, even if such a license did violate OSD#9, would it not make
sense to consider this sort of license anyway (and perhaps amend the
definition rules if they were found to be inadequate)?

Cheers,

Clark