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

111–120 of 312 posts

Re: Why we picked AGPL

#111

Post by kelnos »

Hamcha wrote: post #32

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

Honestly I think this is fine, especially how they've done it. Most CLAs seem to require copyright assignment, but theirs does not. Outside contributors keep their copyright, but grant the company a license to (more or less) do whatever they want with it.

I think we're at a bit of a crossroads here. Enough (smaller) companies have been bitten by the likes of Amazon monetizing their code and crushing the original developers' monetization strategy. So we see some companies turning to non-F/OSS "source available" type licenses instead. This is bad for the open source community as a whole.

IMO, AGPL+commercial is a fine compromise, and companies need to be certain that if they take contributions from the community, that they can still sell commercial licenses for the whole product, including the contributions, without issues in the future. Requiring contributors to assign copyright is one simple way to do that, but I think the path this company has chosen is a lot nicer in letting contributors keep ownership over their contributions.

For a piece of software where the expectation is that the company is going to be doing 90% of the work, and outside contributions will be relatively small, this seems entirely fair to me.

Re: Why we picked AGPL

#112

Post by k__ »

zelphirkalt wrote: post #44
keskival wrote: post #12

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 wh…

Where there is a will, there is a way. Big corporations could use the license and stick to its terms, but no, they don't want to. Better in their view to just take take take and never give. What they don't see however, and what is on no ones quarterly number sheet, is all the talent they don't attract.

Which is funny, as enterprise customers have no issue in buying closed source software, but the moment they see a GPL, they lose their mind.

Re: Why we picked AGPL

#113

Post by progval »

warkdarrior wrote: post #78
remram wrote: post #57

Earlier quoted context omitted.

> Running a program, as a service or not, isn't redistribution. It is use. This is not how I see it at all. The ones using it are the users, and if they sit across the network you are distributing it in a very tangible sense. The idea that the admin running a service is the one doing the "use" and not the users of your service is debatable to say the least.

So when you compile a program and distribute over the network as a binary, you are also distributing the compiler that created the binary?

From section 13 of the license (https://www.gnu.org/licenses/agpl-3.0.en.html):

> if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version [...]

From the Merriam-Webster dictionary:

> interact, verb: to act upon one another

When distributing a binary from a compiler to a user, the user does not act upon the compiler. So the user is not interacting with the compiler, so you don't need to distribute your modified compiler's code any more than you would with the GPL.

Re: Why we picked AGPL

#114

Post by aeaa3 »

kazinator wrote: post #99
jenadine wrote: post #95

Earlier quoted context omitted.

Yes. But that point doesn't help the users since they don't have the data.

It helps in strawman cases when users have the data, and the platform doesn't have social features. For instance, oh, an online photo editor used by the user in isolation, on either local files or easily downloadable files. User doesn't like that instance, so they find the AGPLed source code and run their own, bringing all their files. (Why, in that situation, would the user be entitled to the custom modifications in…

Why would the user be entitled to the commercial SAAS platform's custom modifications?

Because the platform provider didn't pay for the database's commercial license.

Re: Why we picked AGPL

#115

Post by globular-toast »

contrarian1234 wrote: post #101

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.

The "Tivo-isation" clause? You'd want AGPL but without that bit? That would be strange. I doubt Linus likes AGPL either because, unfortunately, his relationship with the FSF is always going to be sour. He's one of most stubborn people on earth (for better or worse).

Re: Why we picked AGPL

#116

Post by contrarian1234 »

lmm wrote: post #107
contrarian1234 wrote: post #101

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.

What rationale would that be? I doubt the FSF would write a version of the AGPL designed to let you use DRM to end-run around it if that's what you're getting at (you can always write such a license yourself, but, why?)

I mean ... Not to rehash all the v2 VS v3 arguments ... But essentially you only care about the source code being shared and you don't care about tivoization and forcing additional hardware requirements or requirements that "used code" is changeable by endusers.

The AGPL's extension just increases any modified code's availability. It's extending the principles behind v2 to networked devices. You gotta share your changes and you can't cleverly avoid it by doing a SaaS instead of selling software/hardware

It doesn't extend the v3 principles (which increase end user's rights). That would be to force companies to allow users to modify and run modified code on the networked device/server (which would be the networked equivalent of a anti-tivoization).

So the AGPL's idea pairs more naturally with v2 in my opinion

Re: Why we picked AGPL

#117

Post by chii »

sfink wrote: post #110
jay_kyburz wrote: post #86

Earlier quoted context omitted.

If true, this license does nothing to mitigate the risk that a user may get locked into contracts they don't like, or the ability to continue to use the software if the developer goes bankrupt or is bought by a competitor. If you can't use the AGPL version now, you can't use it later either. And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.

Even if the (CLA-owning) organization changes the license, the last version available under the AGPL will always be available under the AGPL. > If you can't use the AGPL version now, you can't use it later either. Right. But you can use it now and later. > And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well. Cloud vendors can use it. What they can't do is fork it and start ma…

> but the original project will have access to all of their changes so the cloud operator won't have any advantages when selling support or a license with different terms.

Those changes would be under some sort of AGPL and the original project cannot merge it back, while still maintaining their option of a commercial license.

So once the original project merge any of their competitor's changes/forks, their project becomes AGPL only, and lose the ability to charge for a commercial license as a monetization strategy.

Re: Why we picked AGPL

#118

Post by jan_g »

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.

Re: Why we picked AGPL

#119

Post by knorker »

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…

IANAL, but I'd also be worried that even if the project answers your question, maybe any one individual contributor to the project could sue you if they disagree.

Only if the project doesn't have copyright reassignment, of course.

Re: Why we picked AGPL

#120

Post by chii »

kazinator wrote: post #30
graemep wrote: post #25

Earlier quoted context omitted.

A EULA needs to be a contract. THe AGPL is clearly not a contract nor does it meet the basic requirements for an enforceable contract in common law countries. Can you show me where I am wrong about this? > The source code to the program doesn't even do them any good. They cannot use that to prevent harms perpetrated by the operators of that application. It does. It means they can run their own instance instead of bei…

> A EULA needs to be a contract. Nope. It can just be a piece of text you agree with when opening a classic mass-marked app in a shrink-warpped box ("shrink-wrap EULA") or a dialog box with text where you have to click that by using the software, you agree with the licensing terms. Exactly the same as when you deploy an AGPL program for visitors, you are agreeing to its EULA.

which is exactly what a contract is.

It's an agreement between different parties.

Post reply on HN