[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Heads up: License change on Mixminion 0.0.8

Hi, all.

This is a heads up that, as I've warned people in the past[0], I'm going
to release Mixminion 0.0.8 under a different license than previous

Previous releases have been under a slightly-modified[1] LGPL.  Newer
releases will be under the so-called MIT license[2].

This will only affect the Mixminion code; George's proxy code will
remain under whatever license he chooses.

If you have contributed significant blocks of code to Mixminion, then
I already asked you for permission to re-license the code under any
free license.  Nevertheless, if you object to the license change, let
me know, and I will remove any chunks written by you from the
code base.

Here's why I'm doing this: I still like the GPL, and I still agree
with most of the FSF's ideas.  Nonetheless, because our OpenSSL
dependency has forced me to be not-quite-LGPL[1], I haven't been able
to link against real GPL'd libraries.  Whenever I've found a library
that I wanted to use, I found myself thrilled whenever it was
available under a 3-clause BSD license or an MIT license.  In the end,
I decided that it wasn't fair to take such joy in other people's
decision to license their code liberally, while licensing my own under
a license that made other people's lives more complicated.


  Q: But the MIT license allows people to re-release your software
     under proprietary licenses!  Aren't you worried about the Forces
     of Evil releasing a (possibly compromised!) Mixminion under a
     different license?

  A: If the Forces of Evil really want to release a broken Type III
     remailer, they can already write their own compatible
     implementation.  Perhaps liberalizing our license makes it easier
     for them to do so.  However, I hope that people will have the
     good sense to reject *any* binary-only Type III implementation,
     and I think that by encouraging adoption of Type III and support of
     Type III by more programs, liberalizing the license will get us
     more good support than bad support.

     Anyway, the LGPL/GPL's provisions only affect *distribution*.
     The Forces of Evil have always been free to run compromised
     servers implementations on their own machines, so long as they
     didn't try distributing modified binaries without source.

  Q: Aren't you worried about someone like Microsoft embracing and
     extending Mixminion?

  A: Again, the Type III protocol is not encumbered; someone like
     Microsoft can already implement an incompatible proprietary
     version.  So this argument only applies to small-time players who
     wouldn't have the resources to re-implement Type III, but who
     _would_ have the resources to modify Type III and redistribute a
     *more popular* incompatible or distinguishable version.

     Yeah, I *am* worried about that.  But again, I think that
     liberalizing the license, in the end, will help our friends more
     than our enemies.

  Q: Aren't you going in the wrong direction?  We should change the
     license to something like the AGPL[4], to make it *harder* for
     people to run modified binaries without giving away their source!

  A: There are very valid arguments in favor of these licenses---for
     example, by making it impermissible to run a back-doored server
     without telling people, they provide honest operators with an
     excuse whenever their boss, or some other authority figure, asks
     them to start attacking their users.

     Ultimately, however, I think that these licenses would hinder
     adoption more than they will help security in the long term.
     There are plenty of projects (like mnet, for example) that might
     someday want to benefit from linking against the server code that
     do not want to change their licenses to do so, and I don't want
     to make them choose.

     We could probably get a lot of the benefit of one of these
     licenses by creating some kind of directory server
     terms-of-service along the lines of "In return for having your
     server listed, you agree to only run official releases, blah blah
     blah."  This could be harder to enforce than copyright, but might
     still work.

     Ultimately, please remember that under an MIT license, you can
     always fork and re-release your own modified Mixminion under the

  Q: Why MIT and not 3-clause BSD?  Why MIT and not MPL-with-

  A: Because MIT is shortest and thus easiest to understand. :)

  Q: If you are no longer LGPL, will you start linking with more
     GPL-incompatible stuff?

  A: No.  I will try to keep Mixminion from getting any more
     GPL-incompatible than its OpenSSL dependency already makes it.
     In fact, I still hope that future versions will be able to remove
     this dependency by allowing Mixminion to use NSS or GnuTLS as
     well.  Patches are welcome.

  Q: What happened to your previous ideas about using different
     licenses for client and server components?

  A: I'm no longer convinced that the division is as clear-cut as I
     thought.  Since I started writing Mixminion, I've moved several
     key modules that I thought would always be server-only over to
     the client-server side.  Also, I'm no longer convinced that
     linking against or modifying the server components is as
     valueless as I had thought; a few projects have already expressed
     interest in doing so, for reasons I think are technically valid.

Okay, that's my reasoning.  I know that licensing discussions are an
exemplary bike-shed problem[5], but I still hope that I don't need to
put on my asbestos underwear.

I promise, the next thread I start on this list will be technical. :)


[0] The LICENSE file has long carried the string "It is also possible
    that I'll relicense the client components under an X11-style

[1] The modifications were as follows: The regular LGPL lets you
    re-license the software under the GPL.  But the GPL is probably[3]
    not compatible with the OpenSSL license's licensing clause.  Thus,
    Mixminion has been released under an amended LGPL that lets you
    relicense the software under the unamended LGPL, the unamended
    GPL, or the GPL amended to specifically exempt OpenSSL.

[2] For a copy of the "MIT" license, see

[3] Some people think that OpenSSL qualifies as a "system library"
    because so many systems ship with it, and hence it's okay to link
    it with GPL'd stuff on those systems.  This is not the FSF's
    interpretation, however, and there are enough people who listen to
    the FSF's interpretations that you might as well take them as

[4] Info on the AGPL: http://www.affero.org/oagpl.html

[5] For more info on bike sheds, see
               http://a.mongers.org/clueful/1999-phk-bikeshed  .
    The basic idea is that it's easier to get approval for plans for a nuclear
    power plant than for a bike shed.  This is because most people believe
    (correctly) that they don't understand how to build nuclear power
    plants, and also believe (correctly) that they _do_ understand how
    to build a bike shed.

Nick Mathewson

Attachment: pgp00000.pgp
Description: PGP signature