imap2soap.pl documentation

[fen]

I would like to document the imap2soap.pl script in its most recent incarnation, and suggest that it become part of the CiviCRM distribution.  I documented its predecessor at http://wiki.civicrm.org/confluence/display/CRM/CiviMail+Configuration#CiviMailConfiguration-qmailandmail2soap and now it is much more usable and friendly, thanks to input from Peter Hirst, Grigoriy Strokin and others.  I mentioned the new imap2soap.pl in a comment on http://wiki.civicrm.org/confluence/display/CRM/Alternative+configuration+-+no+Amavis+or+root+access but now it has been tested in real-world situations and I feel fairly confident that it is stable - at least in our qmail environment, but it should be MTA agnostic.

My question is where on the wiki should I add fairly detailed step-by-step installation and configuration documentation?  One of the URLs above?

[Donald Lobo]

Fen:

I would suggest archiving the second url (alternative config) and putting new detailed instructions there. And linking that to the main CiviMail config page

regarding making it part of the official CiviCRM distribution, i think we are open to it assuming that you'll are fine with the licensing stuff at: http://civicrm.org/licensing/. However, the bigger issue is support and bug fixes going forward. I suspect bug fixes will happen since you'll are using it in production. Are you willing to offer the community support on this part of the code? This does mean checking the forums and responding to issues people have, fixing them etc? I think its quite important for some group of folks to take ownership of that if it is included in the code base. Thoughts? comments? ideas?

lobo

[Piotr Szotkowski]

Also, if you can run some tests or at least sanely assert on what practical differences there are between using imap2soap.pl and AMaViS on a mass scale, it would be really useful; I think the imap2soap.pl approach is much easier to setup than the AMaViS one.

[fen]

The licensing is no problem, though I have it currently listed with the AGPL - please take a look and let me know if the copyright statement at the top of the file is sufficient: https://svn.civicactions.net/repos/civicrm/scripts/imap2soap.pl

I also won't mind providing some level of support for the code, though certainly not to the level of helping people configure their email servers!  I'll do my best to check the forums, but if I miss something that should be brought to my attention, please feel free to ping me.

One other issue I will need to clear up: Peter Hirst, J. Brush and others have been working on another version of imap2soap.pl and have been doing a good job providing support and documentation for it.  I think we have to have a meeting of the minds and create a single branch for us to work on.  Having a repository that we could write to would make this easier.  If CiviCRM can't provide this, we could provide access to a limited number of authors on the CivicActions repository.  Thoughts?

[Donald Lobo]

Fen:

1. You'll have to change the license to AFL and also add

Licensed to CiviCRM under the Academic Free License version 3.0.

for us to add it to the SVN.

2. Do u want to lead a meeting of the minds between brush/peter and u and come up with a single branch and support for this. Might make it easier  if u'll merge code bases etc and come up with one version of imap2soap in the civicactions repository and then we can move it into the official civicrm repository and code base. Considering we are a week away from code freeze, i suspect this will be make it into the 2.0 distribution (unless u'll come out with a unified code base / documentation in the next few days?)

lobo

[fen]

1. You'll have to change the license to AFL and also add
Licensed to CiviCRM under the Academic Free License version 3.0.
for us to add it to the SVN.

This probably won't be difficult - I'll consult with my team - but I'm curious: Drupal (for one point) is GPL and CiviCRM is AGPL -- why use a third license for contributions that may not be compatible with either (wikipedia says the FSF has not commented on the newer version 3.0.)?

2. Do u want to lead a meeting of the minds between brush/peter and u and come up with a single branch and support for this. Might make it easier  if u'll merge code bases etc and come up with one version of imap2soap in the civicactions repository and then we can move it into the official civicrm repository and code base. Considering we are a week away from code freeze, i suspect this will be make it into the 2.0 distribution (unless u'll come out with a unified code base / documentation in the next few days?)

I'd like to.  I have an email in to Peter - I don't know J. Brush's email address - on the old CiviMail list (he hasn't posted much in these forums yet).  I believe a conversation could go very quickly, as my version is basically their code with some new optional command line options that we found useful in our heavily-trafficked environments.

=Fen

[Donald Lobo]

From my limited understanding (usual disclaimers apply)

AFL is a more liberal license than GPL / AGPL and hence our lawyer (Larry Rosen) recommended it for contributions. This gives us more control over the codebase for the future if we need it. If you want the gory details as to how/why, you might want to chat with him/

Larry is also the author of AFL

I'll send u j. brush's email address via a personal email. If you get consensus and feel comfortable including it in 1.8, we can make that happen

lobo

[Piotr Szotkowski]

This probably won't be difficult - I'll consult with my team - but I'm curious: Drupal (for one point) is GPL and CiviCRM is AGPL -- why use a third license for contributions that may not be compatible with either (wikipedia says the FSF has not commented on the newer version 3.0.)?

We need AGPL because GPL 2 does not protect web applications properly; GPL 3 will (and AGPL is supposed to be compatible with GPL 3).

AFL, in turn, allows us to relicense your code ‘under any license of [our] choice that does not contradict the terms and conditions, including Licensor’s reserved rights and remedies, in this Academic Free License.’

2. Do u want to lead a meeting of the minds between brush/peter and u and come up with a single branch and support for this.

I'd like to.

I’d love to be Cc:ed (at shot@civicrm.org) if you don’t mind (although I most probably won’t contribute to the discussion).

[fen]

I understand the reasoning for your desire for the AFL, in that you need a "warranty of non-infringement."  However, we have a concern that should we license imap2soap.pl under the AFL - which is similar to the BSD license - this will allow others to use the code on their servers without contributing changes back to the community.

As some of the code is derived from amavisd-new - which is GPL - I think licensing under a BSD license may be prohibited.  And it may even be the case that we would need to keep the code GPL.   But as the AGPL is GPL v3 compatible, I feel comfortable licensing imap2soap.pl as AGPL - a stronger license than the GPL - which is your desired end goal.

Peter and I can sign affidavits that our code is patent free to satisfy any concerns of Mr. Rosen.

BTW: there's an updated release of the code at

• https://svn.civicactions.net/repos/civicrm/scripts/imap2soap.pl
• https://svn.civicactions.net/repos/civicrm/scripts/imap2soap.conf.sample

[Donald Lobo]

For the short term, lets keep the code in the CA svn and folks can download from there if needed. We avoid the licensing issue and details.

We've spent a fair amount of time and money on legal fees already and I'd like to minimize this for the near future (or at least till revenues increase some more)

lobo

[Piotr Szotkowski]

I understand the reasoning for your desire for the AFL, in that you need a "warranty of non-infringement."  However, we have a concern that should we license imap2soap.pl under the AFL - which is similar to the BSD license - this will allow others to use the code on their servers without contributing changes back to the community.

Just to clarify this here as well: we only need people to license their code under the AFL to CiviCRM, not to the whole world; that’s the whole point of AFL – the licensee is named (see point 14 of the license text).