Licensing – Decisive Difference Between LGPL and AGPL

The main difference in GPL 2->3 is Tivoisation and patents.

You cannot use a GPL app but prevent people replacing it with their own version (even if you give them the source) by encrypting/signing the binaries or restricting the ability to install new software.

The sections on patents is trickier, it's not entirely clear how much you can require this in a licence agreement, where it would apply and even if software is patentable in your location.

For a conventional desktop app there isn't really much difference from GPL2.1->3

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.)