Yeah, that line stood out for me as well. Can someone explain why MySQL's GPL license is a problem in practice for his use case?
However, I don't see anything related to the use cases in the article that would make GPL be an issue. Unless they want to build proprietary extensions to the database. Considering they've released the code related to the Postgres rewrite as AGPL that seems even stranger.
> Then I was in a very long and intense meeting with a potentially major customer for an on-premises install, and one of their basic requirements was “no AGPL in the stack”. With the RethinkDB company gone, there was no way to satisfy that requirement, and my requests went nowhere at the time.
> All the code I wrote related to this blog post is – ironically – AGPL. Basically it is everything that starts with postgres- here.
All the code they just wrote for the Pgsql rewrite is AGPL. Obviously they can relicense since they own the copyright, but it's weird to mention MySQL's GPL license in passing as a reason they didn't went that way yet put your own code up as AGPL.
The GPL license essentially triggers on distribution, but if you have some SaaS app it's not clear that this falls under distributing your code since you're accessing what the code produces over a network. This is usually known as the "Application Service Provider" hole in the GPL.
With the AGPL that hole is closed and you have to be able to receive the source code for that app too.
This is all explained right here: https://www.gnu.org/licenses/licenses.html#AGPL
Then I was in a very long and intense meeting with a potentially major customer for an on-premises install, and one of their basic requirements was “no AGPL in the stack”.
Perhaps GPL was close enough to AGPL that it made MySQL's license problematic.