For Approval: Socialtext Public License ("STPL")

[Andrew C. Oliver]

That caught my eye as well.

I'd say it actually violates OSD#10 in that it requires the "covered 
code" to provide this functionality and is technologically dependent.  
Larry Rosen gave a history of the clause in the previous discussion and 
it was
originally prompted by click-through licenses.  I would suggest that 
this is substantively similar and I question
whether it really adds much these days.  Google/email pretty much serve 
the same purpose.  Moreover just
requiring the license be included in distibutions with notification of 
where/how the user can request the source code
can serve this purpose much more fault tolerantly and securely.  If the 
technical methods were used then DNS
or other means might forward the request to a spammer who domain snipes 
and email has provisions for
redelivery.

Moreover, the clause doesn't assist lead generation for the source 
company (assuming intent) as it requires the
mechanism not the destination. 

-Andy

Lasse Reichstein Nielsen wrote:
> On Thu, 08 Mar 2007 16:39:01 +0100, Ross Mayfield 
> <ross.mayfield at socialtext.com> wrote:
>
> Only commenting on the "Network Use" part.
>
>> 1.2  Network Use.  If the Covered Code as You received it is intended to
>> interact with users through a computer network and if, in the version 
>> You
>> received, such a user has the opportunity to request transmission to 
>> that
>> user (whether through an Electronic Distribution Mechanism or 
>> otherwise) of the complete Source Code of the Covered Code, You must 
>> not remove that
>> facility from the Contributor Version, and must offer an equivalent
>> opportunity for all users interacting with the Contributor Version 
>> through a computer network to request immediate transmission by HTTP 
>> of the complete Source Code of the Contributor Version.
>
> You might want to define "facility" too. It's not clear whether it is the
> functionality of requesting download of source, or the concrete covered
> implementation of it, that must not be removed. If it's the former, then
> "must not remove" is irrelevant, as the next part of the sentence says 
> that
> it must exist anyway. If it's the latter, it is a problem.
>
> Consider the case where you have a complicated network application 
> covered
> by this lincense. I find that at the heart of that application is a very
> efficient connection queue implementatation (or something similar 
> low-level)
> and I want to use *just* that for my own network application, which will
> be placed under the same lincese.
>
> This license then prevents me from omitting the implemented facility to
> request source from my program, even though I have another way of 
> providing
> source.
>
> Generally, a "must not remove" requirement on code is a bad idea, so I'm
> hoping it's a "must provide functionality" requirement.
>
>
> Also consider the case where I find that the covered code contains a very
> efficient implementation of a MultiMap, or similar generic data 
> structure.
> I want to use that in a *non*-networked, off-line, application. This 
> is not
> possible, as there is no way for the non-networked application to offer
> source code download, though that might be leviated by distributing the
> source code with the application. Ofcourse, that would be the "FILE" 
> protocol,
> not HTTP :) The HTTP requirement has already been commented on.
>
> /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.


-- 
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org