[Mailman-Developers] mailman / archive-ui / licensing questions

[Stephen J. Turnbull]

On Wed, Apr 4, 2012 at 3:58 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:

> From the talk about what it means to be a FSF project at the mailman sprint
> at pycon I don't think a non-FSF copyright assigned archiver would be
> bundled into mailman (Core).

AFAIK there are no "FSF projects", although the FSF does support "The"
GNU Project and sometimes specific GNU projects.  According to the
criteria for being a GNU project
(http://www.gnu.org/help/evaluation.html)

    For a program to be GNU software does not require transferring
    copyright to the FSF; that is a separate question. If you transfer
    the copyright to the FSF, the FSF will enforce the GPL for the
    program if someone violates it; if you keep the copyright,
    enforcement will be up to you.

What *is* required is the GPL:

    A GNU program should use the latest version of the license that
    the GNU Project recommends—not just any free software license.
    For most packages, this means using the GNU GPL.

So David's program can't be *part* of GNU Mailman without special
permission, which I doubt the GNU Project (ie, RMS, AFAIK) will grant
(and would require delicate negotations in extreme good humor on our
part, based on past experience trying to negotiate licensing
exceptions with RMS).  It is not obvious that it can't be bundled with
Mailman distributions, however.  To my mind, bundling is a very strong
recommendation, and the official standard for GNU projects merely
says:

    A GNU program should not recommend use of any non-free program[...].

We could also redistribute verbatim, as part of Mailman under the GPL,
with pointers to upstream (I would be happy personally host a mirror
of a permissively licensed distribution).  Perhaps with an
ElementTree-like agreement that David makes the call on changes to the
archiver he contributed.  AIUI, that would make David happy (enough),
as he doesn't believe you can really restrict redistribution of a
simplified BSD-licensed program merely by incorporating it in a GPLed
distribution.

The main stinker there is the "David is the boss" agreement, if he
wants it.  I personally have been working with that kind of agreement
for years in XEmacs, and it makes our package contributors happy,
although it pisses off some of our core contributors.  Similar to the
ElementTree controversy in the Python stdlib, although none of the
packages where issues have come up matters as much to us as
ElementTree does to Python.  So that would be mostly up to Barry (if
David decides he wants that kind of power over the future of his
archiver after contributing it to Mailman).

> General impression from talking to a few other developers at PyCon is we
> generally like copyleft licenses.  Some version of copyleft is likely what
> a lot of us would choose to license our own code under.  A few of us are
> unhappy when our code is used to make closed source applications.

Sure, but this isn't our code yet, it's David's, and he proposes to do
much of the work involved in adapting his code to Mailman 3.

> Mailman2 is an FSF project.  mailman3 and postorius are both derivatives of
> mailman2 and so they are both FSF projects.

That logic is inaccurate.  There's no must about it; Mailman 3 could
just as well be a fork.  But since the FSF is the owner of most of our
code, there are certain important conveniences to continuing that
practice, and no real benefit to not doing so since we can't choose
our own license because of the derivation from Mailman under the GPL.

> FSF projects must do copyright assignment to the FSF

Not true, see above.

> and are licensed with one of the GNU licenses.

This is true, and I'm pretty sure it will be GPL v3, although given
the functionality there is some chance the GNU Project would push for
AGPL (but AFAIK RMS still considers the Affero clause optional, even
for out-and-out Web 2.0 webapps).

> Do we want to have a single blessed archiver (probably
> in a separate tarball as postorius, the admin web ui, is
> separate) as an eventual goal?

I believe that we won't have a blessed archiver, in the sense that any
archiver we distribute will have to use the same APIs that other
archivers do.  But having followed mailman-users for a decade now, I
think it would be a bad idea to have a "batteries not included"
distribution for Mailman 3.1.  Which webmin, which archiver, is a
different question.