On Wed, Apr 4, 2012 at 3:58 AM, Toshio Kuratomi <a.bad...@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. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9