No. If you're using it internally though, there are no issues. You don't have to share anything. If you're using it externally, e.g. building a PgDog cloud service, you'll need to share any changes you make to PgDog _only_.
> If you're using it internally though, there are no issues.
Unfortunately this advice is incompatible with that of most legal departments.
I get that this is your interpretation, by your interpretation doesn't have any value when it comes to possible IP issues.
No issues. PgDog is a company, email me if you want to use it internally and we'll work it out.
Sorry to harp on this point that isn't fun performance engineering, but I think the tricky bit comes in exactly where you draw the line.
Is offering Postgres-as-a-service with PgDog under the hood okay?
What about a document-oriented, Firebase-equivalent that has PgDog and Postgres under the hood?
What about a low-code application development platform?
What about all of the above, but internal-facing vs paying-customer facing? Does it matter if the internal-facing is paid for via a cross-charge rate (e.g. a multinational company that charges divisions in other countries for services)?
Does a customer of all of the above services have to AGPL their code and release it publically?
Maybe it's all obvious, but that is the sort of thing I worry about with AGPL commercially. Even though I love OSS.
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.
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.
> 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.
> Unfortunately this advice is incompatible with that of most legal departments.
I see this comment pop up every now and then on HN in specific, but I've never personally had a lawyer tell me this; is there any chance anyone could share an actual example of this?
Well in all large orgs legal has rules which licenses are allowed for dependencies generally it's MIT, Apache, BSD and the like
I worked in a large org with 100,000+ employees. You could just use software with pre-approved licences and I am 99% sure AGPL wasn't one of them.
Google is in that camp, and I would bet they don't skimp on lawyers https://opensource.google/documentation/reference/using/agpl...
I didn't spot it previously but they've even gone so far as to treat it like an actual virus https://opensource.google/documentation/reference/using/agpl...
FWIW they have a similar stance about SSPL https://opensource.google/documentation/reference/thirdparty...