Comment by levkk
9 months ago
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.
lev@pgdog.dev
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.
7 replies →
> 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.
1 reply →