Item — HN Reader

Everything is fine. You never have to release your code for anything that's not PgDog itself. If you're running PgDog as a service, anyone who connects to it can ask you for the source code of PgDog. That's what AGPL says.

In practice, if you use it internally, your teammates already have access to the code. Requirement fulfilled.

Your databases run on a private net typically, so your customers can't connect to PgDog directly: AGPL doesn't apply. That's internal use.

If you're running a DB cloud and using PgDog as a proxy, anyone who connects to it, i.e. your customers can ask for the code to PgDog. If you didn't modify it, just point them to my repo. Requirement fulfilled.

If you did modify it, e.g. added some cool feature or fixed a bug, you'll have to show your clients what you did. That's real open source. That's how GPL was supposed to work. Code is free, and so is knowledge and our ability as humans (and now machines, lol!) to learn from it. GPL stopped working because we stopped shipping software on CDs. AGPL is it's modern version.

I love open source and that's why I'm using AGPL. GPL and FSF is the reason why I can do what I do today: I learned from open code written by thousands of brilliant people who chose to share that with the world. Now it's my turn to give back.

2 comments

Thank you; I appreciate your clarity and passion.

I'm trying to read the AGPL in the most tricky possible light to see where the exact boundary is.

From what I think you're saying, I could make a service that uses PgDog behind the scenes, which would mean I could modify PgDog without releasing the source code.

However, given most people making PgDog As A Service wouldn't put PgDog directly on the internet, but would put it behind something like HAProxy, or perhaps even a REST API that takes in a SQL query as text and runs it on PgDog. Would either of those options then mean they could modify PgDog without releasing the modification's source code?

That's a good question. To echo the comment above/below, we would have to define what a "direct connection" is.

In my interpretation (and as the founder, I think that matters because I would be the only one who would have any enforcement interest) that means TCP. AGPL says "over network" and that means TCP/UDP. To me at least.

So if you're running a SaaS, the TCP connection is broken by the app layer and all the business logic in between. Your code and proprietary products are safe.

And just to restate my previous point: PgDog is a company. If you want to use the product, we'll make it work.

> AGPL says "over network" and that means TCP/UDP. To me at least.

Ye-es agreed, but wouldn't an interstitial HAProxy or REST API over the top pass this test as well?

I'm not looking to get round your licence; just figure out what exactly you're protecting with it.

No, any user has enforcement interest.

> That's what AGPL says.

I mean no disrespect, but it doesn't say that. This is your interpretation. There is insufficient legal precedent to validate this interpretation, and thus there is inherent risk.

The risk specifically is that if I use PgDog as a component of a larger application (e.g. a SaaS app) then the entire application may be in scope.

You can fill this webpage with text stating otherwise but it doesn't matter in the slightest. If your intent is that only users connecting directly to PgDog are entitled to receive the source, then I encourage you to develop a license saying as such. But that's certainly not the AGPL, unfortunately.

(Caveats being I'm not a lawyer, and this is not legal advice. I certainly don't enjoy imagining how one would even define direct connections in a court of law.)

FWIW your heart is in the right place. I wish the world worked the way you describe.

The org I work for won't allow agpl packages or code to be used or deployed. It's too much of a risk.