Hacker News Reader

Comment by malisper | Hacker News Reader

Author here. At least for databases, AGPL (or stricter) has become standard. The issue is it's so easy for megacorps (Amazon, Google, etc) to take a permissively licensed product and monetize it at the expense of the original standard.

For instance, Mongo, Cockroach, and Materialize have all gone source available. We picked AGPL because it's the best balance between open source and prevents Amazon from just repackaging it and selling it.

If AGPL is an issue for anyone, we would be happy to dual-license under a commercial license.

View on HN

There is nothing wrong with wanting to be compensated for your work, but for people like myself which use a cloud managed DB solution (GCP CloudSQL PostgreSQL) it means something like this would never be available.

I consider AGPL a poison pill in my work. That is not true with a suitable commercial license, although I expect a lot more commercial product (support/features/etc). As you note, your objective is to prevent commercialization of your software, but radically speeding up analytics is primarily a concern of large organizations so it seems like a mismatch in purpose.

>we would be happy to dual-license under a commercial license

what exactly are your concern of using agpl db server? It doesn't force you to make rest of your system agpl.

> which use a cloud managed DB solution (GCP CloudSQL PostgreSQL) it means something like this would never be available

That's up to GCP then. I'm sure OP would be willing to license pgrust to them for an appropriate price.

What's the incentive for third parties to contribute, knowing just one guy stands to benefit if the project gets monetized in such a manner?

Most of the same incentives of typical OSS contribution? It's not like other OSS projects pay out any earnings made with the product evenly across contributors.

Also, from the trajectory of the project it doesn't look like they are significantly deoendent on outside code contributions.

The whole point is to force the cloud providers to go through a contract negotiation for licensing rather than keep the door open for them. Nothing prevents the parent project from specially licensing to individual parties.

The issue is that AGPL is flatly banned at many companies, so now any company that even wants to test this database out is going to have to seek a contract, which they won't.

> If AGPL is an issue for anyone, we would be happy to dual-license under a commercial license.

You should be setting up a CLA process then ASAP if you are looking to take outside contributions.

Sure, that's your prerogative, and kudos for not talking up open source. I'm not amazon size so can't use it, and AGPL is a no go for DB, don't want to be forced to open source my app because I use this!

Will await a MIT based fork myself.

Why would AGPL force you to open source your app? Unless you literally compile your app with pgrust by modifying the pgrust source code, you're safe. Clients aren't bound by the AGPL because they aren't derived works.

Here we go again.

AGPL is untested in courts. There is no definitive definition of what could be considered within the blast radius such that it would require AGPL licensing.

There's a reason AGPL is banned at Google and most sane companies. It's simply too dangerous.

You can't simply say "clients aren't bound" because it depends.

I'd rather see the BSL used here to be perfectly honest. At least it's simple.

While the AGPL is untested, what a derived work is is less so. It is entirely outside the bounds of the intentions of the authors of the AGPL for clients to be infected.

Reply on news.ycombinator.com