I thought I would add the relevant explanation from
https://www.gnu.org/licenses/why-affero-gpl.html :
Why the Affero GPL
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.
The purpose of the GNU Affero GPL is to prevent a problem that affects developers of free programs that are often used on servers.
Suppose you develop and release a free program under the ordinary GNU GPL. If developer D modifies the program and releases it, the GPL requires him to distribute his version under the GPL too. Thus, if you get a copy of his version, you are free to incorporate some or all of his changes into your own version.
But suppose the program is mainly useful on servers. When D modifies the program, he might very likely run it on his own server and never release copies. Then you would never get a copy of the source code of his version, so you would never have the chance to include his changes in your version. You may not like that outcome.
Using the GNU Affero GPL avoids that outcome. If D runs his version on a server that everyone can use, you too can use it. Assuming he has followed the license requirement to let the server's users download the source code of his version, you can do so, and then you can incorporate his changes into your version. (If he hasn't followed it, you have your lawyer complain to him.)
Both the ordinary GNU GPL, version 3, and the GNU Affero GPL have text allowing you to link together modules under these two licenses in one program.
The GNU Affero GPL does not address the problem of Service as a Software Substitute (SaaSS).
SaaSS means that users use someone else's web server to do their own computing. This requires them to send their data to the server, which does their computing for them and sends the results back to them. SaaSS is an injustice because the users cannot control their computing when it's done that way.
If some program on this server is released under the GNU Affero GPL, the server is required to offer the users the corresponding source of that program. That is good, but having this source code does not give them control over the computing done on that server. It also does not tell them what other software may be running on that server, examining or changing their data in other ways.
We don't see any sensible way to address the SaaSS problem with license conditions on particular programs. Even to write a legal condition to distinguish between SaaSS use and non-SaaSS use would be a challenge, and if we had that, it is not clear what we would want to require in the SaaSS case. Thus, our solution to the problem of SaaSS is simple: refuse to use it.
If a program is meant specifically and only for SaaSS, you shouldn't write it. But many programs are useful for a variety of kinds of services, including some that are SaaSS and some that are not. It's useful to write and release these programs so people can set up non-SaaSS services with them, and good to release them under the AGPL.
As for the reasoning why ATI has always licensed Armory under AGPL 3, it was an attempt to balance the benefits of allowing other people to see and use the code, which is absolutely critical for security related software, against the costs or lost opportunity associated with a third-party using it to build their own commercial platform. (I won't speak for Alan, although he and I had lengthy discussions regarding the choice of open source license years ago).
As a developer, once you release code with a license that is very permissive, you cannot re-license the released code with a more restrictive license. So, for example, if you release your code with the BSD license and then find out that someone is making millions using it as the foundation for their offering, you cannot go back and get value from them. Therefore, using a more restrictive license like the AGPL 3 from the start allows the developer to ratchet the license down on a case-by-case basis as users request.
Using the AGPL 3, we thought that it would either 1) force code into open source, which we thought was a good thing; 2) force developers to talk to us, which we also thought was a good thing.
Please don't misinterpret that when I say "custom license" that it means it has to have a price. If someone wanted to experiment or start their business using Armoryd, we certainly could talk about a no-cost license for a period of time.