Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Thu, Mar 29, 2012 at 1:00 PM, David Jeske dav...@gmail.com wrote: I started to talk to one of them about installing CSLA (or MHonArc, or anything really), and realized I should see if you folks are interested in a great bundled archiver, I'm personally interested, but that's not going to be the main focus until the core gets a little less alpha, I would guess. I admit that even with a pretty good knowledge of these many licenses, I'm not familiar with the intracacies of FSF copyright assignment and non-GPL free licenses. The bottom line is that if you assign it to the FSF, they can change the license of future copies to something you don't like without your permission, or even consulting you. This has been done in the past (eg, libreadline). I don't know whether they would bother with a non-GNU project, though. However, copies of the version you originally released under a different license remain under that license, and there's always a grant-back clause in the assignment contract that allows you to make derivatives of your contributions available under any license you like. The ClearsilverArchiver code (written by me and two others) is released under the Simplified BSD license and totally free. It's important to me that any code I release be similarly free-and-unrestricted (i.e. BSD/Python/Artistic/PublicDomain), not free under certain conditions (i.e. GPL/LGPL). It's not possible to assert GPL restrictions on totally-free code, because it's already totally free. That's not the way copyright works, though. It certainly is possible to assert GPL (or any other) restrictions on given *copies* of permissively-licensed code. If you've got a copy of the old (say, early '90s) O'Reilly X Window System series kicking around, check out the copyright notice in those books. (Preventing that is precisely why copyleft advocates advocate copyleft.) Even on a verbatim copy, lawyerly FUD means that even if there is no actual legal issue, practically it may be infeasible for just plain folks to redistribute. Cf. the DMCA takedowns. FSF says S-BSD is GPL-Compatible, which I believe means they are saying they have no problem with GPL code depending on and being combined with (i.e. linked with) S-BSD code, because the S-BSD code is fully open-source and does not put restrictions on the use of the GPL code. No. What they mean is that it is Borg-able. You can assimilate S-BSD code into a GPL project, and that copy is distributed under the GPL. Perhaps in legal theory they cannot prevent you from making copies of the S-BSD portions and doing anything the S-BSD permits, but the S-BSD (like other permissive licenses) does not require them to tell you what parts are S-BSD, only that some parts are, and who wrote those (unspecified) parts. (The wording is generally to the effect of This file is part of the FOO Program, which is licensed to you under the GPL. It contains software by J. Random Hacker, with the following permissions notice) The burden will be on the user to determine which parts can and cannot be copied, and if it comes to a court case, the user will have to prove that the parts they've copied are not actually GPL. I would say you should try to retain copyright, and have the Mailman project distribute it with the S-BSD license under the mere aggregation clause of the GPL. This would entail certain restrictions on interface. Eg, you can't put the whole thing in a pipeline Handler, and you would need to have a separate webapp for summarizing/indexing/searching/retrieving the archived posts. I advocate those restrictions anyway. :-) Some small glue parts that need to be tightly integrated with core Mailman might need to be done under GPL. It's also my understanding that the primary reason for FSF copyright assignment is to provide a coherent entity to enforce the terms of the GPL by challenging violators who don't redistribute source something which is not necessary for S-BSD. (Though I suppose they could enforce that folks include the S-BSD copyright notices.) The FSF's reason is so that they have control over the license, which allows them to make it GPL if that seems like a good idea to them. (Mostly they are way too busy to go looking for opportunities, though, and it's a labor-intensive process for a project of any size.) In return, they will enforce license provisions. Projects may also wish to do this so that they have the legal right to offer other licenses (the FSF is not a good assignee for this purpose!), or change the primary license. If no single entity owns the whole copyright, then you have to get agreement of all owners, some of whom may be in retreat in a Tibetan monastery or the heirs to someone who lost an argument with a bus, etc. (MIT specifically allows sublicensing, as does Larry Rosen's AFT; but S-BSD does not.) Is Mailman-team is interested in having a better built-in archiver that is included in the distribution, but licensed
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On 03/29/2012 02:27 PM, David Jeske wrote: On Thu, Mar 29, 2012 at 9:16 AM, Stephen J. Turnbullstep...@xemacs.orgwrote: I would say you should try to retain copyright, and have the Mailman project distribute it with the S-BSD license under the mere aggregation clause of the GPL. 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. I think it would be really beneficial for us to have more than one archiver on the table sooner rather than later, and working with you to make sure all the plumbing is there to connect things would be really beneficial to us. The licensing issue might mean you're probably not guaranteed a blessing as the standard archiving utility for Mailman, but that never stopped other projects like MhonArc! But... since you arrived around the same time GSoC started, I should ask whether you were hoping to do this as a GSoC project? It'd be a worthwhile project to put out there, but it might be lower priority for us than more direct development, since one of the goals of GSoC is to get new developers who are going to stay around and do future work with the project. Terri ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
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. But... since you arrived around the same time GSoC started, I should ask whether you were hoping to do this as a GSoC project? Perhaps it would make things more clear if I expledin why I'm here... I'm not a student. I've been working in software for 15 years, programming for almost 30 (since I was 9). I wrote large portions of eGroups / Yahoo Groups / Google Groups. I'm a successful post-Google entrepreneur. Since leaving Google I've been angel investing mostly in tech stuff (see my Angel List).. I've been donating notable chunks of money and time to open source projects (with my blender donations working out the best so far). Given my history, and the fact that I keep wanting to tear my hear out reading mailing list archives in pipermail, I thought I'd give you folks an archiver that would be nice. 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) ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
I think it would be a mistake to bundle any archiver with mailman3. Listing the available archiver options and their features and shortcomings would be a better way to go. -1 I think the majority of MM users will be simply using the RPM that comes with their distro, and there is a real benefit to stuff working right out of the box. This includes the Archiving functions. Its great to have options, and giving a list of possible alternatives for users is excellent, but I think releasing MM 3 without -any- archiver is a down-grade from the current MM 2.x. Bob ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 3, 2012 8:14 PM, Bob Puff b...@nleaudio.com wrote: I think it would be a mistake to bundle any archiver with mailman3. Listing the available archiver options and their features and shortcomings would be a better way to go. -1 I think the majority of MM users will be simply using the RPM that comes with their distro, and there is a real benefit to stuff working right out of the box. This includes the Archiving functions. Its great to have options, and giving a list of possible alternatives for users is excellent, but I think releasing MM 3 without -any- archiver is a down-grade from the current MM 2.x. I agree. If MM2 and pipermail is any indication of how often admins just 'leave the defaults', then bunding no archive interface with MM3 would mean most mailing lists would have no archive. I'd personally like to see a better archiver rolled into an MM2 point release, as well as upcoming MM3 development. (I understand pipermail URL compat would be nice in that case). ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 3, 2012 11:58 AM, Toshio Kuratomi a.bad...@gmail.com wrote: The question is would you BUNDLE another archiver even if the licenses don't match? 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. I'm just going to charge down the path I was on and finish up something that's a great drop in for MM2/MM3. I'll even try to add some pipermail URL compatibility. It'll be S-BSD, so (if you like it) the MM devs and the FSF can wrestle with issues of whether you want to bundle it as is, put a rubber GPL stamp on it, or just point to it like you would any other archiver. I honestly expected to have an updated UI to show by now. I've been busy with some code-restructuring, and an unbelievable amount of life-stuff came across my bow in the past week. It shouldn't be too long now. 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'm a bit scared of a world where MM3 does not include any archiver. If pipermail popularity is any indication of how often admins 'stick with the bundled defaults', we could have an unreasonable number of MM3 lists with no archives at all. Obviously the team is free to bless any archiver it wants, mine or others. Also, I'm certainly NOT trying to get anyone to agree to bless an archiver before they've even seen it working and kicking butt. I was just trying to understand the many issues as I'm cleaning up my code and trying to find it a home with a bit more utility. I think I have a great idea from all the disussions here.. THANKS! ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Wed, Apr 4, 2012 at 1:16 PM, David Jeske dav...@gmail.com wrote: On Apr 3, 2012 8:14 PM, Bob Puff b...@nleaudio.com wrote: I think the majority of MM users will be simply using the RPM that comes with their distro, and there is a real benefit to stuff working right out of the box. This includes the Archiving functions. I don't see why that precludes having the archiver in a separate recommended or required RPM, .deb, ebuild, or whatever dependency, and I imagine the distros can and will deal with that (as most of them use Mailman themselves, they'd have to do without dogfood). The problem as I see it is that many distros (I'm looking at you, Debian!) get woefully out of date, and their packaging often pays more attention to fitting in to the distro than to what we consider best practice. So users will often upgrade from our sources (and that is historically what we recommend). Also, many non-OS distros (*gag* *spit* Plesk *barf* cPanel) will roll their own derivatives (typically with little care for what we consider best practice). I'd personally like to see a better archiver rolled into an MM2 point release, as well as upcoming MM3 development. (I understand pipermail URL compat would be nice in that case). That, and automatic storage conversion to whatever the new archive UI prefers. The caveats above notwithstanding, at this point I'm definitely with David and Bob on this issue -- +1 for including batteries. I'd like to hear from Mark, though (even more so than from Barry; Mark is the guy who's been guiding people through upgrades on a daily basis for the last decade or so). ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On 12-04-03 11:08 PM, Stephen J. Turnbull wrote: 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. It occurs to me that it's perfectly reasonable to assume that people who *package* mailman for different distributions may choose different recommended/required archive software, since they can (and with the license hassle likely should)) be separate packages. So what works for the FSF, what works for us as a dev team, and what works for the distributions may actually be different things. So no matter what, having David release his work is potentially going to lead to people getting it as a default, somewhere along the line, if he's got a great solution available. People get something better than pipermail *and* it doesn't result in me getting more angry emails from RMS? Sounds like a winner to me. BTW, I *will* argue that we should have a bundled archiver that does something more than make mbox files, and you can all expect to have a big argument with me about it later. ;) But I'm not in a hurry to make a decision about which one Right Now because I'm going to want to do a deeper usability analysis of Postorius + archive and I can't do that until we have them both on the table for user testing. Terri ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
This thread is slowing down my coding! :)(it's been really helpful though all, thanks for the many perspectives!) On Tue, Apr 3, 2012 at 11:19 PM, Terri Oda te...@zone12.com wrote: It occurs to me that it's perfectly reasonable to assume that people who *package* mailman for different distributions may choose different recommended/required archive software, since they can (and with the license hassle likely should)) be separate packages. So what works for the FSF, what works for us as a dev team, and what works for the distributions may actually be different things. I agree I'm coming around to the sensibility of possibly not including an archiver with MM3, just so long as there actually ARE solid and working archivers that plug right in with nothing more than an apt-get (or equiv). It's just as fine if the distribution maintainers pick which one to include, and this gets around all this FSF/GPL/whatsit stuff... without bascally getting a pipermail default. I still think it's dangerous for people landing on Mailman's website and downloading source.. So no matter what, having David release his work is potentially going to lead to people getting it as a default, somewhere along the line, if he's got a great solution available. I know this thread is long and in pieces, but just to clarify, my code is already released and has been S-BSD for **ten** years. The UI is a little dated, so I'm cleaning up both the UI and the code right now, but I just want folks to know the code is already out there.. http://www.clearsilver.net/archive/ http://dj1.willowmail.com/csla/Mailman-Developers ...this discussion is all just about whether mailman wants to bundle (or reference) near-future updates to this stuff. I was hoping that rather than create my own separate OSS-y website and such for it, I could just hang out here and roll it into Mailman-land. You guys have done great work. If this GPL/S-BSD issue turns out to be a blocker, then I'll just make my own site and maintain (my version) there because I want to release my code S-BSD. Also, there will be *zero* ill-will if you folks want to wrap it up in a GPL license and stick it into mailman... i just won't be maintaining that, or assigning copyright, and any patches I make will be into my S-BSD tree. Perhaps not ideal, but still seems a better outcome than pipermail. ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Wed, Apr 4, 2012 at 3:56 PM, David Jeske dav...@gmail.com wrote: ...this discussion is all just about whether mailman wants to bundle (or reference) near-future updates to this stuff. I was hoping that rather than create my own separate OSS-y website and such for it, I could just hang out here and roll it into Mailman-land. You guys have done great work. I can't see any technical or legal reason why you would need to maintain a separate site. I would be more than happy to help maintain a Mailman-based site providing links to resources such as tarballs, VCS repos, and docs (this site would presumably be on the wiki) and a repo on Launchpad, which I think takes care of any social issues. It wouldn't be specific to the Clearsilver archiver, I'd do the same for any other archivers people care to recommend. As for a GPL-wrapped release bundled into Mailman, I'll do admin-level work to make that possible if the Clearsilver archiver is adopted and that's the way people want to go. I have experience with that kind of thing, and am happy to help lubricate that kind of friction. (I might be willing to do more hacking/maintainer-like work if people decide to make significant GPL-only enhancements, but I won't decide whether to do that until I've seen both the existing code and any such enhancements.) ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 02, 2012, at 08:04 PM, David Jeske wrote: The question i would you BUNDLE another archiver even if the licenses don't match? If you're donating the archiver to the GNU Mailman project, for us to maintain, release, bundle, and develop, then I think that would be a very high hurdle to overcome. Sorry, but it just is. I really don't want our developers to have to think about whether they can copy a chunk of useful code from the archiver to the core. Or whether they can refactor some web-ui code, developed under the GPLv3+, and re-use it as a library in the S-BSD licensed archiver code base. I know with absolute certainty that I personally don't want to have to think about stuff like that. Do you really want to spend your time trying to figure out all the insane legalistic conundrums that's going to bring up? 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. Which is fantastic, and which I fully encourage. One of the reasons why Pipermail is so ubiquitous is that it was bundled with Mailman 2.1. But another reason is that it was so painful to replace. Mailman 3's architecture fixes the latter, and `bzr rm` fixed the former. 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) I'm not going to spend time on this list arguing for the GPL. The bottom line is that the core, and by extension the web ui, are GPLv3+ and that cannot be changed. Having a different licensing and ownership regime for one component of the project will make our lives more difficult, and drain resources from developers who would rather hack than worry about legal crap. Probably the only way I'd change my mind about that is if RMS personally told us that we could still treat the non-copyleft donation the same way we treat all the other code, i.e. we can use the code and freely copy between them without any additional administrative overhead. Cheers, -Barry ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 03, 2012, at 11:58 AM, Toshio Kuratomi wrote: Distributed/pointed to by list.org along with mailman and postorius might be negotiable though :-) Absolutely. I'm committed to making it as easy as possible for an admin to integrate third-party FLOSS archivers with mm3. 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. A hearty +1 to all of the above. I know for sure that 3.0 final won't be held up for lack of a robust archiver. Having this conversation now is important for future releases though. Cheers, -Barry signature.asc 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 03, 2012, at 11:56 PM, David Jeske wrote: If this GPL/S-BSD issue turns out to be a blocker, then I'll just make my own site and maintain (my version) there because I want to release my code S-BSD. Also, there will be *zero* ill-will if you folks want to wrap it up in a GPL license and stick it into mailman... i just won't be maintaining that, or assigning copyright, and any patches I make will be into my S-BSD tree. Perhaps not ideal, but still seems a better outcome than pipermail. David, there's one thing that's not clear to me. If you donated the code to GNU Mailman and we bundled it under our banner, would you continue to maintain, develop, and release it as a separate project? -Barry ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 03, 2012, at 11:21 PM, Bob Puff wrote: I think the majority of MM users will be simply using the RPM that comes with their distro, and there is a real benefit to stuff working right out of the box. This includes the Archiving functions. Distros are of course free to make their own opinionated decisions about how components work together. Think about the rest of the email stack: a distro makes decisions about MTA, antispam, IMAP/POP servers, etc. etc. including how they all work together and how much effort it takes to configure and run those services. Heck, entire businesses are springing up over service provisioning. So I have full confidence that distros will make things way more easy for people than it would be if you had to download and install all the individual upstream source packages. I think our job as a project is to make that possible, and easy. A secondary job is to make our own opinionated choices where appropriate. We're not yet there with the archiver, IMHO. -Barry ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 03, 2012, at 09:16 PM, David Jeske wrote: I'd personally like to see a better archiver rolled into an MM2 point release, as well as upcoming MM3 development. (I understand pipermail URL compat would be nice in that case). I'd strongly oppose any change in default archiver for Mailman 2.1. I don't think it's possible to make that decision yet for Mailman 3.0. Including a default archiver for Mailman 3.1 should be a top priority. A web ui should be a priority as well! -Barry ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Apr 05, 2012, at 05:18 PM, Mark Sapiro wrote: I'd like to see a default install provide list owners with at a minimum a choice of public, private or no archives and the archives to be searchable. See also Jeff's first paragraph in comment #1 here: https://bugs.launchpad.net/mailman/+bug/967238 -Barry ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On 08-04-12 17:48 , Barry Warsaw wrote: On Apr 02, 2012, at 08:04 PM, David Jeske wrote: The question i would you BUNDLE another archiver even if the licenses don't match? If you're donating the archiver to the GNU Mailman project, for us to maintain, release, bundle, and develop, then I think that would be a very high hurdle to overcome. Sorry, but it just is. Would it work for everyone if David licensed the archiver to Mailman under the GPLv3+? (There could still be a question about the license for contributed patches over whether they could be pulled back into the main tree or not, but as long as it was reasonably clear one way or the other, I don't think it would be a problem in practice. On the other hand, I am an optimist... ;) Later, Blake. -- Blake Winton Thunderbird User Experience Lead bwin...@mozilla.com ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On 08-04-12 19:24 , Mark Sapiro wrote: On 04/08/2012 04:14 PM, Blake Winton wrote: Would it work for everyone if David licensed the archiver to Mailman under the GPLv3+? It won't work for David. See, e.g., http://mail.python.org/pipermail/mailman-developers/2012-April/021921.html Well, that's not exactly what David said. ;) (I'm not proposing he stops releasing it under S-BSD, just that he re-licenses the copy in Mailman as GPL. So he can continue to work on the code and release it under a permissive license, but Mailman can also use and distribute it. ) Later, Blake. -- Blake Winton Thunderbird User Experience Lead bwin...@mozilla.com ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On 04/08/2012 04:14 PM, Blake Winton wrote: Would it work for everyone if David licensed the archiver to Mailman under the GPLv3+? It won't work for David. See, e.g., http://mail.python.org/pipermail/mailman-developers/2012-April/021921.html -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Mon, Apr 9, 2012 at 8:27 AM, Blake Winton bwin...@mozilla.com wrote: On 08-04-12 19:24 , Mark Sapiro wrote: On 04/08/2012 04:14 PM, Blake Winton wrote: Would it work for everyone if David licensed the archiver to Mailman under the GPLv3+? It won't work for David. Well, that's not exactly what David said. ;) No, that *is* what David said, and repeatedly. He will not license under GPL, period. What he has also said is that he would be happy to maintain his original distribution in parallel to a GPLed branch bundled with Mailman. He would be willing to do a (very) small amount of work to keep them in sync, I believe, but his releases will be under simplified BSD so any contributions that he is going to maintain must be licensed that way. This matters because, in practice, if there are significant contributions under GPL to the Mailman branch, it will become a real (though friendly) fork, and we will lose the benefit of David's maintenance because we'll have to integrate his changes into our branch. He won't do that for us any more. I personally see that as win-win. Barry doesn't, presumably because (1) to keep David as maintainer means that contributions either need to go through him (implicitly making themm BSD), or we'll need to do some legal dance to explicitly relicense every such contribution BSD (since in practice our contributor agreement will make any contribution to Mailman itself GPLv3+ only), which (2) implicitly gives David veto power over the bundled archiver. The reason I see it as win-win is that I don't think there will be a lot of contribution from the current Mailman core to David's archiver. There clearly is a lot of enthusiasm for something with social networking features, and David's archiver doesn't look like a good platform for that to me. Eventually, the recommended (and bundled) archiver will be something else. (I'm not proposing he stops releasing it under S-BSD, just that he re-licenses the copy in Mailman as GPL. David doesn't need to do anything. We just copy the code and release it in Mailman under the GPLv3+ like the rest of Mailman. That's just a special case of the main reason for using a BSD license. So he can continue to work on the code and release it under a permissive license, but Mailman can also use and distribute it. ) There's nothing stopping us from doing that, not even the possibility of offending David. That's *why* he uses BSD in the first place, so we can do that if we want to. But he won't do it for us. ___ 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
Re: [Mailman-Developers] mailman / archive-ui / licensing questions
On Mon, Apr 9, 2012 at 6:48 AM, Barry Warsaw ba...@list.org wrote: On Apr 02, 2012, at 08:04 PM, David Jeske wrote: Probably the only way I'd change my mind about that is if RMS personally told us that we could still treat the non-copyleft donation the same way we treat all the other code, i.e. we can use the code and freely copy between them without any additional administrative overhead. He won't do that, because it's not possible. You cannot freely copy from a copyleft code base into a non-copyleft code base; you must indenture the latter. What we can do is branch the code, and freely copy back-and-forth between Mailman core and the code we got from the non-copyleft code base. The potential costs of that I point out in another message, so don't reply to this one. :-) ___ 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
