For Approval: Socialtext Public License ("STPL")

[Lasse Reichstein Nielsen]

On Mon, 12 Mar 2007 01:50:18 +0100, Matthew Flaschen  
<matthew.flaschen at gatech.edu> wrote:

> That's a different, but interesting issue.  IANAL, but I think arguably,
> with an ATM, the user's not interacting with the "Covered Code", but
> rather with the ATM software, which in turn interacts with Covered Code
> (likely over a well-defined protocol that is independent of the Covered
> Code).

But in the "ASP" case, the user arguably interacts with the browser, which
in turn interacts with the web server (over a well-defined protocol  
independent
of the Covered Code: HTTP), which interacts with the covered ASP code.

> In other words, there is a thick client in between the Covered
> Code and user.

I would say that a browser is a thicker client than an ATM. After all, on  
an
ATM, all significant computations are certain to be done on the server. A
browser can do quite a lot of computation locally using JavaScript.

> I think the clause is only intended to apply when the
> user is interacting with the Covered Code over the network as directly
> as possible (e.g with only a dumb client in between).

In that case, the license should define how to delimit dumb/smart clients.
It's certainly not something I would expect consensus about.
And while we are at it, "interact with" isn't very clear either.

Perhaps the Covered Code is used in a service that generates pages and
prints them on a printer at the server end. The user never sees the output,
but he interacts with it as directly as possible (upload document, request
printing).

Perhaps the Covered Code is used in a mailing list server. It interacts
with people over a network. It could easily be set up to send the code
too, if asked, but that would not be HTTP.

> That said, I could easily see this becoming controversial.  It would  
> still be
> possible to transmit the source to the ATM (which must have some sort of
> maintenance port), but it would obviously be extremely inconvenient (and
> HTTP in particular probably isn't feasible).

... and even if it is possible, the user won't be able to receive the  
source,
even if the ATM client can request it. I.e., the requirement on making
the source available to the user is actually technology dependent - it
requires a way to make the source portable.

The ATM example is actually a good one with network connection and a gui,  
but
with other limits on what the client can do.

I can think of ~4 types of examples that should all be cosidered. In each  
case,
the usage of the Covered Code can cosist of as litte as a single  
class/function/whatever:

- network and gui: e.g., ATM connecting to server and server using Covered  
Code.
- network, no gui: e.g., Server providing services only through Web  
Service-interface.
- no network, gui: e.g., Stand-alone application.
- no nothing: e.g., kernel driver (e.g., HD driver). Must be able to  
operate headless and isolated.

STPL dodges the non-network examples by only requireing functionality if  
there can be networked
users. The networked ones require a clearer definition of "interact with".


I'm also slightly worried about the text "If the Covered Code as You  
received it is intended to
interact with users through a computer network ...". A licens that  
requires me to deduce the
intent of the upstream provider is an argument waiting to happen. Could I  
distribute to myself
and claim another intent for the next step? Could I split the code in two,  
so that neither
is complete and usable, and claim that neither is intended to interact  
with users through
a computer network (since clearly, it's not even able to)?

/L
-- 
Lasse R. Nielsen - atwork at infimum.dk
  'Faith without judgement merely degrades the spirit divine'
  Reproduction of this message, or parts thereof, is allowed if proper  
attribution is given.