Choosing a License for Mailpile 1.0 | Hacker News Reader

Choosing a License for Mailpile 1.0

mailpile.is

30 pointsHerraBRE33 comments

Please choose the AGPL3+! A strong copyleft is important for ensuring that the users of a Mailpile instance actually receive the freedoms that you intended for them to have.

If they do copyright assignment, it also opens the possibility of selling exceptions, which may become a revenue stream. Reputable software like Qt and FFTW has gone this route.

I'm gonna go donate so I can record my vote for AGPLv3.

We already set fire to that bridge, most deliberately. It burns as we speak. :-)

We've accepted various patches from people, all of which were under both the AGPLv3 and Apache licenses. We now have the choice of dropping one of the two licenses, by making all new code only available under one of them.

But we can't apply new licenses or change the terms without reaching out to a growing number of folks and asking their permission...

Oh well. I still prefer AGPLv3. I wonder why did you refuse to allow selling exceptions?

Deliberately relinquishing power means we can't be corrupted. :-)

If the backer community wants closed source versions to exist, we feel it should be on even footing based on a permissive license, not based on the whims of the founding team.

Also, copyright assignments are a burden which makes people less likely to contribute in the first place. We don't want any such burdens, getting folks to take part is hard enough as it is.

Copyright assignments haven't really slowed down Emacs contributions, which has hundreds of contributors over the years. And for those who don't or can't do the assignment, well, there's a huge group of people who are doing Emacs packages outside of core. Emacs's extensibility helps here.

As to corruption of power, you can include in the copyright assignment contract that you will only ever use the copyright to give specific individuals the same rights as they would have under some permissive software, except for the right to give it without copyleft to someone else. Allowing people to create non-free derivative works via a license exception is no worse than allowing people to create them via lack of copyleft.

Not that it matters, like you say, but I feel very strongly about selling exceptions. It's no worse than free software without copyleft, and it opens up a revenue stream most projects decide to simply relinquish.

There's a big difference between a 501(c)(3) non-profit like the FSF asking for copyright assignment, and a for-profit corporation doing the same.

The latter creates an uneven playing field, and other corporations are generally loath to assign their "IP" to a competitor, which tends to prevent the mutually beneficial collaboration that is the biggest advantage of successful open source projects.

> Deliberately relinquishing power means we can't be corrupted. :-)

Nicely done!

I'd argue Apache license here. Making mailpile AGPL will limit your contributors, limit the distribution of your product, and limit the people willing to commit to it. Because of the restrictions the AGPL places on software, I wouldn't use it for personal projects, and definitely wouldn't use it for any commercial projects. Putting mailpile as AGPL would just make me look at other webmail clients like horde; the compliance costs are just too high for a webmail client.

There seems to be an issue with different companies interpreting the AGPL differently. This question on StackOverflow and the discussion that follows explore the issue with regard to MongoDB and Neo4j: http://stackoverflow.com/questions/6500925/agpl-license-ques.... If Mailpile goes with the AGPL I would urge them to offer a clarification as to which interpretation they have in mind. MongoDB's one seems more reasonable to me but I am not a lawyer and one's "reasonable" is not the same as "would stand up in court".

Once upon a time... my company had to choose some html editor to use in some system that would be used by the Judiciary system of the whole country. One good software was released under AGPL. Due to many discussions about understaing what were the consequences of that licensing, we gave up and used another one. After some while, we saw that the software was re-released under another license, but it was too late.

Since they were in the beginning of the software, we would contribute a lot with it. AGPL was a no-go in that case. I would step back of it.

Yes, strongly agreed. Without guidance from you about what constitutes a derived work, private entities will be left with the most extreme interpretation: anything that touches the program in any way is a derived work. If you select the AGPL, I strongly recommend doing what RethinkDB has done: be very, very explicit. From their FAQ[1]:

We chose to release the client drivers under the Apache License v2.0 to remove any ambiguity as to the extent of the server license. You do not have to license any software that uses RethinkDB under AGPL, and are free to use any licensing mechanism of your choice.

Absent this, expansive (and frankly, deranged) notions of a what constitutes a derived work will prevent AGPL-licensed software from going places that its authors likely did not want to prevent.

[1] http://rethinkdb.com/faq/#how-is-rethinkdb-licensed

The intent is stated as:[0]

The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run the program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the program that it's running. If what's running there is your modified version of the program, the server's users must get the source code as you modified it.

I'm assuming MongoDB's interpretation comes from Section 13:

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 by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

Which is pretty clear: this only applies to modified works. Further, under Section 2:

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

where "convey" is defined in Section 0 as:

To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

So there is an inconsistency between the stated intent of the AGPL, and what the license actually states. I'll ask FSF/RMS for clarification.

[0]: https://www.gnu.org/licenses/why-affero-gpl.html

>I'll ask FSF/RMS for clarification.

Thanks. Could you post the clarification here once you get it?

Will do. It might be a day or two.

I'm pleased to say that this matter has been resolved unambiguously. Recall above that the ambiguity I pointed out was between the description of the license[0] and Section 13 of the license itself[1]. RMS has updated the former (see my above quote for the original) to read:

> The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.[0]

Here is the applicable part of RMS' reply to me:

  > Section 13 in the AGPL states the real conditions.  The
  > why-affero-gpl.html has an error.
  > 
  > It is a general principle that, if the license words  are clear, they
  > override explanation elsewhere.
  > 
  > As regards the philosophical question, I don't remember any more
  > why we decided 8 years ago to apply section 13 only to modified
  > versions.  I don't see any strong reason in favor of either choice.
  >
  > I corrected the page why-affero-gpl.html.  Thanks for reporting the
  > error.

Hope that helps.

[0]: https://www.gnu.org/licenses/why-affero-gpl.html

[1]: https://www.gnu.org/licenses/agpl.html

To the siblings suggesting that the publishers clarify their interpretation of the license, this is not how copyright law works. You do not get to define the interpretation of the license you utilize. A court will decide that if/when an issue ever goes to trial.

At best you are saying "I promise that I won't pursue legal action in situations conforming to these criteria." This is not legally binding, and as such interpretation would be external to the license, would likely make no impact on a third party's decision to use or not use the software.

If the goal is to eliminate an ambiguity in the license, the solution is another license, not the ambiguous license plus a promise.

> At best you are saying "I promise that I won't pursue legal action in situations conforming to these criteria." This is not legally binding,

Actually, promissory estoppel is a thing: http://legal-dictionary.thefreedictionary.com/Promissory+Est...

Cool. I did not realize that.

I do think that the court case would just devolve to interpreting the circumstances described in the promise. At the end of the day, my point is that a contract or a promise is only interpreted by the court. One cannot make legal opinion in the form of a contract or a promise.

AGPL3 maximizes options down the road. You can start AGPL3 and loosen it up over time. Lots of security projects have tried to go the other way, and the result has always been a mess: all the permissively licensed open source I've seen try to vector back towards GPL has created viable, hostile forks.

Is it possible you haven't seen the same result the other way because it's pretty rare for that to happen in the first place? I can't think of any examples off the top of my head.

Also, it seems like getting contributor agreement to license under a more permissive license than they contributed under might be rather more difficult. To use an extreme example, if you accept a patch from RMS it seems extraordinarily unlikely he'll ever agree to let you relicense his contribution as BSD.

I guess if you have a really solid CLA...

Everything else aside: you fundamentally can't make code released under Apache more restrictive down the road, but you can make code released AGPL3 less restrictive. Permissive licensing is forever, restrictive licensing isn't.

Not sure about that, see my reply to your original message.

As for "you fundamentally can't make code released under Apache more restrictive down the road", isn't that exactly what LibreOffice (LGPLv3) people do when they import patches from Apache OpenOffice (ALv2)?

You have it exactly backwards. Without relicensing, you can't ever revoke the conditions of the GPL and allow proprietary things. You can always make non-copylefted code more restrictive, e.g. you can make it proprietary.

I am referring to relicensing, which is meaningful for AGPL3 but not Apache.

I guess I don't know what you mean by "relicensing". I meant that the original copyright authors decide to change the license. The original copyright authors are always free to change the license to whatever they damn well please, in any direction they want, more restrictive or less restrictive.

What do you mean by "relicensing"?

What the Mailpile contributors are doing isn't exactly relicensing. They're just agreeing that from now on their future contributions will be under only one of the two licenses that were a choice in the past. If they choose the Apache license for all new contributions, they can still in the future decide that they want all contributions from that future on to be AGPlv3. If they choose AGPLv3, they can never again without relicensing decide that contributions are no longer copylefted.

I am thus still unable to interpret things as you explain them.

My understanding is thus:

The work is published with a particular license, and that cannot be changed. However, the creators may republish the work with a new license. If this happens third parties can choose which work they want to use, the original published work or the second published (identical) version. By saying that license can only get less restrictive, we mean that people can always choose to use the least restrictive license a work has been published under.

If I have some egregious misunderstanding please correct me.

That's what I'm saying. It's true that getting consensus for license changes is hard, and that (unless you're willing to rewrite some code) relicensing of projects with diverse contributors requires that consensus. But consensus is required in either scenario.

Meanwhile: once you publish something MIT/BSD/Apache, it's MIT/BSD/Apache forever; when you try to GPL it, people will simply fork from the MIT code. See: OpenSSH.

Oh, I see. You mean forking the older version.

Sort of, I suppose. A recent example I've been monitoring where this hasn't worked very well is Rhodecode. It was originally GPL'ed and then got locked up into proprietary software (through lies and subterfuge, I must add). The Mercurial folks took the last clearly GPL'ed version and forked it into Kallithea. But Kallithea is not Rhodecode, and Rhodecode has in the meantime added a bunch of development and features that are as restrictive as possible.

I wouldn't take this to mean that Rhodecode is still available under the least restrictive license. The authors have really taken Rhodecode away from us, and we can scamper about with a fork, but there has definitely been some damage done.

For an individual copyright holder, or software which is static and no longer being developed, you are correct.

However if either of those preconditions fails, then the reverse becomes true "in practice."

When the copyright is held by multiple parties, re-licensing becomes impractical (or impossible) because every copyright holder needs to agree to the new terms. The more of them there are, the more likely it is that someone will veto.

However, because the AGPL and Apache licenses (and other liberal licenses, MIT, BSD, etc.) are compatible, I can take liberally licensed software, add loads of fancy features using an AGPLv3 license and the combined end result will become AGPLv3 licensed in practice. Just like the combined license of OS X or Chrome is proprietary, even if it contains open source components. The most restrictive license wins.

So assuming the software is evolving over time and you have a wide base of contributors, it is possible to go from less restrictive to more restrictive, but not the other way around.

> AGPL3 maximizes options down the road. You can start AGPL3 and loosen it up over time.

I'm not sure you can easily do that, unless all the contributors assign their copyright to you. You can trivially tighten the license (eg. by adding GPLv3-released code in a LGPL or even Apache codebase) but to loosen it you need approval from all the copyright holders (which is doable, but also a huge pain).

Do you/significant Mailpile developers plan to actively enforce if you go with AGPLv3? If so, please state that publicly, ideally with a plan to do so (perhaps consult with an organization that does enforcement), and go for it. If not, may as well use Apache 2.

Uh, I'm certainly not going to go on record telling people they're welcome to ignore our license, no matter what that ends up being.

But we're also not going to waste time drafting some sort of legal assault strategy at this point, we've got a long list of more productive things to do first!

We'll deal with it if or when it comes up. Probably initially by asking nicely, following up with public shaming, and finally by seeking assistance from whatever orgs are available...

Reply on news.ycombinator.com