[Mailman-Developers] What is "GNU Mailman?" (was Re: mailman / archive-ui / licensing questions)

[Barry Warsaw]

See what happens when you go on vacation?  So many interesting issues to
untangle!  I'll try to catch up but my responses will no doubt be somewhat
fractured.

First of all, thanks David for bringing ClearSilver to our attention and
offering it to the Mailman project.  We can all agree that Pipermail is dated,
is missing key features, and needs to be replaced.  It's been removed from the
lp:mailman branch.

What does it mean to be part of the "GNU Mailman" project?

This used to be an easy question to answer because everything was bundled.
When you download the mm2.1 tarball, you get an archiver, a web ui, and an
engine.  Everything is GPLv2+'d with copyright owned by the FSF.  Life is
simple.

Now we have at least two separate subprojects, the core and the web ui.  It's
very likely that what we'll call "GNU Mailman 3.0" will be just the core.
For various reasons, this needs to be released as soon as possible, but it's
important to understand that it won't be a full replacement for Mailman 2.1.
I think of it more like the Python 3.0 release - a critical milestone for the
project, usable on its own, but with deficiencies we both know about and don't
yet know.  We'll need to manage expectations, but it's also true that it just
will not get a full workout until it's got that "final" stamp on it.  We can't
wait for Postorius or an official archiver, but both those will probably be
included in future releases.

One of the core principles of mm3 is that site admins get more choices.  You
can use Postorius as your web ui, but it's also easy to use something else, or
no web ui at all.  Want to use your own archiver?  No problem.  Want to throw
all your data into PostgreSQL and drive the user database off your corporate
databa$e?  No problem (hopefully :).  So again, in a mm3 world, what does it
mean to be part of the GNU Mailman project?

Here are some of my own principles, and I'd like to hear yours.

No fiefdoms in the code.  I much prefer projects where everyone feels a shared
sense of stewardship for the code base.  Of course we'll have experts in one
area or another, and everyone is going to have an opinion about how things
should work.  Hopefully you won't depose me as BDFL just yet.  But I do think
that nobody should have veto power over any particular aspect of the code.  An
expert, or even myself, should be able to make a convincing technical argument
for why something should be done or not done, and that should hold sway over a
collective solution.  Now, it might be because one way is the right way to do
it, or because another way is the expedient way.  And not everyone will agree
with every decision, but I also think it's important to fight the good fight
and then work hard to make this a successful collaboration.  Of course, you're
never forced to hack on something you disagree with.  Almost above all else,
this should be *fun* :).

This relates to big code donations like the archiver.  Once we as the Mailman
project accept something under our umbrella, we all have the right and
responsibility to dig in and hack on it.  In Python, I don't think it's really
worked out very well to have some big donated module be "owned" by one person.
There are both pros and cons for getting subsumed into a project, so only do
it when everyone understand and agrees to that.

As I mentioned, bundling and releasing was easy in 2.1.  It'll be easy in 3.0
only because that will probably just include the core.  What does a release
look like in Mailman 3.1 and beyond?  How do we take all these disparate
projects (Postorius, the API client, an archiver, etc.) and release these in
an easy to download and install format?  I'm still not sure, and I'm not
holding up the 3.0 release to figure that out, but we will have to figure that
out at some point (and probably get it wrong the first few times :).

Licensing was also an easy decision.  Everything was GPLv2+.  Now the core is
GPLv3+, as is Postorius.  I'm not a licensing zealot; I'm pretty much happy to
hack on anything that has a FLOSS license.  I think a copyleft Python would
fail miserably, but copyleft has worked well for Mailman for probably 15
years, and it's too late to change the license.

I'm happy for people to make money off of Mailman, but the GPL helps ensure
and encourage that folks give back to the project.  GPLv3+ seems right for the
core, and pretty right for the web ui (AGPL might be better, but Toshio has
identified some problems in practice with it).  I would certainly prefer that
any archiver that gets bundled under the GNU Mailman moniker be copyleft, with
copyright assigned to the FSF.  The core and web-ui are already structured
this way, so I think the consistency ultimately makes our lives, and more
importantly the lives of our users, easier.

Those are my preferences anyway.  Maybe copyright assignment to the FSF isn't
right for the archiver, but I need a more convincing argument than "I don't
like it".  Same for choice of license.  From a project management perspective,
consistency is a big win, so convince us why it's better, or at least okay, to
have different licensing and ownership regimes under a single project's
banner.

Oh, one more principle I'd like to maintain: please write it in Python.  No
disrespect to other languages, but Python is just more fun and consistency
counts.  Okay, okay, you can include some JavaScript for the web bling if you
must. :)

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120408/ebe269f2/attachment.pgp>