Interesting from a licensing point of view: the GPL does not require you to redistribute changes that are 'internal' to your organization. You are not redistributing the program itself in this case, you're just letting someone access it.
So the way Werner Vogels explained it at the AWS Summit in NYC recently, Aurora is built from scratch and is MySQL compatible, but it is not a fork. He mentioned that they broke it down into components which are each built on pre-existing AWS services - for example, the storage layer just DynamoDB which I thought was really interesting.
There's a distinct possibility that it's not based on MySQL at all. From their prior discussions, this looks like a clean implementation that just uses its API, so even if MySQL were AGPLed, Amazon wouldn't need to release anything.
It's just a storage engine, albeit a very good one (I was on the beta); storage engines act as a plugin to the mysql/mariadb server layer, and are typically just a separate binary.
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.
The AGPL is fundamentally flawed. Imagine if Google were subject to it; the idea of free software is to have the option to modify that which you run yourself. Without a million spindles, Google's main products are useless to you.
> Imagine if Google were subject to it; the idea of free software is to have the option to modify that which you run yourself. Without a million spindles, Google's main products are useless to you.
Without years of expertise, and tons of free time, you will not be able to modify the free software either. You can have someone do it on your behalf though, and just as well you could have had someone (Yahoo? Microsoft?) run Google software for you, had it been available as free software.
> Without years of expertise, and tons of free time, you will not be able to modify the free software either. You can have someone do it on your behalf though, and just as well you could have had someone (Yahoo? Microsoft?) run Google software for you, had it been available as free software.
I'd like to see something like this with regards to B corporations or non-profits. Something like Gmail, Gravatar, or the like that are services you can pay for, but they're not run for-profit. Companies can bid on the management of the service, maintenance of the underlying open source packages, and so forth.
Something between municipal fiber and Wikipedia, but for SaaS services.
For some people, this kind of end-run around the GPL is the poster child for the AGPL: https://en.wikipedia.org/wiki/Affero_General_Public_License