We Picked AGPL

I love the AGPL. I can't imagine it becoming popular for generic business functionality in library form, but for highly-specialized libraries (in my case scientific with industrial applications) it was everything I was looking for --- not least because automated license scanners flag it and scare potential parasites away. It's also a great choice for complete pieces of software (such as DBs, as in this case) to offer a free tier for communal benefit, provided you're genuinely willing to let the project develop a life of its own if the open source community finds reason to mobilize around it.

For academic use AGPL compliance is a natural part of life anyway, for non-profits it's a little bit of effort but there's no fundamental objection, and when companies get involved it ensures that either my collaborators and I get a payout for SaaS-ification/proprietarization, or that it only gets used in internal tooling, which means that money gets redistributed to labor (often also to us via consulting fees or custom development arrangements anyway, since we know the code best).

It's a model for software development that I can really get behind.

Best of luck to you!

The point of an OSS license in these kinds of situations is pretty simple:

They need to pick a license which is salty enough so that big corporations cannot use it, but have to buy a special license from the authors.

Meanwhile they can support and benefit from the open source community without bureaucracy, and get a maximal userbase to create content on the web about this stack, and have a maximal number of people who know this stack and want to use it.

AGPL is perfect for this.

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 the following: 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? And they do not want to answer this question. I do not understand why is it so hard to answer clearly. I understand that the majority of opinions is that it's fine to use without modifications, but I wanted a clear statement from authors of Minio. Failing that, I then decided to keep the pre-AGPL version for a while and have transitioned away from Minio since then.

Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.

Every so often I run through the common set of licenses to double-check which one I want to personally use for my projects (both commercial and for fun), and I always end up back at AGPL. For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.

I don't understand why they say

"Future-Proof: 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. ParadeDB just turned one year old, and we’ve already been contacted by four cloud providers who, had we not chosen the AGPL license, may have privately forked and distributed ParadeDB."

Nothing in the license requires cloud vendors from reselling the project. They just need to make the source available?

What am I missing?

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

It's AGPL for you but arbitrary relicensing at will for them:

https://github.com/paradedb/paradedb/blob/dev/CONTRIBUTING.m...

I fully support ParadeDB's decision. For an open-source software company, AGPLv3 + Dual License is the most sensible choice.

If you go with Apache 2.0, you're literally doing free work for cloud vendors.

> The AGPL license permits free use, modification, and distribution of software, provided that distributed, derivative works of the software are released under the same license.

Here is the rub: free software permits unconditional use.

The GPL without the A, or MIT or BSD licenses are not EULAs; they place restrictions or conditions on redistribution, not on use. (With regard to use, they have only certain liability disclaimer clauses.)

The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.

I totally get this. I recently changed the license on my project from MIT to AGPL after getting a dm from someone interested in buying the project. I make absolutely no money at the moment, if anything I'm paying out of pocket for the domain, and don't think will any time soon. My only goal was to protect the project from getting commercialized by someone else. I've gotten questions about it and have been questioning whether I got too scared that someone might monetize what I worked so hard on.

They looked at 4 licenses (Apache, Business Source License, AGPL, Elastic License) representing different categories.

I think the Mozilla Public License represents another category and should always be evaluated as well. (or the Eclipse Public License or CDDL are similar)

They are less permissive than Apache in that they require contributing back (as in open sourcing changes under same license), but more permissive than AGPL in that you can statically link an MPL licensed library into your project without having to open source your project.

> Elasticsearch alternative built on Postgres

Without horizontal scaling it's more like a hosted/queryable Lucene.

This resonated with us as well, we have also chosen AGPL as license for our open source project - https://github.com/patched-codes/patchwork

I’ve been pretty involved in open source projects most of my career. The license you choose should reflect the community you are trying to create. But it probably only makes sense to protect application level code with a copyleft license.

Most code has no real value beyond the time it saves you and its software developer contributors so it should be as liberally licensed as possible. You want to encourage contributions from the widest possible user base which includes developers of closed source software. They are already incentivised into upstreaming their changes to you on a liberal basis.

Honest question: For the people not intending to "build a business on top of an open source library" but only intending to do something like "I just need this library to solve an issue in my work job" it's not simple to not touch it at all?

I had read a lot of conversations, and to be honest it's quite confusing for me the risk acceptance to have AGPL code in my codebase.

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

First title is a bit misleading. ParadeDB is Open Core, which uses AGPL for Open Source version.

When you talk about traction I wonder how many external contributors are you getting ?

The AGPL is great, even for business. I make a living from AGPL software. Lots of people generally don't like it, because AGPL was not written to please the largest number of developers, but rather to protect the basic software freedoms of end-users. In a sense, the AGPL guarantees more freedoms, is more free, than other licenses such as MIT/BSD for end-users. But depends on the point of view.

Many developers don’t like to have their freedom to steal to be restricted by such strong terms as those imposed by the AGPL. And that’s a good thing for you, my fellow maintainers. It’s also a great thing for you, dear end-users.

The fact that they aren't mentioning their CLA which gives them extra rights that everyone in the community doesn't get means they're disingenuous in writing this article...

As an analogy it's as if someone was selling you a new car, but neglected to tell you that it doesn't come with a steering wheel or tires.

Be transparent and tell the whole story, don't be sneaky.

We chose Apache 2.0 for the Spice OSS runtime.

TL;DR: Data-plane Apache 2.0, control-plane BSL.

Being such a core component, we want developers to be completely comfortable integrating and deploying the Spice runtime in their applications and services, as well as running Spice in their own infrastructure.

In addition, Spice OSS is built on other great open-source projects like DataFusion and Arrow, both Apache 2.0, and DuckDB (MIT), so being permissively licensed aligns with the fundamental technologies and communities it's built upon.

We expect to release specific enterprise control-plane services, such as our Kubernetes Operator under a license such as BSL.

[1] https://github.com/spiceai/spiceai

Is there some AGPL equivalent on top of GPLv2 instead of GPLv3

After reading the rational for v2 for the Linux kernel, Ive always found v3 a bit off putting.

It's a shitty license.

If you need to patch anything due to local requirements like the auth system you need to publish it which doesn't make sense at all.