I'm gonna go donate so I can record my vote for AGPLv3.
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...
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.
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.
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.
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.
Thanks. Could you post the clarification here once you get it?
> 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.
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
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.
Actually, promissory estoppel is a thing: http://legal-dictionary.thefreedictionary.com/Promissory+Est...
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.
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.
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.
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).
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...
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.
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.
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.
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.
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.
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)?
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...