restrictions on web service linking?

[Clark C. Evans]

Thank you for chiming in Chuck Swiger and David Woolley.  This message
also includes a response addressing two of Flaschen's posts, one from
Michael Poole, and Arnoud Engelfriet's recent reply.  I tried to make
it as short as I could, sorry that it still rambles.

On Tue, Nov 21, 2006 at 02:44:06PM -0500, Chuck Swiger wrote:
| The OSD does not mandate that all combinations of Open Source licenses be 
| redistributable; license incompatibility is a significant and legitimate 
| concern.  The GPLv2 predates the OSD and to some extent is grandfathered 
| in, as are some other licenses (ie, Python has an ACCEPT button in the 
| Python license).

I can buy this argument, thank you for the clarification.  If something
is just called an exception this would make it much easier to deal with
than trying to shoe-horn a rule that doesn't quite fit.

On Tue, Nov 21, 2006 at 07:42:58AM +0000, David Woolley wrote:
| The Free Software Foundation's interpretation that dynamic linking 
| constitutes a derivative work is highly controversial.  At your level
| of combination, even the FSF doesn't appear to believe that a
| derivative work exists.  If there isn't a derivative work, you need
| a correctly formed contract, not just the bare license concept that
| underlies most open source software (most commercial license agreements
| purport to be contracts, although there is some controversy in that area).

After reviewing the issue in the prior example I posted, the case of the
readline library,  I join in this skepticism -- at least under the theory 
that the application is some-how a derivative work of the linked library.

However, I'm not about to thow the baby out with the bath-water.

| (It might be argued that performing rights are an issue there, and that
| you can therefore impose conditions that you couldn't impose for mere use.)

This is a very good perspective, and as I thanked you earlier, it has
informed my reasoning.  In the case of a shared library, while the code
for the library remains separate even when "loaded" by an application,
there is a shared workspace: the data segment.

To steal the music analogy, I imagine our application is a particularly
gifted singer who knows how to belt out a mean "Battle Hymn of the
Republic".  Further, I picture the library as being a rather mousy
announcer reading the declaration of independence, in monotone, an
octave lower.  I can just hear the emergent syncopation of this
particular arrangement.  Oh wait, that was the History Channel.

In all seriousness though, I think there is a derived work, but it
doesn't happen at design, compile, link, or load time.  It happens
when the program is executed -- during its performance.   The beauty
is, you don't need to agree.   

Let's call this thing "performance" and be done with it.   I can 
picture my application and a database working on a mutually derived
communication dialog; I picture an application and an dynamic link
library performing together in the shared data segment.  You are
welcome to see this as simply "running" the program, where by the
restrictions I'm discussing trigger on this event.

The license I'd like to forge, based on the theory of the GPL, is one
that prevents "proprietary dependence" during a "public performance"
of the software.

On Tue, Nov 21, 2006 at 06:17:23PM -0500, Matthew Flaschen wrote:
| Clark C. Evans wrote:
| > However, if one component simply cannot operate without another... it is
| > a completely different matter.  This the case I'm talking about.  It may
| > not be detect this case via a computerized algorithm, however, when
| > presented to a Judge, I think the distinction would quickly be obvious
| > (and would develop case law that clarifies the intent, if you didn't
| > include explicit examples in the license itself).
| 
| Components that can not operate without each other do not necessarily
| form a derivative work.  A derivative work must actually be based on the
| original work, not just tightly interacting with it.

As I stated above, I respectfully disagree.  Furthermore, since this is
not exactly settled law, I don't think that my proposal should be
rejected due to your opinion otherwise.   But let's work on a productive
line of thought, shall we?

The issue for me is what sorts of "performances" can or should be
restricted?  The implicit adoption of the GPL by the OSI implies that a
license condition based on this sort of thing should at least be
acceptable (due to linking).  The question is, what sort of limit is
reasonable?  

That is, as Chuck states above, what sorts of license incompatibilities
should we be concerned about?  What guidelines should the OSI place on
licenses that restrict performance? One guideline seems obvious:

   No Restrictions on Private Performance
   
     Running or making derived works with the software should not in any
     way be restricted, so long as this activity is done in private and
     the results of this activity remain private.  For a rationale, we
     look to the music industry. Just as music performances by private
     individuals for private audiences (think a family dinner) is
     protected, so too must private use of software.  

An example of a OSI clause which currently puts a restriction upon
performance (in its language, 'use'), in my opinion, is the OSLv3
"External Deployment".  Note that it explicitly follows this guideline,
taking care to only trigger upon the use of the software in a public
networked service.

My particular request satisfies this guideline, I'm not attempting
to prevent any private use of my software.

On Mon, Nov 20, 2006 at 04:40:30PM -0500, Michael Poole wrote:
| You wish to prevent users from modifying your software to communicate
| with certain other software.

It's actually somewhat broader: Even if my software isn't modified, I
still want to prevent it from communicating with other software under
particular cases.  I concede that most cases happen with "hooks" being
installed, that is, with actual modification.  However, modification
should not be a necessary condition for a restriction on performance.

Yet, significantly narrower: I only wish to limit communication with
certain other software which (a) cause a dependency to be made of my
software upon that software, and (b) that that software is not licensed
in a manner that guarantees the freedom I wish to maintain for my software.

To use Bruce Perns' vocabulary:

   I wish to prevent the public attachment of a proprietary parasite
   to my software.

I have tried as best as I can to narrow my request to the bare bones.  I
am particularly concerned about systems which when used together with my
application by a way in which it is modified or configured, that:

  (a) create a dependency, in such a manner that if the given system
      were removed, my software would fail to operate normally; and

  (b) be licensed in such a manner as to not provide the same rights
      that I provide to the users of my software.

Let's call this a "proprietary dependency".  I do not wish to have my
application participate in such an arrangement.  My concern is the
injection of proprietary features into my application as seen by end
users.  I assert this technique is simply sneaking a proprietary
dependency in under the "cover" of an otherwise open source product.

The problem is thatthe implicit promise of open source is broken, the
end user cannot obtain the same functionality they were lured into
using, since a proprietary license is actually required for the system
as used to be reconstructed.   

As I've stated before, my concern is a scenario where:

  1) my application software is used as a web-service,

  2) it is configured to use a proprietary database,

  3) by nature of its configuration, proprietary features
     are presented to the user that are not open source.

This can happen either with database features (ie, adding explicit
"hooks" to my code calling functions that don't exist in the open source
database), or indirectly through a different interpretation of the
information sent to the proprietary database.

| If the "end user" is distinct from the "hosting user", then external
| deployment clauses will make the modified software available to end
| users.  Those end users then have the freedom to port changes to other
| database backends (or whatever else) as much as they desire. 

This is a bit optimistic.  If the end users wish to move their data to
another system, they will have the *burden* of duplicating functionality
they have grown dependent upon without the benefit of source code or a
corresponding standard.  This hurts the name and value of my software,
as well as the open source label which I hope it would fly under.

The changes to the my application may merely be a few SQL changes to
invoke a stored procedure or non-standard SQL construct that does all
the work.  This isn't fair play, and I would like to prevent it.

On Mon, Nov 20, 2006 at 04:41:36PM -0500, Matthew Flaschen wrote:
| > If my application was released under the OSLv3, the license would trigger
| > via the "External Deployment" clause and require the organization to publish
| > all source code changes that they are using due to this deployment.  However,
| > the source code released isn't helpful, since public users of cannot make use
| > of these "improvements" unless they separately license Oracle.
| 
| It might be.  PostegreSQL or another open source database system might
| add a similar feature later, or the new feature might be adapted to be
| partially usable with current open source software.

Speaking from a business perspective, it is quite hard for me to open
source my work if competitors get to use my stuff, but not publish their
modifications.  The GPL simply will not protect my interests if "hooks"
are added to my source code, but the implementation of these hooks can
be kept private since they are implemented in a different program.

| > I would like to prevent such "improvements" to my application from being
| > externally deployed.  In particular, I'd like to see an additional clause
| > to OSLv3 that covers this case.
| 
| I still think it is the intention of OSD #9 to prevent this.  If we
| consider External Deployment distribution, you are attempting to
| attempting to mandate that only an open source database program can be
| distributed in conjunction with your program.

The historical intent of OSD#9 was to ensure that licenses from various
open source (and non-free) products can be aggregated together on a
single CDROM or other distribution.  It is not, nor should it be a
bludgeon to ensure that a user can piece software together, for public
performance, in any way they choose.

What I'm talking about is a license clause (similar to OSL's External
Deployment) that triggers upon use.  Hence, by definition, it just
doesn't apply to OSD#9, since a restriction on distribution is
simply not part of what I'm asking.

In more detail, I see my request as analogous to the case of dynamic
linking for the GPL license.  The derivative work is formed at load or
run time, when the dynamic library is "hooked up".  If you view the
distribution happening at execution time, the library is part of a
derived work and hence exempted from OSD#9.  If you view the distribution
as happening while the program isn't running, it could be viewed as a 
mere aggregation.  In either circumstance, all is OK.

For my particular use case, my application is welcome to be placed on the
same CD-ROM as Oracle -- or any other software program.  Nothing in my
additional clauses should prevent this.  By my logic, when the clause
does kick-in, during performance, a derivative of my system (and that of
the database) is created.  It is on the basis of this arrangement that 
the proposed clause kicks in.

| Finding otherwise would require that the modified program and Oracle be
| considered a single derived work; I just don't think this is accurate
| (if it was Oracle would probably sue).

This is simply not the situation I'm describing.

On Wed, Nov 22, 2006 at 06:39:54AM +0000, David Woolley wrote:
| This borderline case of the GPL is a common off topic subject!

Agreed.  I've tried, in this email to move the discussion elsewhere and
I hope that concerns regarding OS#9 has been adequately addressed.

| Note that the GPL V2 does not mention static linking, but only
| derivative works.  It is the FSFs interpretation that dynamically
| linked code is a derivative work at the time of compilation (or
| first linking).

And to re-cap, I consider it to be happening when the software
components are first linked together via a socket or other communication
channel. Alas, we don't have to agree on this since one can restrict
how copyrighted works are performed.

| > | 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".
| > 
| > I kinda read OSD#9 more literally, that it doesn't place restrictions on
| > other software it is distributed along with.  That is what it says anyway.
| 
| The purpose, as far as I concerned, is to allow the creation of compilation
| CD, and to allow commercial OS distributors to distribute open source 
| programs along with their operating systems, as most Unix ones do and I believe
| even Microsoft does.

Indeed.

On Wed, Nov 22, 2006 at 08:23:07AM +0100, Arnoud Engelfriet wrote:
| I can completely see your argument. Problem is, this isn't
| anything like math where we struggle over the formulas until
| the right answer comes out. It has to be a consensus that
| seems reasonable to most people. Hence the Ph.D. theses.
| And I'm afraid the consensus right now is "linked libraries yes,
| cooperating programs no".

Well, hopefully this particular point can be set aside, and we could
just consider what is appropriate guideline for OSD with respect to
restricting usage. 

Thank you for your attention and concern if you have made it all the way
to the bottom of this post.

Kind Regards,

Clark