restrictions on web service linking?

[Clark C. Evans]

Matthew/Andrew, 

Thank you for your response.  However, I think your response demonstrates
that I have poorly explained myself.  I am not at all concerned with 
"user data"; I am not trying restrict "Field of Endeavor".  Please met
me explain my situation in more detail.

I have a typical web application, it takes in HTTP requests and responds
with content, usually HTML or XML.  This application depends upon a
database system for its operation (currently PostgreSQL), much as it
depends upon the programming language it was written in (currently
Python).  It also depends upon several open source libraries (to which
it is linked).  This is a "free" application, and I wish it to remain so.

I see the External Deployment (see OSL v3.0) of my application in a
manner with which it is configured to depend upon a proprietary database
system (such as Oracle, DB2, Microsoft SQL Server) for its operation as
problematic, and I would like to prevent it accordingly.  This is, in my
view, a classic "free rider" situation and one that does not help the
open source development community.

On Sun, Nov 19, 2006 at 01:17:45PM -0800, Wilson, Andrew wrote:
| This is a useful clarification, but one that still makes clear your
| intent is to craft a license which is not open source by definition,
| e.g., a license that prevents usage of the code with a non-free database.

I hope the above clarification changes your viewpoint.

On Mon, Nov 20, 2006 at 12:00:22AM -0500, Matthew Flaschen wrote:
| A database is not a programming language or operating system.  I think
| you're off-base in viewing databases as software.  They are inherently
| data, and thus can be manipulated by multiple programs.  Attempting to
| limit this to open source programs limits the freedom of the data (the
| copyright of which may belong solely to the user).

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

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.  Furthermore, unless these
systems are licensed in a manner that is "open source", I do not wish
for my work to be combined in such a manner.

| Even the GPL (a license which is deliberately very demanding on redistributors)
| underscores this by stating, "Thus, it is not the intent of this section
| to claim rights or contest your rights to work written entirely by you;
| rather, the intent is to exercise the right to control the distribution
| of derivative or collective works based on the Program."

This phrase was clarifying the previous phrase:

  "But when you distribute the same sections as part of a whole which
   is a work based on the Program, the distribution of the whole must
   be on the terms of this License, whose permissions for other licensees
   extend to the entire whole, and thus to each and every part regardless
   of who wrote it."

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.

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

| Thus, the user is being limited (perhaps permanently, if their database
| is tainted) because of the licensing choices of software developers they
| may be unable to control.

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

| Licensing use restrictions are not "fair game", as shown by OSD #9,
| "License Must Not Restrict Other Software."  The section states,
| 
| "The license must not place restrictions on other software that is
| distributed along with the licensed software."  It goes on to add as a note
| 
| "Yes, the GPL is conformant with this requirement. Software linked with
| GPLed libraries only inherits the GPL if it forms a single work, not any
| software with which they are merely distributed."

I'm not talking about being "merely distributed".  I'm talking about the
deliberate combination (via configuration, code, or otherwise) of my
application so that it is dependent upon a proprietary database system.

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.   

| Whether it is a single work is determined by copyright law, and IANAL,
| but I strongly believe that neither a database nor a platform would be a
| derivative work of a program that used them.

No, they are not derivative works.  However, the combination of my
software with a database is a derivative work.  It alters the 1's and
0's on the hard drive or in memory in such a way as to cause a linking
and indeed dependency between the programs.

| However, you suggest:
| 
| | Let us define "Arrangement" as the static or dynamic combination of
| | this Original Work and its Derivative Works with other software systems
| | which together form a whole.  This could be accomplished through (a)
| | static linking, (b) dynamic linking, (c) requests done over a network
| | connection, (d) or any other mechanism which causes the Original and its
| | Derived Works to directly or indirectly control the operation of another
| | software system.
| 
| This goes so far beyond static linking that if a shell were under such a
| license, every program distributed with it would have to be under the
| same license.  Also, network applications like Firefox (if they were
| under this license) couldn't communicate with servers that used
| proprietary software.  Clearly, OSD #9 is intended to prevent such
| limitations.

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:

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

I'm looking forward to your continued critique.

Clark