Choosing a License for Mailpile 1.0

Tags: #<Tag:0x00007f7cc0fdc098>

The Mailpile folks posted a thorough and thoughtful post about why they would license Mailpile one way or another.

I hadn’t heard of Webkit being used as an example, but it is very interesting:

An excellent example of permissive licensing, is the Webkit project.

Webkit is based on KHTML, which was published under a relatively permissive license (the GNU Lesser General Public License). I say relatively permissive, because although the LGPL allows use within proprietary products it does require that motifications to KHTML itself be given back to the community. This balance allowed Apple to create Safari, a proprietary browser, while forcing them to publish the engine they derived from KHTML - an engine which we know today as Webkit.

Webkit was then chosen by Google for use in their Chrome project, and the rest is history: Webkit, daughter of KHTML and Apple, has taken the lead as the world’s fastest and most powerful HTML5 rendering engine. It is now not only at the heart of both Safari and Chrome, but is used in a wide range of other smaller browsers and open source projects.

This is a fantastic open source success story, and it’s worth remembering that this would probably never have happened if KHTML had been licensed using a more permissive license, such as MIT, BSD or Apache - those license would have allowed Apple to keep their improvements to themselves.

But there are more lessons to be learned here!

Today Safari and Chrome are both provided free of charge, but they are proprietary programs and the community does not have access to their inner workings. Amongst other things, this means the community cannot easily inspect or audit how and when these browsers “phone home” and share private data with the companies that wrote them.

It can also be argued Webkit’s license perpetuates the status quo and unfairly skews the market against truly free software. Compared with these truly free alternatives, Chrome and Safari will always have a head start because Google and Apple can keep some of their innovations to themselves.

Of course the counter-argument is, that without the motivation for big companies to collaborate, Webkit probably wouldn’t exist at all.

Their roadmap links to some opinion pieces as well. @mlinksva, have anything in yer back pocket to send their way? :slight_smile:

I did pump something snarky on this already: if they’re going to put resources into enforcement AGPLv3+ else Apache2.

First order, it doesn’t matter. The impact of license choice on the project’s impact on helping people achieve software freedom (and other related goals of the project) will be utterly swamped by other factors, many characterized by how well they execute on their roadmap, including excellence of the software, business development, and fundraising.

Not entirely tangentially, after replying I’m going to move this post from the software category to the policy category. I’m going to try to constrain license-centric discussions to the latter, as I consider them brain rot, and the only way to pull them up from such is to put them in the context of policy, including public policy.

Speaking of which, here’s another rubric for making a decision: do those involved in the Mailpile project feel that anyone providing email software as a service should be forced to reveal the source code used for running such services? If yes, they should choose AGPLv3+, as it is a private regulation which prototypes this public policy. If no (perhaps because they consider such force wrong and/or necessary, perhaps because they feel market competition will provide enough transparency without regulation), they should choose Apache2.

BTW I noticed that Roundcube (AFAIK by far the most widely deployed free software webmail interface, though not who I hope Mailpile sees their primary competition as – that would be proprietary webmail and proprietary post-email services) is doing a crowdfunding campaign right now for Roundcube next, which at a glance I take to be a technology and UX upgrade attempt. Their license is GPLv3+ w/permissive exception for skins and plugins. This doesn’t closely model either regulatory or deregulatory policy for email services above (not that AGPLv3+ and Apache2 are purely regulatory and deregulatory either, but they fit much more closely in those boxes for services than does any weaker copyleft), but it seems to have worked at least somewhat for for the project – I mean to the probably overwhelming extent this choice hasn’t been overwhelmed by everything else about the project. :slight_smile: