AGPL violation using reverse proxy?

Question

A (hypothetical) company owns two webservers:

• server A, runs AGPL licensed software
• server P, runs Proprietery software and acts as a reverse Proxy

Now server A is blocked from the public and only responds to requests from server P. Server P is public and echo's web requests to server A. Then serves the response from A to the client.

Server P sometimes changes or enhances the pages, sometimes serves them as they are, and may serve some pages on its own (without depending on A).

My questions:

1. Is this legal?

After the company makes changes to the AGPL software on server A,

2. Is it then legal?
3. Does the company need to release the changes it made back to the community?

(I've searched and so far only found this question which is somewhat analogous, but very different.)

Answer 1

First, there is no such reference to proxy/proxying being mentioned in the AGPL, so whether or not a proxy is used in the chain that allows an external user to access features of an AGPL-licensed package does not make much of a difference to me. For instance network traffic will likely go through several routers and proxies even if I am not using a fronting proxy myself.

1. Is this legal [when used unmodified]?

Yes, there is no reason why this would not be OK. But I guess the implied question may be what should I do then to comply with the AGPL?. If there is any notice or link or mechanism in the original software that ends up in the packets that I proxy, I would keep these and make these available to my end users in a way that is equivalent to a non-proxied access. I would also (though it is not a clear requirement when the code is used unmodified) provide some credits notice and the license text of the AGPL in the UI of my app.

After the company makes changes to the AGPL software on server A,

2.Is it then legal?

3.Does the company need to release the changes it made back to the community?

It was OK before and it is still OK now: proxying does not have any impact IMHO. But the modification of the AGPLv3-licensed code will likely trigger the extra requirements of section 13 "Remote Network Interaction".

[...] 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.[...]

Therefore, and again IMHO irrespective of proxying, I would notify my users of the modifications (in addition to what I was doing without the mods as explained above) and I would provide them with a mechanism to get access to source code that includes my modifications, most likely with a link to download an archive of the corresponding source code. Here I would not worry about the community at large (though it would be a nice thing to do) but instead ensure that my users have access to this download.

Just as a follow up. In the Preamble of the AGPL it is said: Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. Since in this example server A is not publicly accessible, wouldn't allow this the hypothetical company to keep it's changes for itself?

The AGPL "Preamble" is not part of the T&C but is not something to ignore entirely. Yet this is a different context we have here: say I use a modified version of MongoDB strictly internally in my organization: I have no special obligations IMHO.

If this becomes available externally outside my organization, such as to a customer this is no longer internal use, even if this is not "public" use in the sense that only my customers can access it and not the "general public".

Answer 2

I'll first discuss the case that the proxy is a transparent proxy.

The AGPL does not prevent you from running AGPL software behind a proxy.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

The proxy is completely independent from the AGPL software, and they do not form one combined work.

Clearly, users that make requests to your servers do interact with the AGPL software, even if their requests go through the proxy. If you modify the AGPL software, the AGPL section 13 comes into effect and you have to offer the Corresponding Source to all users (= end users) of your system.

if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network […] an opportunity to receive the Corresponding Source […] from a network server at no charge, through some standard or customary means of facilitating copying of software.

In your case, the proxy isn't a transparent proxy.

Its ability to route requests either to the AGPL server or to the internal web server is unproblematic, and does not seem to change the setup significantly.

However, your proprietary “proxy” may also manipulate the requests and responses to/from the AGPL server. We now have to consider whether these manipulations mean that the proprietary server is “linked” or “combined” with the AGPL software, in which case this setup would violate the AGPL license.

• Simple transformations of the content such as compression are certainly OK.

• Simple changes to the content such as injecting tracking codes or ads are possibly OK, since these changes do not depend on the AGPL software – they would work just as well with any other server.

  However, this would be start to be unethical from a FSF-perspective. This would infringe on the user's freedom to study the software. Given the AGPL server's Corresponding Source, the user would be unable to understand how the server response they got had been created since changes were performed by the proprietary server. Of course, this ethical aspect is not part of the actual AGPL license.

  This requires further consideration. I think this usage is likely to be compatible with the AGPL, but that the user is still interacting with the AGPL software, thus triggering the AGPL section 13 provisions as soon as you make changes to the AGPL server.

• Substantial changes to the content or extra interaction between the proprietary server and the AGPL server make your setup appear as a single application to an end user. It is unlikely that the proprietary software performing these changes would be useful without the AGPL software, opening up the possibility that it is somehow “linked” to the AGPL software.

  This requires a lot of further consideration. I think this depends on how much the proprietary server does. See also: How does the AGPL affect Microservices?

  Does the proprietary server effectively offer an independent application? In that case, it's OK if it uses the AGPL server as a data source or service. Since any communication between the two servers happens over HTTP requests, they operate “at arms length” and do not form a single program. This setup seems compatible with the license. Example: a web app using the AGPL-licensed MongoDB database on their backend.

  Or is the proprietary server just a thin layer over the AGPL server? Does the proprietary application embed parts of the AGPL application in itself, or embed itself into the AGPL application? This effectively still allows direct communication between the end user and the AGPL software. In that case, I would argue they form a single application that must be made available in its entirely to the end user under the AGPL, even if the back end consists of multiple processes.

  It is worth noting that the GPL licenses do not apply to the output of a program, but they do apply to user interfaces offered by a program. Combining user interfaces therefore creates a derivative work. For web applications, there may be some wiggle room since the front end running in the end user's browser and back end running on your servers are separate processes. E.g. it might be possible to create a combined front end which remains covered by the AGPL, but which communicates with both the proprietary server, and the AGPL server through the proxy.

For each of these distinct cases (transparent proxy, minor changes, derivative user interface, independent application) you'll have to sort out which case applies to which aspect of your setup. Preferably with legal counsel. you will have to think about the functionality of your proprietary server very carefully. It's not problematic that your setup has multiple of these aspects, as you can manage licensing for each case separately.