Can't you get around the AGPL by just making it an internal service on your network? Basically it looks like this.
Internet --> Your API service --> AGPL program
Your API service uses the AGPL to implement it's logic. Since the FSF holds that API cannot be copyrighted, Your API service implements the same API as the AGPL program and uses a network connection to the AGPL program running on another computer to implement the API. Since the Internet user never connects to the AGPL program, they are not entitled to the source code. You are required to release the source code to the users interacting with the AGPL program over the network. You therefore release the source code to the implementers of Your API service and call it a day.
Adding another layer of indirection solves a lot of problems in computer science, even GPL and AGPL
However, only if there is effectively the API service in the middle, making your AGPL program internal. But if you are exposing an AGPL program (let's say a database) as-a-service, you cannot have an API service in between (unless you'd re-implement all the API yourself) and hence exposing directly the AGPL database, in which case you are bound by the license with respect to the users.
Thanks for posting this, we've had some arguments with our investors and their lawyers recently about (specifically Golang, in our case) GPL and AGPL meanings and how they relate to SaaS. One case in point we have a cronspec parser package licensed AGPL (what the hell!?) which doesn't even include a web server or listener code of any kind… so are we in violation by using it to parse cronspecs that our customers have entered into our SaaS API?!)
Do you have any citation, references, or case-law I could use as a starting point to steal your arguments as my own?
The citation/case-law to use is those that define the terms distribution, adaptation, and derivative work.
With GPL, anything which isn't client side code should be fine, especially since legal advice from GPL authors have said that SaaS and GPL do not put any additional requirement on the service provider.
AGPL talk about using the work, and here the law as I have read it defined that you got to be a lawful owner in order to be permitted to copy the work into RAM. In order to be a lawful owner of the copy, you got the be in compliance with the license. How you do so is up to you, but the perceived consensus seems to put that responsibility on the SaaS provider.
Since we are talking about an SaaS API, what count as the program is sadly a grey zone. For example, Linux based operative systems has commonly a command line API but it isn't a single program. Ask yourself (or the lawyers) what a nontechnical layman would consider as a single work and what they would consider as multiple separate programs working in unison. I suspect it highly depend on what the API do, how data is flown, and how the internal source code is laid out.
> With GPL, anything which isn't client side code should be fine, especially since legal advice from GPL authors have said that SaaS and GPL do not put any additional requirement on the service provider.
Legal guidance from GPL authors is of somewhat limited utility; they aren't your lawyers, and for software where the FSF isn't the copyright holder as well as the license author, it doesn't even have the utility of being a documented representation from the copyright holder as to their intent with license they were offering.
They also are employed by an entity with a vested interested in promoting the use of the GPL.
Internet --> Your API service --> AGPL program
Your API service uses the AGPL to implement it's logic. Since the FSF holds that API cannot be copyrighted, Your API service implements the same API as the AGPL program and uses a network connection to the AGPL program running on another computer to implement the API. Since the Internet user never connects to the AGPL program, they are not entitled to the source code. You are required to release the source code to the users interacting with the AGPL program over the network. You therefore release the source code to the implementers of Your API service and call it a day.
Adding another layer of indirection solves a lot of problems in computer science, even GPL and AGPL