[go: up one dir, main page]

|
|
Log in / Subscribe / Register

A beta release and a new license for Mailpile

By Nathan Willis
July 22, 2015

Mailpile is a free-software webmail client that has been designed from the start to provide top-notch security and privacy features. The project recently released its third beta, which improves setup and encryption-key discovery as well as streamlining the user interface. In addition, the project recently held a public discussion about the license under which Mailpile should be released, eventually settling on the Affero GPL (AGPL).

[Mailpile inbox]

To recap, Mailpile offers a somewhat unusual take on the traditional email program. It is designed to run as a web application (thus making it cross platform with a minimum of fuss), but it is a single-user application and is designed primarily to run on the local machine. Because each user runs a separate copy of Mailpile, it offers isolation. Also noteworthy is that Mailpile is a mail user agent (MUA), so a separate server is required to actually send and receive mail. But, because Mailpile downloads all messages locally, it can function offline and (at least in theory) offer better safeguards against security breaches of the server.

The project also puts a strong emphasis on integrating cryptography into the webmail experience. We examined the first beta release in September 2014, at which point its GnuPG integration was rather awkward in places. The team made a second beta release in January 2015, but withdrew it from the site in March after beta testers complained about IMAP and GnuPG issues (although the release is still available from the project's GitHub repository). The team subsequently scaled back their planned feature set.

Beta three

The third beta was pushed out on July 19, and is available in a source-code bundle for Linux and as installers for Windows and Mac OS X. Mailpile is a Python 2.7 application, though, so installation for the source is trivial. The dependencies are fairly standard and the required Python packages can be installed through pip. Of the other dependencies, the only worthy of note is that Mailpile still uses the GnuPG 1.x branch.

[Mailpile setup]

Among the significant changes in beta 3 is a simplified setup and first-run configuration process. All that the user has to do is select a language and pick a password that will be used to decrypt the local mail storage (i.e., a separate password from those needed to access email accounts). Email account setup has been simplified as well; the program attempts to detect the correct IMAP and POP settings based on the email address entered, and the setup process includes a GnuPG key-generation step.

The server-settings-detection step uses Mozilla's ISP database, so it should be as reliable as Thunderbird's detection (and similarly limited to public email providers). Local mailboxes are also supported by the account-setup tool, so users who already get their mail in mbox or Maildir format can make use of this release as well.

There are even more noticeable changes to the mail-reading interface—most are, again, simplifications. Previous Mailpile releases included a sometimes-confusing array of tagging and contact-management features that, as the release announcement put it, "seemed like good ideas but never quite worked." For instance, there used to be three separate buttons linked to the user's tag collection, plus separate "flag" and "favorite" features. The resulting interface is easier to navigate and the clutter is not missed.

[Key creation in Mailpile]

The new release also significantly improves the multiple-email-account experience, which was among the complaints with previous releases. There is now a "home page" that shows a summary of the configured accounts. Last but certainly not least, the GnuPG support now includes key discovery. The program will attempt to detect which email recipients use encryption or PGP signatures and try to fetch the corresponding keys from public keyservers. This is in addition to manually importing keys, which was already supported.

The program still has a ways to go before it is ready for production usage. Most notably, it lacks the security hardening required to make it usable from a remote server. Despite Mailpile's original design as a local client, this is evidently a feature that users repeatedly ask for.

License one

The other significant development from the past month is that the Mailpile team has finally decided on the license under which it will make releases. This is not an insignificant choice for any project, and the team took the unusual step of asking its users to weigh in on the choice.

In May, project lead Bjarni Einarsson posted an appeal to the community asking for its input. The options presented were the AGPL (version 3) and the Apache 2.0 license—which, at least in some respects, constitute opposite ends of the free-software license spectrum. Apache is renowned for its permissiveness, while AGPL is held up for doing the most to preserve copyleft. The preceding alpha and beta releases of Mailpile had been offered under both licenses while the team debated their merits.

In the initial post, Einarsson reiterated the usual arguments heard from proponents of each side: the risk of "marginalizing" the project by choosing the strong-copyleft AGPL, versus the risk of proprietary Mailpile forks by choosing the Apache license. In June, he summarized the feedback the team had received, quoting several blog posts and emails. Supporters of the project (in the financial sense) were encouraged to vote on the web site.

On July 2, the project announced the final decision: AGPL. Einarsson noted that AGPL "won" on a straight vote tally, albeit by a slim margin, and that Apache won when the results were adjusted by the dollar amounts of the supporters. But that latter result was skewed significantly by one voter's large donation; without it, AGPL won the dollar-adjusted vote by a slim margin, too.

Ultimately, Einarsson said, the slim margins and low turnout concerned him greatly, but he chose to go with the AGPL because he felt it was better aligned with the project's goals:

Mailpile is a project about freedom. It is not a popularity contest or a startup, it's not "industry infrastructure", nor does it aim to be. Mailpile is a political project which aims to improve the privacy and digital independence of individuals everywhere.

The Apache License is a wonderful thing, an open, generous, pragmatic, apolitical license. The AGPLv3 on the other hand, is a political and ethical line in the sand.

And so is Mailpile.

For now, it has not been announced whether or not additional beta releases of Mailpile will be made. For the time being, Einarsson plans to make incremental updates to the current beta release every two weeks or so, but he is also re-examining the roadmap. The final release could still take a while, but Mailpile has made clear progress in recent months, and now has a clear licensing plan going forward.

Index entries for this article
SecurityEmail


to post comments

A beta release and a new license for Mailpile

Posted Jul 23, 2015 7:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (17 responses)

And so in a year or two Mailpipe will die, since almost no commercial company would touch AGPL with a ten-foot pole.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 8:33 UTC (Thu) by Seegras (guest, #20463) [Link] (16 responses)

Why would a company have a problem with it? Not all companies want to sell some kind of "mail service". Some companies just need secure software for their own use.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 17:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

Even that is way too dangerous. For example, you integrate Mailpipe with your auditing and logging system. And BAM! you need to open your whole backend. It's just too risky.

In _all_ software companies I've worked so far, AGPL was explicitly Verbotten with no way of even getting lawyer-reviewed exemptions (even MongoDB required commercial licensing).

A beta release and a new license for Mailpile

Posted Jul 23, 2015 19:37 UTC (Thu) by jnareb (subscriber, #46500) [Link] (14 responses)

> Even that is way too dangerous. For example, you integrate Mailpipe with your auditing and logging system. And BAM! you need to open your whole backend. It's just too risky.

Bulls*it. First, for a project to fall under (A)GPL it must be in strict definition combined work - mere aggregation doesn't trigger. Second, for license to matter at all you need to distribute combined work - mere in-house use doesn't trigger.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 19:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> Bulls*it. First, for a project to fall under (A)GPL it must be in strict definition combined work
Linking-in an in-house auditing/logging module makes it a combined work.

> Second, for license to matter at all you need to distribute combined work - mere in-house use doesn't trigger.
Simply giving an off-site contractor an account in the mail system is enough to trigger the 'distribution' clause in this case ( https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.... ).

I've spent quite a bit of time discussing these points with our lawyers...

A beta release and a new license for Mailpile

Posted Jul 23, 2015 19:56 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (12 responses)

>Simply giving an off-site contractor an account in the mail system is enough to trigger the 'distribution' clause in this case

The FAQ is for GPLv2 and doesn't validate what you are claiming here.

" In particular, providing copies to contractors for use off-site is distribution."

> I've spent quite a bit of time discussing these points with our lawyers...

Your lawyers only represent the legal position within your organization.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 20:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> The FAQ is for GPLv2 and doesn't validate what you are claiming here.
I grabbed the first one. It's still there in the GPLv3 FAQ: http://www.gnu.org/licenses/gpl-faq.en.html#InternalDistr...

Uhm, excuse me, but I'll just quote the FAQ:
> "However, when the organization transfers copies to other organizations or individuals, that is distribution. *In particular, providing copies to contractors for use off-site is distribution.*"

For the AGPLv3 it's enough to simply give a link to the account (Article 13 of the AGPLv3): "Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version"

This is WAY too scary for companies.

> Your lawyers only represent the legal position within your organization.
If lawyers in several large organizations give me the same opinion, I tend to believe them.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 20:40 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

I have a different take on what you just quoted but if you have a legal opinion otherwise, you should probably rely on that but the following is more important:

>If lawyers in several large organizations give me the same opinion, I tend to believe them.

How do you know the opinions of lawyers in several large organizations on AGPL and does it confirm with your reading on it? This is a genuine question.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 20:43 UTC (Thu) by dlang (guest, #313) [Link]

besides the opinions of lawyers from several large companies

when the people who are likely to file lawsuits to enforce the license state in the license FAQ that they consider giving a contractor access to something "distribution" that triggers the source availablilty clause of the license you would be smart to treat that as being the case.

Even if they are wrong and that isn't really "distribution", until they either change their mind, or loose a case in court, you will be in the position of paying to defend a lawsuit on the issue.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 21:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> I have a different take on what you just quoted
Which probably will carry much less weight in court than the FSF's opinion

It's been a consensus for quite some time that distribution clause is VERY easy to hit. I've explicitly asked lawyers this question many times.

> How do you know the opinions of lawyers in several large organizations on AGPL and does it confirm with your reading on it? This is a genuine question.
Yes. AGPL was a topic of conversation several times and lawyers in multiple companies were quite adamant about that.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 22:20 UTC (Thu) by bronson (guest, #4806) [Link] (7 responses)

You have a different interpretation of language in the GPLv3 FAQ? I'd like to hear more. To me the language seems clear and agrees with Cyberax's statements.

Last I talked with lawyers about the AGPL, it was only a few years old, but they came to the same conclusion as Cyberax's: if you have AGPL and private code inside your organization, you need to tread VERY carefully and keep excellent records. For us, the showstopper was integrating single sign-on. The project was dropped. Frustrating, but I understand everybody's viewpoints.

A beta release and a new license for Mailpile

Posted Jul 23, 2015 23:10 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

>You have a different interpretation of language in the GPLv3 FAQ?

Like I said, if you have legal opinion that suggests otherwise, rely on that. Here is what I have experience with:

This is partially based on a project where public deployment was going to use some AGPL'ed code with related modifications (not direct code changes but authentication provided by third party code snippets) and contractors involved. The organization decided against that for other reasons but the initial consultation from a lawyer was that a contractor involvement wouldn't count as distribution. Now I understand lawyers being risk averse about this and all that but I was wondering whether this was just a abundance of caution of whether the language in the license was interpreted consistently in a particular way.

A beta release and a new license for Mailpile

Posted Jul 24, 2015 4:07 UTC (Fri) by bronson (guest, #4806) [Link] (5 responses)

Man, that's gutsy. If I receive a legal opinion that directly contradicts what the FSF is saying about their own license, I'd go back to the lawyer and ask, "are you sure??" (and pay the additional $$$ of course) I'd be very curious to hear your lawyer's answer.

Even if the license's language leaves doubt, interpretation or estoppel would likely encourage the court to take the FSF's side.

A beta release and a new license for Mailpile

Posted Jul 24, 2015 4:41 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

> If I receive a legal opinion that directly contradicts what the FSF is saying about their own license, I'd go back to the lawyer and ask, "are you sure??" (and pay the additional $$$ of course)

That additional expense would be pretty unjustifiable after one picks a different solution. It amounts to nothing more than idle curiosity at that point.

A beta release and a new license for Mailpile

Posted Jul 24, 2015 6:00 UTC (Fri) by bronson (guest, #4806) [Link] (3 responses)

Agreed. I meant, if you ever find yourself in this position again, I hope you'll report back. I'd love to hear any reasoning behind disagreeing with the FSF about the interpretation of their own license.

A beta release and a new license for Mailpile

Posted Jul 27, 2015 13:15 UTC (Mon) by drag (guest, #31333) [Link] (2 responses)

When you use legal terms like 'Derived Work' you are no longer the ones in charge of interpreting the license. These things are defined by courts, not by the license writers.

So it's very easy to be wrong about your own license.

A beta release and a new license for Mailpile

Posted Jul 27, 2015 18:33 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

However, if you end up having to go to court to defend your reading of the license as being different from what the authors of the license very publicly state, it can cost you quite a bit of money, even if you win.

Not to mention the bad PR.

There needs to be a VERY big upside to using that particular software instead of some other choice to make the risk worthwhile.

A beta release and a new license for Mailpile

Posted Jul 27, 2015 19:23 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

There is also the question of how the developers interpret the license when it is different from the interpretation of the license authors themselves. My understanding is that the copyright holders view is the more relevant one.

A beta release and a new license for Mailpile

Posted Jul 24, 2015 1:36 UTC (Fri) by branden (guest, #7029) [Link] (1 responses)

I can't concur with Cyberax's hyperventilation.

Where I work, AGPL is viewed with great caution, but it's not even the "worst" FLOSS license.

That title would go to the Sleepycat Berkeley DB license (now administered by the friendly folks at Oracle).

I think a lot of people glaze over at that one when they see the first 2 clauses, which are obviously from the good old BSD license.

But watch out for that 3rd clause--it's a doozy.

A beta release and a new license for Mailpile

Posted Jul 24, 2015 4:01 UTC (Fri) by bronson (guest, #4806) [Link]

Here's an article talking about the Sleepycat -> AGPL transition: http://www.infoworld.com/article/2611450/open-source-soft...

There's just no pleasing some people. :)


Copyright © 2015, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds