Chancing license to a more liberal license

[bkolb]

Please consider changing your license or dual-license your project under a more liberal (business-friendly) license.

[smari]

@bkolb can you please elaborate in which way the AGPL license is hostile to businesses?

[public]

Why do you consider Mailpile's AGPL license to be business unfriendly? It gives you a clear basis to conduct development on and protects your users from being locked into competitors deployments.

[BjarniRunar]

Allow me to defuse the snark a bit... :-)

We have discussed this, and didn't come to any strong conclusion. Basically, the AGPL is way more in-line with the privacy and freedom ideals which are the roots of this project, we have absolutely no interest in building software which makes it easy for some cloud provider to become the next GMail, locking in their users data somewhere in the cloud. So that is a strong vote against more "business friendly" licensing.

On the other hand, a major facet of fixing the current problems with e-mail is encouraging decentralization. A million little GMails would arguably be better for the ecosystem than the current situation, even if they are all closed and proprietary.

We decided to err on the side of freedom this time and stand up for our users (not the developer community, the end users) by using the strictest license. However, if our community of backers disagrees with this stance, we will listen and consider a license change. We don't yet have any of the infrastructure in place to have that discussion, but we probably will later this fall. A reasoned debate, followed by a vote between licenses is something we would be quite happy to facilitate and abide by the final decision.

[bkolb]

The problem is that all extensions (not modifications to the original source code) are infected by this license as well. This means that one cannot build commercial (closed source) extensions. I'd hope for a license like the EPL (Eclipse public license) which is still copy left but allows commercial add-ons.

While writing my comment @BjarniRunar posted his. His proposal sounds reasonable to me.

[smari]

I agree with what @BjarniRunar says, and am very much in favor of our community members making the call. I just wanted to throw out a couple of observations I wrote down in the meantime:

We are trying to replace centralized infrastructures such as GMail. We are trying to do that on the back of features and usability. If we use Apache, then there is nothing to stop, say, Google (although I really hate to be picking on them!) from incorporating all of our features as we spin them out, and apply a dozen or so developers to making it better than ours, i.e., the decentralization objective could be jeopardized by our centralizing competitors being given the ability to stay ahead of us without trying.

Now, here there is the very valid counterargument that if they are providing better software, it's natural for us to lose, on the basis of free market principles. This is why GMail has won over Hotmail - it is substantially superior software with a better service offering.

On the other hand, we need to decide whether we are developing Mailpile on the basis of free market fundamentalism or decentralization fundamentalism. While I subscribe to both to a degree, I think Mailpile is squarely in the latter category, with any free market objectives being secondary - meaning that if aspects of the free market might contradict or harm the decentralization goal, then those aspects can legitimately be blocked.

Now, that said, I do agree with @bkolb that it would be nice to have a strong copyleft license that still allows for commercial add-ons within a certain scope, and this is actually where I'd like to draw a perimeter around Mailpile's internals that excludes the plugin interface on the one hand and the themes on the other, so that people can develop their own themes and plugins without necessarily having to push them back. It is hard to imagine any AGPL enforcement suits ever happening on the basis of somebody not having shared back a theme to the community, but I would really like to extinguish all doubt about that from the getgo.

Just my two cents. But folks, let's keep this discussion goal-oriented. :-)

[public]

I strongly disagree that extensions or themes should somehow get special license text. This is not required for the distribution or sale of commercial extensions. It is only required to provide extension authors with some degree of vendor lock in power. I'm not trying to be fundamentalist, I'm just not convinced it's required to meet the needs of many developers.

e.g. I suspect certain classes extensions may be well served by a call back based API that would not turn them into derivative works of Mailpile. Then extensions that desire non-AGPL license could easily avoid calling AGPL code themselves.

Themes are probably a little harder but the project could make a statement that the use of theme API does not infect your theme with AGPL requirements just as the Linux kernel developers have with user-space APIs.

[bkolb]

The problem is, that if you talk to layers it does not matter what the developers state. It is just what is in the license (and this is still pretty vague as you probably know because there has never been a case where those things have been fought through) (I've been through that several times...)

I think in the end, to be successful you'll need as many people as possible using it if your goal is to make mail more secure again. To do that you need help from some of the mail providers (not the big ones in the first place, but the many small and medium ones) But they as well need a chance to distinguish themselves from their competitors (not only by a price tag)

But as mentioned above, let's decide on that when appropriate.

[tomleo]

I'm confused as to why AGPL isn't "business friendly". Businesses could use the software internally or provide it as a services if they wish. It seems like the only thing AGPL does is ensure that changes made to the code will be shared with everyone. Also what is a commercial add-on and why would it require different licencing?

[public]

@bkolb The GPL has been tested in court in various ways, the linking issue doesn't have a lot of case law though. My general point is to try and show that there are more ways to cope with the AGPL than simply turning it off for bits that seem scary.

The FSFs opinion on linking to GPLd code is quite clear. http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.

This particular configuration can often be avoided through technical means so I am unclear as to why any form of selective licensing is needed.

I'm not trying to make any decisions @bkolb, I'm just trying to work out what problems you perceive the AGPL causing for you :) I suspect many of them have work-arounds.

@tomleo I believe the use-case is 3rd party email hosts etc who may want to offer Mailpile as a feature to their users. I can imagine they'd want to extend it to try and differentiate their product.

[tomleo]

@public Does that mean adding Mailpile as a service under the AGPL require the underlining system to be libre as well? For example if I owned a web hosting company and added Mailpile to my clients cpanels (with one-click integration) then would my whole software stack have to be libre? Writing plug-ins seems like kind of a grey area as the way the software is written dictates the licencing freedom the coder has.

[bkolb]

Not if you just integrate it with a URL schema. But if you build e.g. a calendar integration where you'd like to make use of the en-/decryption capabilities it would have to be...

[public]

@bkolb Unless Mailpile has a CalDav front-end so integration doesn't even need to touch Mailpile code it's self.

[bkolb]

@public Well, yes... If milepile supports everything there is no need for extensions :-)

One option (even if CalDav is supported would be a plugin which scans your mail text and extracts potential meetings.

e.g.

Should we meet next Thursday

There are all kinds of things one might want to contribute through a plugin api. I hope we agree that far :-)

[markwilcox]

An additional issue to consider with the AGPL license (or any strong copyleft without an appropriate exception) is that it's incompatible with distribution on the Apple App Store. That means we couldn't e.g. port some of the core python code to C/C++/Obj-C and use it in an iOS native client.

Two ways around this issue would be:

1. Add a specific exemption to allow Apple App Store distribution.
2. License the core parts that would make sense to port into a native client under a more permissive license that is AGPL compatible while keeping everything related to the web mail UI AGPL. The viral nature of the AGPL would then make the whole thing subject to the terms of the AGPL when deployed on a server as a web mail solution but the core parts could be ported and re-used elsewhere.

With (2) I'm assuming that decent performance for indexing and search are not the main differentiating features and it's actually in the interests of the project to enable a proliferation of compatible clients with integrated encryption but different licensing models. I don't know if that assumption is correct.

[ghost]

If AGPL is verboten from places like the Apple App Store what about licenses such as the Mozilla Public License?

On Thursday, August 15, 2013 at 12:16, Mark Wilcox wrote:

An additional issue to consider with the AGPL license (or any strong copyleft without an appropriate exception) is that it's incompatible with distribution on the Apple App Store. That means we couldn't e.g. port some of the core python code to C/C++/Obj-C and use it in an iOS native client.
Two ways around this issue would be:

1. Add a specific exemption to allow Apple App Store distribution.
2. License the core parts that would make sense to port into a native client under a more permissive license that is AGPL compatible while keeping everything related to the web mail UI AGPL. The viral nature of the AGPL would then make the whole thing subject to the terms of the AGPL when deployed on a server as a web mail solution but the core parts could be ported and re-used elsewhere.
   With (2) I'm assuming that decent performance for indexing and search are not the main differentiating features and it's actually in the interests of the project to enable a proliferation of compatible clients with integrated encryption but different licensing models. I don't know if that assumption is correct.

—
Reply to this email directly or view it on GitHub (#78 (comment)).

[public]

Is porting Python to ObjC a thing people actually do? Seems unlikely.

In any case as long as the Mailpile team are assigned copyright of contributions relicensing to keep the Appstore gods happy remains trivial afaiui.

[markwilcox]

If AGPL is verboten from places like the Apple App Store what about licenses such as the Mozilla Public License?

Most popular open source licenses are fine with the App Store, it's really just the GNU licenses, which go far beyond making the code available and add clauses to try to ensure that you can modify and tinker with the specific instance that has been delivered to you. That's incompatible with the T's & C's on the App Store, and also probably Apple's use of DRM. Personally, I don't see much problem if you get all the code and can rebuild your own version with your modifications in the case of an app - although I understand why those terms are included for things like embedded firmware.

Is porting Python to ObjC a thing people actually do? Seems unlikely.

Python to Obj-C is pretty unlikely but python to C is not uncommon and there's even a suggestion on the roadmap that some of the Mailpile core might be ported to C for performance reasons. A C version would be usable across almost all native platforms.

In any case as long as the Mailpile team are assigned copyright of contributions relicensing to keep the Appstore gods happy remains trivial afaiui.

It's much better, in terms of not creating hoops for potential contributors to the project, to get the licenses right in the first place than require a contributor agreement with copyright assignment before anyone can fix a bug even.

[public]

Most popular open source licenses are fine with the App Store,

IANAL (and I guess you aren't either) but this doesn't seem entirely certain to me. e.g. the MIT license also includes language about "without limitation the rights to use, copy, modify, merge, publish, distribute..." which would be incompatible with Apple's restriction on redistribution of Apps. Just no one has made a fuss about it yet.

python to C is not uncommon

I can imagine almost no circumstances under which Python code developed for the Mailpile server would be useful in a mobile client in any form.

The have very different requirements and perform different roles to the user. I guess any HTML and JS might be vaguely useful if you were doing an implementation based on iOS WebViews but this doesn't seem like a major barrier to work around and would probably not deliver a particularly great experience to the user anyway.

get the licenses right in the first place

If you don't get copyright assignment enforcement of any license can be difficult in various important jurisdictions. e.g. the USA. This is why the FSF (and basically every company that ships open source software) require copyright assignment from contributors. http://www.gnu.org/licenses/why-assign.html

[markwilcox]

IANAL (and I guess you aren't either)

Nope, not a lawyer but I did work for an open source software foundation so have spent a long time on this topic.

the MIT license also includes language about "without limitation the rights to use, copy, modify, merge, publish, distribute..." which would be incompatible with Apple's restriction on redistribution of Apps. Just no one has made a fuss about it yet.

Don't confuse the rights which the license grants you with the rights it tries to guarantee for anyone you give copies to. The MIT license gives you those rights and the right to pass those rights onto others but it only requires that you include the copyright notice in return. If the MIT license were enough to protect those rights for everyone then the legal horror show of the GNU licenses would not need to exist. I've spoken to a number of copyright lawyers about the GPL and the only thing they can all agree on is that it doesn't mean what the authors intend it to. It is however such a mess that any company big enough to have a legal department will go to significant lengths to avoid getting tangled up with it, which most of the time has the effect that the authors were looking for in the first place.

I can imagine almost no circumstances under which Python code developed for the Mailpile server would be useful in a mobile client in any form.

Are you a mobile app developer (I am) - if so, you're not imagining very hard. Mailpile isn't a server in its first incarnation, it's a mail client. The core of the code currently deals with indexing and searching mail. I assume in future it will evolve into the best open implementation for doing that securely and with decent performance when the mail itself is encrypted. Personally I'd want all of that functionality in native mobile clients.

If you don't get copyright assignment enforcement of any license can be difficult in various important jurisdictions. e.g. the USA.

This is overstating the case - any contributor owns the copyright to part of the work and can enforce the license - if they only contributed a small part it would be easier for any license infringer to work around (e.g. replace) their code. The major contributors to a smallish project like this would likely own the copyright to most of the work and would probably not have any trouble enforcing the license.

This is why the FSF (and basically every company that ships open source software) require copyright assignment from contributors.

Yes, companies who create open source software do not usually build large contributor communities as they intend to develop most of the code themselves. They also often sell closed source commercial variants of the software and need to own the copyright to do that. My understanding is that this is a much more traditional FOSS effort where a more broad contributor community would be of greater value than the strongest possible legal position. The FSF is a bunch of lawyers, so obviously they go for the strongest legal position - they also haven't developed anything new that any significant number of people uses in a very long time - look at the wild interest out there in Replicant.

IMHO, this project has massive potential to enhance security and privacy for a LOT of people online and being too purist on the free software side could derail that. That said, I think AGPL is the right license for the project as a whole. I'm just recommending a more permissive license to enable relevant parts of it to be re-used in other contexts. As I see it, this is a case of project prioritisation - secure/private mail for everyone that wants it or the strongest guarantees of software freedom.

[deptadapt]

I hope that the project sticks with the AGPL. It seems to me that Mailpile is about protecting users which is what the AGPL is designed to do.

[coolya]

The GPL family is not designed to protect any user, it was designed by Stallman because he was pissed that his friends didn't wanted to share the changes they made to LISP. And is by far the license family that causes the maximum hassle for anyone who want to use a peace of software beyond the use case it was designed for.

I would not suggest using a non copyleft license like Apache oder Eclipse but I think CDDL and MPL are good compromises to gain both, freedom for developers and protection for users. Any changes to existing code(files) have to published while proprietary extension (not modifications) are still possible.

[tomleo]

@coolya RMS wasn't pissed because his friends didn't want to share their LISP changes, he was pissed because Symbolics Inc. completely destroyed the hacker ethic at the MIT labs. The features made by the team at Symbolics were singled-handedly reverse engineered by RMS and shared with Lisp Machines. I seriously question your understanding of both software licensing and the philosophy behind copy-left. Also how can you make a distinction between a user and a developer? Seems to me that developers are simply a sub-set of users.

[bkolb]

@tomleo Let's not get personal.
I think there is a big difference between a developer and a user.
In fact most users do not care at all about the license. The only things they are interested in are

• is it free?
• is it maintained and under continued development?
• is there a vivid community around?

Developers (should) care about the license. And some / many of them have, because of their background and maybe professional experience, problems with the GPL-family of licenses. (While for most LGPL is acceptable). I think there is no good reason to for a project to limit itself to the to one group of contributors, especially given that there are licenses available which do not have the (maybe only perceived) problems of the GPL while still sticking to the main goal of GPL to getting changes back into the original source code.
The argument of "no lock-in" is a very weak on as far as I am concerned. First of all, it is up to the user to decide. If there is a good, solid foundation chances for such a lock-in are low anyway. Second, what user's are most concerned about is their data. In the end we are "just" talking about a client here. So if the foundation offers a good (generic) persistence there will be no lock-in of users. (In the worst case you take another client to present your data)

There is another argument agains the GPL/AGPL. It is incompatible with other licenses. This limits the libraries one can use and thus leads to a higher development effort. It is up to you how much value you assign to it, but I think it's certainly an argument to keep in mind.

[BjarniRunar]

I am going to close this issue. Civility is being stretched here and considering that nothing is going to be decided on this thread anyway, I propose we stop wasting our time.

The current license is the AGPLv3. This is the license preferred by the majority of the core team as it most accurately reflects the high-level goals of the project. We don't have any particular interest in enabling proprietary extensions. This is a Free Software project, why would we want that?

The two reasons I can think of for changing licenses would be to solicit contributions from "GPL hating developers" (of which there are many) or for strategic reasons to do with enlisting corporate help in our goal of decentralizing the overall e-mail landscape (think standards: the best way to foster a new standard is to publish a working reference implementation under a very liberal license). Considering the groundswell of support we've gotten so far, the first issue doesn't seem pressing to me, but the jury is still out on the second.

If we do change licenses, it will be after the campaign has completed, we have had time to give the issue more thought and are able to meaningfully ask our backers what they want (as mentioned in my comment above). So until then, let's focus on other things. Thanks! :-)

[howardroark2018]

Hello, I just went through everything in the thread and read the license and copied-license files of the project, where it mentioned that the project is infact dual licensed under the AGPL & Apache 2.0. I added that , a decision was due for January 2014. So, I am a bit curious as to the further developments regarding the discussions.

PS: I apologize, in case me-posting on this closed thread is found indecent by anyone.

[howardroark2018]

:(:(

[wolftune]

I know this will never be simply resolved, but just want to put in my vote to urge staying strictly AGPL.

The strategic choices are valid considerations (work with the proprietary developers because it could mean more total success for the project), but a great project will attract developers simply because they like the project. Many of us will support it more because of AGPL assuring us it won't be co-opted by proprietary interests, and that might be more people who will avoid it because they are so annoyed that they can't co-opt it or build proprietary extensions.

By the way, I'm not really a programmer myself. I care about licenses. This is not about the public / users not caring. I hope you stick with AGPL, thanks.