restrictions on web service linking?

[Matthew Flaschen]

Clark C. Evans wrote:
> Matthew/Andrew, 

This is a "free" application, and I wish it to remain so.

I assume you mean open source (though they're almost the same thing).
If so, the only way you can guarantee that is by using a strong copyleft
OSI license (such as the GPL).

> By this response, I assume you're saying that restricting the use of a
> proprietary database system limits the freedom of the data stored in
> that database? 
> 
> In my opinion, this is not true.  If the user wishes to use my application
> they can export their data and use one of the free databases out there.

Yes, and if they even want to switch to a proprietary database system,
they have to stop using your application too.

 If
> they do not have a "feature" they need in those free databases, perhaps they
> would want to contribute back to the community so that those databases
> can be viable for their usage.

   I do not see this at all as limiting a
> "Field of Endeavor". 

Not everyone has the time or knowhow to write the features they need.
> 
> On Mon, Nov 20, 2006 at 12:00:22AM -0500, Matthew Flaschen wrote:
> | This is in accordance with fundamental copyright principles.  These
> | platforms (languages, databases, etc.) are not derivative works of your
> | software; their licensing is independent of your software's.
> 
> I am not claiming that these (programming languages, database systems,
> etc.) are derivative works of my application.  I am claiming that the
> combination of my work with their work is.

If by combination you merely mean they are on the same system, and
exchange queries, you are still wrong; this does not mean the two
programs are a single work.  Such combinations must be allowed under OSD #9.

> For my particular case, the interaction of a database application with a
> database system (the software, not the data) is quite intimate and
> temporal... much like the "calls" made to a library.  Arranging my
> application in such a manner that it would use a library should trigger,
> in my opinion, a copyleft.   
> 
> By arranging I would include: adding code that would cause the application
> to use a particular "external" service, adding ODBC configuration information
> which would cause the application to be linked with the database system, etc.

The fact that a modified version of your program uses proprietary
software over ODBC and/or SQL does not mean the proprietary software and
your program form one work.  If that alone was sufficient to define a
single derived work, much open source software would be in violation of
proprietary software licenses.

> 
> | It seems you're trying to slip around this principle (fundamental to 
> | copyright law) by limiting the user's right to use proprietary and open
> | source software together (since you can't limit proprietary software itself).
> 
> This comes down to enforceability, not intent.  Can we stick with intent
> for the purpose of this thread -- enforceability is a separate issue.

I think the purpose of OSD #9 was to limit this type of clause,
partially *because* it's unenforceable.

> I'm afraid I don't understand this point.  As I stated above, a user can
> simply use a free database...

Without this clause, they can simply use a free database (if they choose
to).  With the clause, they MUST use a free database.


> The licensing restriction that I'd like to see is a more "modern" GPL
> that doesn't rely upon static linking.  Enforcibility is indeed a
> concern, but courts have been enforcing all sorts of stuff by virtue of
> copyright law.  I'll take my chances there.

I think OSI is reluctant to allow unenforceable licenses, and this is
reflected in OSD #9.

> Clearly the language above is overly broad.  However, I would hope that
> OSD #9 was not intended to prevent limitations beyond static linking. I
> think the word "dependency" might help:

I think it was intended to stop at about the same point as copyright law.

> 
>  Let us define "Arrangement" as the static or dynamic combination of
>  this Original Work and its Derivative Works with other software systems
>  in such a way that the Original Work and its Derivative Works become
>  dependent upon the other software system for its normal operation.
> 
> This would cover my particular case, but clearly would not cover mere
> distribution nor usage.  For example, a browser connecting to this
> service would not cause the service to be dependent upon the browser,
> hence, this license restriction wouldn't restrict actual usage of the
> application.  However, connecting the back-end to a proprietary database
> would clearly create a dependency (remove the database, and the combined
> system fails to operate).

Similarly, if the operating system is removed, your program will fail to
operate.  However, the operating system and your program are still
merely being distributed together, and do not form a single work.

Matthew Flaschen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20061120/e2a874a9/attachment.sig>