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

81–90 of 312 posts

Re: Why we picked AGPL

#81

Post by philippemnoel »

wittystick wrote: post #72
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.

In practice, projects that take this approach do the majority of development in house, and external contributions are small. It makes sense that a company that may have spent several years developing a product can sell commercial licensing. The only alternative way to monetize AGPL works is to provide services and support. Nobody is forcing anyone to give away their rights. You can always distribute contributions und…

Blog author here -- I couldn't have said it better. If you'd like to meaningfully contribute to the project, we're hiring :)

Re: Why we picked AGPL

#82

Post by pxc »

kazinator wrote: post #22
Avshalom wrote: post #13

Earlier quoted context omitted.

>You cannot change it and run it yourself, without hosting the source code. Yes I can. It's only if I let other people use my changed code that they become entitled to a copy. >You cannot combine an AGPL program with proprietary code and operate it, because you cannot release the proprietary code. hmm, gotta say that sounds like the proprietary code is the thing infringing on my usage.

Well no, someone combining the proprietary code with the AGPL code infringes if they run that code such that it is exposed to visitors.

Depending on the license of the proprietary software and who is creating the software derived from both of them, that derivative work could easily be in violation of both licenses. lol

Re: Why we picked AGPL

#83

Post by tzs »

sgarland wrote: post #8
kazinator wrote: post #6

Earlier quoted context omitted.

Running a program, as a service or not, isn't redistribution. It is use. The original spirit of the GPL is about identifying people doing bad things we don't like and trying to prevent them. All those bad things have to do with redistribution, not with using the program. The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program. This is no differen…

> Running a program, as a service or not, isn't redistribution. It is use. Hard disagree. You're redistributing the software in a manner for people to easily use it. If you rip a movie you own, there's no distinction that I'm aware of in copyright law between hosting the .ISO on an FTP server and hosting the .MKV as a stream. They're both redistributing, it's just that one is designed for ephemeral consumption.

That analogy does not work because in all the cases you describe a copy of the movie ends up with the viewer.

When you connect to a remote server over a computer and upload data and receive back results produced by the server software you do not receive a copy of the program. You receive a copy of the output that the program produced.

Re: Why we picked AGPL

#84

Post by mroche »

philippemnoel wrote: post #62
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…

Blog author here. I couldn't agree more. Thank you for your kind words and for sharing the academic perspective of using the AGPL - super interesting!

I'm a fan of AGPL as well, but there's a point of possible confusion for GNU license variants I personally run in to and maybe others as well. It may be worth specifying which variant of the AGPL you are using, e.g. AGPL-3.0-only or AGPL-3.0-or-later.

Re: Why we picked AGPL

#85

Post by kazinator »

remram wrote: post #57
kazinator wrote: post #6

Earlier quoted context omitted.

Running a program, as a service or not, isn't redistribution. It is use. The original spirit of the GPL is about identifying people doing bad things we don't like and trying to prevent them. All those bad things have to do with redistribution, not with using the program. The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program. This is no differen…

> 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.

The admin uses the software, regardless of who else is regarded as a user.

Among the users, the admin is the one saddled with use restrictions by the license.

Re: Why we picked AGPL

#86

Post by jay_kyburz »

warkdarrior wrote: post #74
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…

I think AGPL requires the whole cloud stack that's used by a deployment of this SW to be AGPLed as well.

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.

Re: Why we picked AGPL

#87

Post by kazinator »

purpleidea wrote: post #55
kazinator wrote: post #4

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

> The antithesis of free software. Those who oppose the GPL are precisely the people it was designed to protect against. I think we found a good example of your wishes here. You are against the GPL if you have an ulterior motive to make something proprietary and avoid contributing back!

My comment was about the AGPL, not about the GPL.

Though I don't favor the GPL for my own code, I would not call it "antithesis of free software". The GPL does not impose any use restrictions, and meets a reasonable definition of a free license in other ways also.

Re: Why we picked AGPL

#88

Post by tzs »

graemep wrote: post #25
kazinator wrote: post #23

Earlier quoted context omitted.

The AGPL is absolutely a EULA. The user of a program is the one who installs it somewhere and runs it. Outside people interacting with the program are visitors. They don't have the source code because they don't have the program at all in any form. It has not been distributed to them. 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 th…

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. 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?

https://perens.com/2017/05/28/understanding-the-gpl-is-a-con...

Re: Why we picked AGPL

#89

Post by tzs »

kazinator wrote: post #4

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

It also seems to violate criteria #10 of the OSI's Open Source Definition:

> 10. License Must Be Technology-Neutral

> No provision of the license may be predicated on any individual technology or style of interface.

It has provisions that only apply to people who are interacting with the software remotely over a computer network. If they are interacting using some other technology those provisions do not apply.

Re: Why we picked AGPL

#90

Post by jay_kyburz »

wavemode wrote: post #76
warkdarrior wrote: post #74

Earlier quoted context omitted.

I think AGPL requires the whole cloud stack that's used by a deployment of this SW to be AGPLed as well.

This is a common misconception. Nothing in the text of the AGPL requires this whatsoever. But it's a common enough misconception that my personal recommendation tends to be to just steer clear anyway, if you're planning to run a closed-source business. It's better to not get sued at all, than to get sued by someone who's wrong. But for reference, the only text added to the AGPL in comparison to the GPL is section 13…

I spent some time reading about static linking and dynamic linking. From the FAQ

    > "Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination"
If I had to guess, if you installed each application in your stack separately, and they simply interacted with each other through API calls, you could consider them "System Libraries" and therefore would not dragged into the AGPL. Example, The OS itself, Node, Postgres, and any other 3rd party applications. As long as you are not distributing them, I think they would count as System Libraries.

    > "To prevent unscrupulous distributors from trying to use the System Library exception as a loophole, the GPL says that libraries can only qualify as System Libraries as long as they're not distributed with the program itself. If you distribute the DLLs with the program, they won't be eligible for this exception anymore"
Post reply on HN