If Timescale were AGPL Amazon would be free to just run it as a service for profit and all they need to do is publish their modifications to it, if they make any. Amazon has no problem running all kinds of other open source software for profit, and this is what TSL is specifically designed to prevent.

But that's the trade: you either pay with time+effort or with money.

What everyone seems to miss here is that the GNU Affero General Public License offers the ability for people to make that choice. Cloud providers would be forced into an ugly situation if almost every single XaaS codebase switched to AGPL. Their business model depends on being able to make minor investments to provide things people want as a service and not share it with the community.

However, if the AGPL was normalized and used more often, cloud providers would be in a situation where they'd either have to A) build everything of theirs on their own if they don't like the license or B) use the software people want, release their improvements back to the community, and everyone benefits.

It's amazing how everyone has forgotten why Linux won over all the other server, mobile, and edge platforms, and is slowly inching to dominate everything else. The terms underlying most of the core Linux system software, including the kernel obviously, require things incorporating it to be released with usable sources to the public. That is what enabled individuals to sustain a project and make it into the successful juggernaut it is today.

But because Google has managed to poison the well with AGPL, we're in a situation today where "business-friendly" permissive licenses like the Apache Software License are used and companies are surprised when they get sucked dry by cloud providers abusing the properties of that license.

Companies building open source software should expect one of two things: money or code. Both are intrinsically quite valuable to them, and they should take care to nurture that those are the two valid options.

The problem with agpl is that no companies want to touch it. It's too restrictive if you ever want to integrate something with your internal proprietary moneymaking code.

Doesn't that accomplish the goal then? Make your project AGPL and with a commercial license, so only you will be able to make it a commercial business as other big cloud companies don't want to touch it.

The problem is that it is not truly impossible to integrate into a commercial company. It's more that the license practically requires a lawyer to look at exactly how it'll be used and approve that use. AWS certainly does not shy away from hosting AGPL software. It does prevent AWS from taking the code and running with it though, at least not without a shim. A more permissive license can lead to the Athena/Presto situation where Athena is, to my knowledge, a proprietary fork of Presto.

Disclosure: I work at AWS on infrastructure services

I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license.

Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3...

Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.

Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal review it is unproblematic to use commercially, which cuts both ways as Redis found out.

I think there's a serious amount of FUD around it. I suppose it's because of how rare it is. With more usage, it would probably bee seen as less dangerous.

The core Redis code (originally announced on this site in 2009 [1], before Garantia Data started in 2011, or became Redis Labs in 2014) has always been BSD licensed. Only extensions from Redis Labs (e.g., Redis look) were licensed under AGPL, and changed to Commons Clause / Redis Source Available License. Those extensions were never part of an AWS cloud service.

See also [2]

[1] https://news.ycombinator.com/item?id=494649

[2] https://redislabs.com/blog/redis-core-team-update/

I agree that there’s a serious amount of FUD around it. I think it’s at least in part because it proliferating could seriously harm Alphabet’s ability to freely grab people’s code to incorporate in their consumer products (YouTube, G Suite, etc.) without reciprocating, and they’ve been careful to semi-subtly spread the FUD (ie. publish https://opensource.google/docs/using/agpl-policy/). https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html

See also https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...

The problem is that Amazon could still do it, they're just on that scale, while most common companies would shy away as they don't have the Amazon budget for abusing AGPL right.

I hope in the future the Elastic, TimeScale, Confluent and any other "fuck Amazon" license could be merged into one and kind of standardized on as many freedoms as possible, while keeping AWS out of it.