restrictions on web service linking?

[David Dillard]

> 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 can be viewed as potentially violating a several items in OSD:

3. Derived works: If someone cannot modify the software to work with any
of the proprietary DBs you named, you've restricted the ability to
create derived works.
 
5. No Discrimination Against Persons or Groups: You are discriminating
against those that wish to use proprietary software in combination with
your software.

And arguably:

9. License Must Not Restrict Other Software: You are preventing, via
license, other software from being used with your software.  Admittedly,
the description here goes into other software distributed with the open
source software, but I strongly suspect the intent was not to limit it
to just that software, as the rationale section alludes to.  It says
that "Distributors of open-source software have the right to make their
own choices about their own software."  I think we can all agree that
should apply to users of open source software as well.


--- David


-----Original Message-----
From: Clark C. Evans [mailto:cce at clarkevans.com] 
Sent: Monday, November 20, 2006 1:10 PM
To: Matthew Flaschen; Wilson, Andrew
Cc: Clark C. Evans; License Discuss
Subject: Re: restrictions on web service linking?

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