Topic: Clarifying armoryd software license (Read 1492 times)

Actually they could, of course, because they own the copyright to the code so they don't require a license.  But I know what you mean...

It's rather ironic that ATI couldn't, as things currently stand, host an armoryd-based service off of their own website at https://bitcoinarmory.com/.

This seems like a rather surprising position to take.  It would, for instance, prohibit using an off-the-shelf commercial firewall between Armory and the Internet.

ATI believes that the use of Armory or Armoryd, licensed under the AGPL 3, as a backend application that interacts with any information from the Internet, causes all software in between Armoryd and the Internet to also be AGPL 3 licensed. Therefore, the source code is required to be publicly available.

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.

First off: pretend that "IANAL" is added to every single opinion you see below. With that said....

Is the AGPL enforceable? I've absolutely no idea. It's probably the most copylefty license out there, though.

Is ATI's application of the AGPL to armoryd's JSON-RPC interface enforceable? Again, no real idea, although it seems like a stretch to me.

Is ATI's desire clear? Yes, unless a principal at ATI steps forward with a different statement, I'd say it's pretty clear. They don't want anyone using armoryd with an Internet-facing service unless you open-source that service, or seek an alternate license from ATI.

Although I didn't read his post that way, the fact is that every piece of copyrighted content (rightfully) carries this inherent threat if misused. Of course I'm happy to argue that copyright law needs a major overhaul in my country (U.S.), but that doesn't change the current state of things.

Just in the interest of not starting a flame war , is it OK to limit this thread to ATI's particular choice of license, and leave out the more general copyright/left/permissive debate?

Still not a lawyer here, but I'm nonetheless quite confident that your licensing terms are unenforceable, and so I'm daring to ignore them.

We do share a similar opinion, though: the thought that everything which touches armoryd's JSON-RPC interface is tainted by AGPL is too copyleft for my taste.

Is it not the whole point of Bitcoin to begin with that trying to control abstract concepts is rather pointless?

The statement above from ATI general counsel implies there exists a legal threat to those that do not respect this so-called "license".

If you release a piece of information publicly, you cannot reasonably expect to maintain "control" over that information by definition.

Ok then, I hereby state that anyone who replies to this thread or any other on bitcointalk.org about IP is agreeing to a contract that agrees with whatever I say about it. You're saying you don't agree? Well, you are, of course, free to choose to not enter into my contract by not expressing views on IP that constitute reneging this incredibly valid contract. Happy now?

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.