On Mon, Apr 02, 2012 at 08:04:23PM -0700, David Jeske wrote: > On Apr 2, 2012 3:07 PM, "Terri Oda" <te...@zone12.com> wrote: > >> This agrees with my view of the situation as well. Which leads to the > >> question, is the above approach interesting/viable for Mailman-team? > >> (assuming the code does something awesome that people want) > > > > If the question is just "would you like another archiver even if the > licenses don't match?" then I believe the answer is yes. > > The question i "would you BUNDLE another archiver even if the licenses > don't match?" > > My archiver has been available for download (like many others) for ten > years. All these sites are still running a limping pipermail archive, > because it's bundled. I want to get Mailman a better bundled archive. > 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).
Distributed/pointed to by list.org along with mailman and postorius might be negotiable though :-) Would that be something you'd like to pursue? Also -- mailman3's builtin archiver is extremely minimal -- at the moment, it archives (stores) mail but it doesn't have a means to display that email on a web page or similar. Given that sort of bundled archiver, I have a feeling sites are going to want to run a third-party archiver of some sort instead of the default. > > HOWEVER, I personally will not write GPL code. I might submit a tiny patch > or bugfix, but I'm simply opposed to restrictions on how someone uses > something that I'm trying to donate to the software community. (i.e. you're > never going to turn me into a mailman developer, the best you'd get is me > writing my own mailman-ish and releassing it under S-BSD.. if you want > that, let me know) > 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. Mailman2 is an FSF project. mailman3 and postorius are both derivatives of mailman2 and so they are both FSF projects. FSF projects must do copyright assignment to the FSF and are licensed with one of the GNU licenses. Where could your archiver fit into that sequence of impressions? I'm not entirely sure. I think that it probably couldn't be bundled into the same tarball with mailman core due to mailman being an FSF project. But pointing to it from list.org or blessing it as the "standard archiver" for mailman3 is probably something that could be discussed by the core devs and yourself. I don't think you're going to find the will to make this sort of decision right at this instant because what we want the archiver ecosystem to look like for mailman3 is somewhat in the air. Do we really want an obviously less capable archiver to be the bundled archiver? 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? Do we want (at least for a year or two) to let people go to town with their new ideas for archivers and then see if a best-of-breed archiver is raising its head? I don't believe any of this is decided inside of our minds yet, so, for now, people are defaulting to wait and see. -Toshio
pgpRWhRcGlqe8.pgp
Description: PGP signature
_______________________________________________ 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
