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

191–200 of 312 posts

Re: Why we picked AGPL

#191

Post by kazinator »

rpdillon wrote: post #175
kazinator wrote: post #69

Earlier quoted context omitted.

Sure, and you can absolutely use Photoshop, if you paid for it, and promise not to reverse engineer anything. Or, what do you think usage restrictions are or look like? If you don't share those modifications then you must not host that software such that it communicates with visitors; that's a restriction. The modifications that you are required to share cannot be any arbitrary modifications; anything you add has to…

Copyright covers four rights. The right to copy, the right to modify, the right to distribute, and the right to perform publicly. The GPL places restrictions on a combination of the modification and distribution aspect, which says that if you modify the software and distribute it, then you must also include source code. AGPL is more strict and says even if you just want to modify it and use it, you must supply the so…

It's triggered on use of the modified software. Not just any use but use in such a way that network visitors interact with the software. If you don't use the software that way, the requirement doesn't apply even if you modified it.

If you've not modified the software, interested visitors can just get the source code from the same upstream, so why would it be required of you to host it.

However the following situation could arise and I don't see how the license addresses it. You visited a site running some AGPL service which was modified by those site operators. You decide to clone your own instance using their modified code. Since you're not modifying anything yourself you're not required to host that code. Now suppose that original site shuts down and disappears. The upstream for that modified code is no longer available. Are you on the hook for hosting it now? You've not modified anything yourself.

Re: Why we picked AGPL

#192

Post by johnny22 »

quectophoton wrote: post #70
trueismywork wrote: post #48

Earlier quoted context omitted.

You don't need CLA for legal protection, Developer certificate of origin is enough. https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...

Is this actually legally binding? What would be the difference w.r.t. informed consent, between DCOs and the "I have read and accept the terms and conditions" checkboxes from most websites? It also gives me similar vibes to the Do-Not-Track HTTP header since both can be enabled by default.

The linux kernel relies upon one, so I can't imagine it wouldn't be.

Re: Why we picked AGPL

#193

Post by sangnoir »

jillesvangurp wrote: post #157
JohannesSuenden wrote: post #24

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…

I'm actually not a fan of this restrictive license and the even more restrictive contributor license that is in place here which is what enables them to sell closed source versions of the software and potentially close source entirely (as other companies have done). AGPL without this is not very practical for companies as it makes selling commercial licenses impractical and is a bit of a turnoff for commercial users.…

> If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it.

Isn't this a core feature of the "unrestrictive" licenses you're a fan of? If you don't like freeloaders, BSD-/MIT-style licenses are even worse because they allow anyone, not just the maintainers, to sell your contributions in a closed-source product.

Re: Why we picked AGPL

#194

Post by Vegenoid »

sangnoir wrote: post #193
jillesvangurp wrote: post #157

Earlier quoted context omitted.

I'm actually not a fan of this restrictive license and the even more restrictive contributor license that is in place here which is what enables them to sell closed source versions of the software and potentially close source entirely (as other companies have done). AGPL without this is not very practical for companies as it makes selling commercial licenses impractical and is a bit of a turnoff for commercial users.…

> If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. Isn't this a core feature of the "unrestrictive" licenses you're a fan of? If you don't like freeloaders, BSD-/MIT-style licenses are even worse because they allow anyone, not just the maintainers, to sell your contributio…

Yes. I think what makes some people unhappy is the perceived inequality: you can do whatever you want with my contributions, but I can't do whatever I want with the software.

But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).

Re: Why we picked AGPL

#195

Post by powersnail »

teddyh wrote: post #134
lmm wrote: post #106

Earlier quoted context omitted.

> The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing). There's nothing specific to the AGPL or s…

Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not. Secondly, don’t equate the FSF with any other company. The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy; therefore, it’s completely reasonable to also trust the FSF…

> The FSF is in the unique position in that the FSF could change the GPL if they wanted to.

They can publish new versions of GPL if they want to. They can't retroactively change the terms that users of the software and contributors agreed to.

Just like any code owners who has the complete control of copyright can publish their code under a different license.

Re: Why we picked AGPL

#196

Post by lukekim »

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

Re: Why we picked AGPL

#197

Post by bityard »

gspr wrote: post #165
JohannesSuenden wrote: post #24

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…

I have no experience with the AGPL, but I really really like the idea of it. However, I get worried when I read takes like Hector Martin's [1]. In essence, he argues that it becomes very easy for the end-user to make even the most trivial of modifications to AGPL code or stuff associated to it and accidentally violate the license's quine requirement. Do you have any insight on this? [1] https://bugs.gentoo.org/737708

Hector built up a strawman in that bug, and not a very good one. I'm surprised the Gentoo devs were as patient with him as they were, given he kept trying to argue his personal interpretations which are not in line with how the AGPL is generally understood by Gentoo and other distributions. And some of the things he claims are just plain wrong.

Re: Why we picked AGPL

#198

Post by richardwhiuk »

camgunz wrote: post #178
dspillett wrote: post #132

Earlier quoted context omitted.

The question isn't about modifications to the library/service itself, but whether with other code linking to it in any way is what you have considered a derivative work that should also be covered by the AGPL. For a library I'd say that was a definite yes. For a service it is someone's less clear, some provide connective tissue (language bindings or other access modules) under less strict licenses which creates an ob…

Well that's not Op's question. They're asking "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?" (Minio is basically a FOSS S3) [0]. You're asking about linking, which is covered in the FAQ [1]: "You have a GPLed program that I'd like to link with my code to build a proprietary program. Does t…

That's GPL, not AGPL. The AGPL license implies that communicating with it over the network is sufficiently to count as a violation.

Re: Why we picked AGPL

#199

Post by richardwhiuk »

camgunz wrote: post #179
mrbluecoat wrote: post #155

Earlier quoted context omitted.

I think the length of this HN discussion is evidence enough that AGPL isn't clear. In my experience, organizations that use AGPL do so to 1) ward off an active non-paying community with its associated support cost, 2) claim open source to help convince you to buy their software/service, 3) hire skill-vetted programmers, 4) allow third-party security audits, and/or 5) avoid being jaded by someone that can market or ho…

It can also be evidence that HN posters have a poor understanding of GPL licenses. Pretty much all these questions are answered in the FAQ [0]. Your guess is as good as mine as to why people continually post random, uninformed, needlessly conservative takes on them instead of just doing a small amount of reading. [0]: https://www.gnu.org/licenses/gpl-faq.html

That FAQ covers the GPL, not the AGPL.

Re: Why we picked AGPL

#200

Post by richardwhiuk »

mperham wrote: post #52
growse wrote: post #50

Earlier quoted context omitted.

The duplicitous language is a bit slimy here. "In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need..." makes it sound like their hands are tied, you must assign copyright, there's no other option. In reality, this is a (contributor-hostile) choice they made. They could have made different ones.

[flagged]

Not requiring a CLA and only requiring a DCO. (IANAL fwiw)
Post reply on HN