AGPL License - does it apply in this scenario?

Question

There is an AGPLv3 based software (Client) that makes web service calls (using SOAP) to another software (Server - commercial, cloud based). There is no common code or any connection whatsoever between these two except for the web service calls being made.

My questions -

1. Does the Server need to be AGPL too? I guess not - but would like to confirm.

2. Let us say the end point URL for the Server can be configured on the Client side (by editing an XML file) to connect it to different Servers (again, there is no connection other than the webservice calls being made) does it require any of these Servers being AGPL?

3. Are there any issues in running the Client as a DLL that is loaded by other commercial applications on users' desktops? Does it require these other applications also to be AGPL?

Answer 1

tl;dr: Using AGPL this way might not have the effects expected.

• Does the Server need to be AGPL too? I guess not - but would like to confirm.

There is no way for the license on the client to force the server to change its license, whatever the license on the client. There is no way to force that legal restriction; the commercial company simply cannot be bound that way. If this conflicts with the license of the client, then it is the client that is incorrectly licensed (and which hence should not be distributed by anyone other than its copyright holder; standard copyright rules apply).

Persuading any organization to pick a license based on what people (or organizations) that are “downstream” of them do is a hard sell at the best of times. Telling them that, because of some random third party that is totally beyond their control, they have to switch to a license that is objectionable to them (for whatever reason) is just not going to work. They simply do not have such an obligation to you.

• Let us say the end point URL for the Server can be configured on the Client side (by editing an XML file) to connect it to different Servers (again, there is no connection other than the webservice calls being made) does it require any of these Servers being AGPL?

That's even more ridiculous. Suppose you edited that URL in that file to point at an installation of Microsoft Sharepoint; would that force MS to license one of their key commercial products under the AGPL? That's totally laughable.

No, what you'd actually be doing is breaking the terms of use of the client software. Strictly, if it is AGPL then it should only ever be pointed at AGPL services (excepting where the copyright holder grants an explicit exception).

• Are there any issues in running the Client as a DLL that is loaded by other commercial applications on users' desktops? Does it require these other applications also to be AGPL?

It should require that in order for everything to be properly correct, though there's a strong chance that that's not what will actually happen. Instead, what you'll actually get is users breaking the license agreement. Unless the AGPL client is promiscuously offering itself to other programs to load (there at least used to be ways to do this in Windows, though it is now much rarer except for a few parts of the OS itself) in which case it could be argued that the software was trying entrap users into breaking the license. Not a good idea if you want to actually enforce the license!

But you won't persuade the commercial software authors to change (unless they're deliberately searching out the AGPL software for loading despite knowing that it is AGPL). That the commercial software is able, at the prompting of the user, to load an arbitrary DLL and use some sort of introspection to invoke a function within it (such code exists) would not in itself be enough to force a dependency; it would again be the user who is the party causing the problem, not the commercial firm. (Understanding the API presented by the AGPL-ed DLL would not in itself cause a link; there have been fairly recent court decisions to the effect that APIs are not subject to license restrictions at all. This irritated Oracle a lot IIRC.)

Answer 2

As far as any version of the GPL goes, there is no distinction between commercial and non-commercial distribution of the code. If you distribute, you need to do so under the same license, and with copies of the source code.

Since this is the Affero version, if you use aloha on the server side of your website, it still counts as distribution, and you need to provide the source code. You may not make your own changes to the source code and keep them private. If you're just using it, this should be easy; you can probably get away with pointing people to where you got aloha.

There is no requirement whatsoever to distribute any data. This is source code only.

Reference

Answer 3

Two months late, but still...

First of all, IANAL, ask a real professional, and all the usual stuff.

I'll start with 3.

You're touching something very big. According to the FSF, not just AGPL, but even GPL forces you to open-source anything that is dynamically linked to a (A)GPL binary.

According to some other people, you're not really forced to do it. There hasn't been any major lawsuit that can confirm either view of the problem, but the spirit of the GPL is that you should open-source the client application in its entirety. Needless to say, this goes to AGPL too, as AGPL is more restrictive than the GPL. Important note: you can license the rest of the client as GPL, not AGPL, since AGPL allows for this.

1 and 2 are virtually the same, to a certain extent. In both cases I believe you're allowed to do what you want under AGPL. Let's look at the relevant text in AGPL:

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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

So, if you modify the client library that is AGPL licensed, you must provide the modified source code to all parties, that will communicate with it, that is to all servers. As far as I understand, you're not modifying the source code of the client, so it's not your problem at all.

Answer 4

To answer your first two questions, the GPL FAQ says no, an AGPL-licensed client generally cannot affect the licensing requirements of a service it connects to:

If some network client software is released under AGPLv3, does it have to be able to provide source to the servers it interacts with?

This should not be required in any typical server-client relationship. AGPLv3 requires a program to offer source code to “all users interacting with it remotely through a computer network.” In most server-client architectures, it simply wouldn't be reasonable to argue that the server operator is a “user” interacting with the client in any meaningful sense.

Consider HTTP as an example. All HTTP clients expect servers to provide certain functionality: they should send specified responses to well-formed requests. The reverse is not true: servers cannot assume that the client will do anything in particular with the data they send. The client may be a web browser, an RSS reader, a spider, a network monitoring tool, or some special-purpose program. The server can make absolutely no assumptions about what the client will do—so there's no meaningful way for the server operator to be considered a user of that software.

To answer your third question (assuming by "commercial applications" you mean actually mean "GPL-incompatible applications"), the answer is the same as the normal GPL: no one is actually sure. The FSF believes that loading a (A)GPL-licensed library dynamically creates a derivative work, which would require the code using the library to be GPL-licensed. To be sure, not everyone shares this opinion, but that is the legal opinion and intent of the authors of the GPL.