Re: License for mixminion dist

[Zooko <zooko@zooko.com>]

> > I think it would be best if it were under LGPL, ...
[...]
> Hn.  I'd just as soon _not_ help people make proprietary servers that
> subsume the Mixminion server.  If they extend the Mixminion server, I'd
> rather they released their code.  (Are there any realistic examples of
> why we should permit this?)

Well, any system that uses MM for anonymous messaging would require linking 
with the MM code, right?  Like, I dunno, some distributed database for some 
kind of medical support group or something.

I still don't understand the distinction between "client" and "server" here.  
To my mind every MM node is identical, and you must run a local MM node to use 
the MM protocol directly.  (All this SMTP stuff is, in my view, just one 
possible service that a person A can run, where person A is required to have 
an MM node and then offers service via SMTP to a person B who doesn't run an 
MM node.)


> On the server side, the big danger is that under the GPL, people don't
> need to release the source to a modified Mixminion node unless they also
> distribute the binary.  If they just run the proprietary version on
> their own computers, they're allowed.  (I'd kind of like to keep people
> from doing this.  Maybe we could change "distribute" to "operate for
> public use."  My understanding is that the FSF is working on a license
> like this to be an option under GPL3.

That's my understanding as well.

I guess I don't really care about this issue much.  As you later point out, 
licensing terms are not really the primary line of defense for bad nodes -- 
the MM protocol itself and the reputation/node-selection system are.

(BTW, when I say "the reputation/node-selection system", I mean primarily the 
human, manual, gossip-based reputation/node-selection system where people meet 
each other in smoky bars and say "Oh yeah, try *this* node." and scribble 
public key ids on beer-soaked napkins.  Other kinds are possible but unproven.)


> Of course, we probably don't want to get too exotic here.  Keep in mind
> that less-common licenses have been known scare away developers and
> users.

Yeah to me this is one of the primary considerations.

Regards,

Zooko