For Approval: Socialtext Public License ("STPL")

[Matthew Flaschen]

Lasse Reichstein Nielsen wrote:
> 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.

It's true that HTTP is used, but the real effective protocol is layered
on top.  For instance, it could be:

1. Send login form over HTTP.
2. Send filled out form back over HTTPS.
3. Send menu over HTTP.
4. Request page of user's choice by HTTP, with URL specified by menu.

etc.

It would be impossible to change the interface without changing the
server code.  Similarly, it would be very difficult to keep the same
interface while changing the server 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.

I guess what I meant was that in a "thin client", the server specifies
the interface.  There may be slight variation because of browsers, but
this is unintentional.

With a thick client, the client specifies the interface and only pure
data is exchanged (obviously the reality may be in between).  This fits
my understanding of ATMs. I think only relatively simple data is
exchanged over the network, and the interface is governed by client
code, which can be changed without altering the server.

I would only consider the user to be directly interacting in this "thin
client" case.

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

I agree.  There are definitely perils to this clause, which I'm
beginning to recognize.

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

I don't think this is "interaction", but I agree it's uncertain.

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

Right.  As I said before, HTTP should unquestionably be removed (and I
don't think anyone would object to that).

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

Well, they may be able to, if the ATM lets regular users access it over
some serial port or such.  Like I said, this is really inconvenient.

 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.

True.  Depending on how large the program is, even if it's possible to
transmit source, it could cripple slow connections..

> - network, no gui: e.g., Server providing services only through Web
> Service-interface.

This would be what I called a thick client, and hopefully would not be
covered (since the interface is entirely created by the client).

> - no nothing: e.g., kernel driver (e.g., HD driver). Must be able to
> operate headless and isolated.

Strictly interpreted, even this could be considered use over a network,
if a network user uses some service that indirectly requires the driver.

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

It should probably just say, "interacts with users" instead of "is
intended to interact with users"

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

No, because that's not as you received it.


A possible alternative resolution in general is to allow the display of
a written offer for the source, rather than require immediate
transmission.  This should resolve the difficulty of providing source in
some circumstances; however, it doesn't resolve the other ambiguity of
what interaction is.

Matthew Flaschen