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

141–150 of 312 posts

Re: Why we picked AGPL

#141

Post by sfink »

kazinator wrote: post #43
levkk wrote: post #34

Earlier quoted context omitted.

> The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software. This is a common misconception about Free software. It's not about freedom of its users or authors, it's freedom of the actual code to be available for others. For example, MIT license allows users to take the code and modify it without releasing modifications. This traps the new version of the software, possibly for…

Firstly, GPLed programs with proprietary modifications can easily be trapped inside single organizations. The original MIT-licensed program continues to exist and be available regardless of the proprietary versions and embeddings. A copyleft license just asserts, using copyright power, that such things should not exist. MIT and BSD licenses just allow certain works to legally exist that copyleft advocates think shoul…

> The original MIT-licensed program continues to exist and be available regardless of the proprietary versions and embeddings.

> A copyleft license just asserts, using copyright power, that such things should not exist.

Well, a copyleft license asserts that proprietary versions and embeddings of the licensed software should not exist. GPL software doesn't assert anything about the existence of BSD-licensed software. Or at least, not unless you link them together into one thing.

It is true that rms would prefer that such works not exist. (Or that's how he felt originally, at least.) But the GPL is silent on the issue, as it has to be. There's no clause saying "the author promises not to release any software with a non-copyleft license, nor to name a child Dorothy, nor to eat the flesh of an aquatic mammal."

Re: Why we picked AGPL

#142

Post by zadokshi »

goodpoint wrote: post #129
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…

> 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 No and it's spelled out very clearly in the license.

No it is not clearly spelled out. So I am wondering why you think it is clear. Perhaps you are misunderstanding the problem that is being raised? I’m not sure.

Re: Why we picked AGPL

#143

Post by [deleted] »

purpleidea wrote: post #54

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.

[deleted]

Re: Why we picked AGPL

#144

Post by haytamoptika »

goodpoint wrote: post #129
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…

> 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 No and it's spelled out very clearly in the license.

https://www.gnu.org/licenses/gpl-faq.en.html "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program."

I think you can interact with GPL/AGPL and retain your code propietary by:

- Don't modify the AGPL program.

- Run separatly, using docker container, vm etc

- Interact with CLI, REST API, filesystem, database etc

- Keep the AGPL interaction only to your program, non public consumption, minimum the surface of distirbution the code.

- Keep your code non directly interact, such as avoid use node npm dependencies directly, avoid library linking, use api gateway, use thirdparty module.

Re: Why we picked AGPL

#146

Post by runningmike »

jay_kyburz wrote: post #53

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

Nothing. There is no need for consent. Just fork it and respect the agpl. You can do what you want as long as you respect the AGPL. So reselling is allowed.

Re: Why we picked AGPL

#147

Post by franga2000 »

dspillett wrote: post #132
camgunz wrote: post #125

Earlier quoted context omitted.

No, the whole idea of the AGPL is to make you release modifications even if you're not distributing (i.e. a web app). No modifications, no release.

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…

The "any coupling" logic would also make anything running on Linux GPL, which is definitely not the case. Using background service such as Minio as an unmodified black box for data storage as part of your app is unambiguously not derivative work. If you were to write something like a management UI for Minio and offer it with your hosted Minio service, then I can at least see the argument, although it still doesn't count under my reading of the AGPL.

Re: Why we picked AGPL

#148

Post by dgb23 »

keskival wrote: post #135
dgb23 wrote: post #130

Earlier quoted context omitted.

I thought the point of copyleft was mainly to protect the freedoms of users. But apparently it’s also used as a filter of who can interact and benefit from it. But I don’t really understand all of it. One thing I always wondered about selling separate licenses alongside GPL: Can the authors (holding the copyright) distribute code under a different license when there were external contributors under GPL?

By default the contributors also hold copyright and need to consent to the separate licensing. However, this is typically solved by using a contributor licence agreement (CLA) where all contributors click through a form before submitting a PR where they declare that they own the copyright for the PR and they give a license for the organization to relicense the work and derivatives. Sometimes the whole copyright is tr…

Thank you!

This might be a viable licensing scheme for Swiss government contractors now. The federal government requires open source licenses for all software projects as of last year or so.

(A)GPL+CLA might be a good way to ensure the interests of the both the Swiss people and the flexibility or competitiveness of contractors, allowing them to retain proprietary licenses where needed or wanted.

Follow up:

Am I correct in thinking that this might slightly hinder contributions on one hand, but ultimately anyone could still maintain an _independent_ fork?

Or in other words: Would contributions to a fork still require signing the CLA and essentially allow the original authors to dual license any such contributions?

Re: Why we picked AGPL

#149

Post by demurgos »

haytamoptika wrote: post #144
goodpoint wrote: post #129

Earlier quoted context omitted.

> 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 No and it's spelled out very clearly in the license.

https://www.gnu.org/licenses/gpl-faq.en.html "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program." I think you can interact with GPL/AGPL and retain your code propietary by: - Don't…

You linked a more general FAQ for the GPL. Would you have a more specific quote or link for interactions with AGPL code?

Re: Why we picked AGPL

#150

Post by brightball »

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…

This feels like dealing with government agencies where you go out of your way to get clarification to make sure you are doing everything correctly, but they refuse to give a clear answer to they can bother you about it later.
Post reply on HN