[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: License for mixminion dist
On Tue, 2002-04-23 at 07:22, Zooko wrote:
>
> > Hi, all. I'm answering all my mixminion mail tonight, and resurrecting
> > some threads of Roger's that I earlier decided to ignore until reply
> > blocks were settled.
>
> I would like to use standard licenses (in fact, I'd like to use one or more of
> the Big Four listed at `http://zooko.com/license_quick_ref.html').
I agree that a standard license is probably best, although I do agree
with David that it would be good to have a way to prevent secret forks
of the server code. (More on that below.)
> A useful tool is Peter Lowe's interactive version:
>
> http://yoyo.org/~pgl/lqr/
>
> I think it would be best if it were under LGPL, because all five of the
> columns are set to "Y". As far as I understand, that would prevent anyone
> from distributing a mixminion node which didn't come with source *for its
> mixminion component*, but it doesn't require them to release source for other
> components like, uh, e.g. a massively multiplayer online role playing game
> built on top of mixminion.
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?)
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.
OTOH, I'm willing to allow people to fork proprietary versions of the
_client_ libs, if doing so means that more mailers support Mixminion.
We would be "doing a favor" for proprietary systems (in the way that I
believe RMS dislikes), but the dynamics of anonymity sets mean that
proprietary users actually _help_ the mainline users.
================================
Now, for David's ARPL. As near as I can tell (and I'm not much of a
lawyer) the goal of this license is to make it a violation of the
license terms to operate an modified node without flagging it as such.
This tries to prevent people from running modified nodes without
identifying them.
Whom are we defending against? A large-scale adversary willing to run a
network of evil nodes would probably be willing to flout our license,
too. Anybody unethical enough to DoS our network is unethical enough to
flout our license. The only security risks his prohibition effects are
people who believe (incorrectly) that their modified code is better --
and personally, I bet those people would heed a polite _request_ that
their forks return a different version string.
Am I overlooking or underestimating a threat here?
Also, if we adopted, for server use, a license that had the additional
requirement above the GPL we saw above, that would work as well here.
==============================
To summarize, the issues are:
1. Is there a reason not to use GPL on the server? That is, is
there a reason we want to allow proprietary code to link
against the server code?
2. Are we okay with the property of the GPL that would allow
proprietary server forks, so long as the binaries we not
distributed? If not, what can we do about it?
3. Do the rest of us (other than me) mind seeing our client code
incorporated into proprietary mailers? If not, is LGPL or
BSD better? If so, why so?
4. How severe is the risk of people running modified servers,
but refusing to acknowledge the fact? More importantly, how
much can we address this with a license?
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.
Yours,
--
Nick