Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we picked AGPL

blog.paradedb.com

Post reply on HN
Print view View original

271–280 of 312 posts

Re: Why we picked AGPL

#271

Post by myworkinisgood »

gspr wrote: post #262
philippemnoel wrote: post #217

Earlier quoted context omitted.

The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license. We're hoping for a centralized ParadeDB project from which everyone can benefit.

> The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license. This I understand. But it doesn't really address Martin's worry about an accidental modification. Or apparent confusion about what constitutes modification.

There's no accidental modification.

> Not true. There is no need to accept the license if you exercise only your statutory rights, which in many jurisdictions includes the right to run the program and to patch it if necessary (e.g., for compatibility with other programs).

Re: Why we picked AGPL

#273

Post by yencabulator »

goodpoint wrote: post #129
jan_g wrote: post #118

I don't know about ParadeDB, but this was very off-putting for me in case of Minio when they switched to AGPL. If you check their answers to various license questions, they are essentially this: if you use Minio in your stack/product (for profit), then we recommend our commercial license or consult with a lawyer if your use case is covered by AGPL or not. What me and I guess many others wanted was a simple yes/no to…

> if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not No and it's spelled out very clearly in the license.

Only after people badgered them to remove their claim that anything communicating with Minio gets infected by AGPL immediately. Their compliance page used to claim:

> Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO.

That version has, unfortunately, not been archived at web.archive.org or such.

Some remnants of the old compliance text are still mentioned: https://github.com/minio/operator/issues/2030

Re: Why we picked AGPL

#274

Post by cowboylowrez »

jwildeboer wrote: post #170

Correct title would be „Why we picked dual licensing with AGPL and a commercial license“, IMHO. You can only contribute when you accept the CLA at [1] which gives them the right to license your contributions under said commercial license. [1] https://cla-assistant.io/paradedb/paradedb

you can fork it tho. this way you don't need to accept the CLA, you're just obligated to publish your mods if need be.

Re: Why we picked AGPL

#275

Post by yencabulator »

Software products they are using as part their AGPL product are all more permissive, but somehow they consider themselves worthy of monetizing all of this:

- Postgres: similar to MIT and BSD license

- Tantivy (via pg_search): MIT

- pgvector: Postgres license, similar to MIT

- DuckDB (via pg_analytics): MIT

- CloudNativePG: Apache-2.0

- pg_cron: Postgres license, similar to MIT

- pg_ivm: Postgres license, similar to MIT

Re: Why we picked AGPL

#276

Post by the-grump »

yencabulator wrote: post #272

It's AGPL for you but arbitrary relicensing at will for them: https://github.com/paradedb/paradedb/blob/dev/CONTRIBUTING.m...

They put in the effort to create the product. It's their choice how to license it.

Now it's up to you whether to sign that CLA to upstream your changes.

You're welcome to maintain a fully AGPL fork if you don't like that.

Re: Why we picked AGPL

#277

Post by GuB-42 »

yencabulator wrote: post #275

Software products they are using as part their AGPL product are all more permissive, but somehow they consider themselves worthy of monetizing all of this: - Postgres: similar to MIT and BSD license - Tantivy (via pg_search): MIT - pgvector: Postgres license, similar to MIT - DuckDB (via pg_analytics): MIT - CloudNativePG: Apache-2.0 - pg_cron: Postgres license, similar to MIT - pg_ivm: Postgres license, similar to M…

That's the point of permissive licences. To allow monetization and redistribution under more restrictive terms, usually proprietary, but also copyleft licenses like AGPL.

Re: Why we picked AGPL

#278

Post by yencabulator »

GuB-42 wrote: post #277
yencabulator wrote: post #275

Software products they are using as part their AGPL product are all more permissive, but somehow they consider themselves worthy of monetizing all of this: - Postgres: similar to MIT and BSD license - Tantivy (via pg_search): MIT - pgvector: Postgres license, similar to MIT - DuckDB (via pg_analytics): MIT - CloudNativePG: Apache-2.0 - pg_cron: Postgres license, similar to MIT - pg_ivm: Postgres license, similar to M…

That's the point of permissive licences. To allow monetization and redistribution under more restrictive terms, usually proprietary, but also copyleft licenses like AGPL.

And when ParadeDB is harshly criticizing companies that would have otherwise perhaps used their software without paying them:

> Thanks to the copyleft provision, cloud vendors cannot easily resell our project without our consent. This gives us confidence in our ability to monetize without fear of predatory competition.

it seems they don't realize how ironic that stance is; they themselves are using all this software without paying for it.

Re: Why we picked AGPL

#279

Post by yencabulator »

the-grump wrote: post #276
yencabulator wrote: post #272

It's AGPL for you but arbitrary relicensing at will for them: https://github.com/paradedb/paradedb/blob/dev/CONTRIBUTING.m...

They put in the effort to create the product. It's their choice how to license it. Now it's up to you whether to sign that CLA to upstream your changes. You're welcome to maintain a fully AGPL fork if you don't like that.

ParadeDB seems to be thin glue over preexisting Postgres extensions and C / Rust libraries.

Re: Why we picked AGPL

#280

Post by kazinator »

M2Ys4U wrote: post #270
kazinator wrote: post #60

Earlier quoted context omitted.

I would say that's an unhelpfully misleading statement in the license. There exist obvious circumstances of the program's use with which the license doesn't concern itself, and does not speak to, and so in those circumstances the user is not required to enter into the license. A redistributor must enter into the license because it's a derivative of the GPL, and so it has requirements related to distribution. A user w…

>A user who runs the program in such a way that visitors communicate with it from remote stations obviously is required to enter into the license also and comply with its requirements. Only if the user modifies the program. The remote network interaction provision of the AGPL is conditional.

Clause 13 could as well require the provider to offer the code to the network visitors even if the code is not modified.

That makes hardly any difference.

Post reply on HN