Live data from Hacker News

Why we picked AGPL

blog.paradedb.com

181–190 of 312 posts

Re: Why we picked AGPL

#181
post #162

Earlier quoted context omitted.

Github may have it wrong then? Their summary says: > Permissions of this strongest copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Note the last part: "which include licensed works using a licensed work"

No, GitHub has it exactly right. Ultimately this sort of thing has to be settled in court.

At least in the EU there's some precedent where AGPLv3+ won out, though it was through settlement and not judgement (and it's not super clear how contentious the parties were anyway) [0]

[0]: https://archive.fosdem.org/2021/schedule/event/agplcomplianc...

Re: Why we picked AGPL

#182

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

The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only standard described is "like the compiler and the kernel, or like an editor and a shell".

Re: Why we picked AGPL

#183

Earlier quoted context omitted.

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?

"In AGPLv3, what counts as 'interacting with [the software] remotely through a computer network?'"

"If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online."

"If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session."

[0]: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...

Re: Why we picked AGPL

#184

Earlier quoted context omitted.

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

The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only stand…

> How do I know whether a particular API usage qualifies as well separated or not?

The two paragraphs above what you quoted are:

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

"The difference between this and 'incorporating' the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."

Two programs communicating over a socket aren't incorporated. They're two programs.

Re: Why we picked AGPL

#185
post #109

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…

> 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. It's not. It's about making sure users can fix the bugs in the software they want or need to use, and share those fixes with others. Rules about redistribution are a means to that end. The GPL was originally written in…

The GPL is not simply about fixing bugs. It's about preventing the existence of versions of the program in which you cannot easily find or fix bugs, and the underlying ideology that they should be no such programs. And not only bugs but deliberate undesirable or malicious behavior. The problem with closed source proprietary software is that you don't know what's hiding in the binaries.

If software were uncopyrightable, they would still be binaries without source code, which you would have to reverse engineer to find out what harm they perpetrate actively or possibly through their security flaws.

Moreover, if you wrote a piece of free source code, anyone could do anything with it they wish, including removing your name, and not attributing you in any way in the documentation accompanying the compiled code.

Stallman was a control freak who insisted that people modifying his code give back the contributions to the project. In the world without copyrighted programs he would have had no leg to stand on, and he knew that. A world in which programs are not copyrighted would need laws which ban the distribution of binaries without buildable source code, and all the tools needed to build it and their source code.

A program is not distributed to you if someone else installed it on a machine you don't own and you're just borrowing that machine. It doesn't matter if you're physically at the console, we're at a remote dumb terminal or smart client. The program was distributed to your school, company or friend or whoever.

I don't think that even the people who drafted the AGPL believe the nonsense doctrine that the visitors to a server have been distributed the software. That's just something invented by the downstream AGPL apologists. (And of course vendors of proprietary software like the doctrine also. If you buy a program and let 10 people use it via remote access to your machine, they would like the legal system to believe that those people were distributed the program and that you should buy ten more licenses). The doctrine is not required for the AGPL to work. The software distributed to the individual or organization installing it and running it for visitors. The license is concerned with the behavior of that individual or organization, and uses the power of copyright to make their permission to have a copy of the program conditional on their usage behavior. The visitors to the running application are not parties to the license.

The GNU AGPL contains these definitions:

> To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

> To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

Re: Why we picked AGPL

#186

Earlier quoted context omitted.

The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only stand…

> How do I know whether a particular API usage qualifies as well separated or not? The two paragraphs above what you quoted are: "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.…

Again, the FAQ says otherwise. #MereAggregation says that this is "normally" the case, but "if the semantics of the communication are intimate enough" two binaries communicating over a socket may still be one program. Whether they are one program is explicitly left as a question for judges to decide.

Re: Why we picked AGPL

#187

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 need something else, you pay for it.

Open source does not necessarily mean open contribution. It may turn you off, but the tradeoff is that you can make the changes you need and run for your purposes. If your purposes is to make closed source software with it, you will need to pay for that privilege.

win-win!

Re: Why we picked AGPL

#188

Earlier quoted context omitted.

The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only stand…

> How do I know whether a particular API usage qualifies as well separated or not? The two paragraphs above what you quoted are: "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.…

Sorry but what does "arms length" mean? My software doesn't have arms. Using metaphors full of imagery is cute but essentially meaningless.

> Two programs communicating over a socket aren't incorporated. They're two programs.

Aren't they? So, if I want to use a GPL library, all I need to do is write a little wrapper program that does RPC over a socket, and boom, I can use a GPL library in my closed source program? Obviously not.

Re: Why we picked AGPL

#189
post #174

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.

Most major tech companies will ban it for any use because the virality of it isn't clearly bounded and legally it's untested [1]. The stakes are high at large tech companies with valuable IP, so downside is huge. For whatever reason, AGPL has never laid exclusive claim to particularly valuable projects (even in this project's case, it seems like they dual license so you can avoid the AGPL), so the upside isn't that high. So high downside + low upside means major players will just err on the side of "no".

If your company has anything to lose, I'm sure it'll have a lawyer and you'll want to consult them on what their risk tolerance is. It's confusing because the license is actually ambiguous, most tech companies aren't willing to accept this ambiguity.

[1] See this opinion by a Google lawyer: https://news.ycombinator.com/item?id=23968783

Re: Why we picked AGPL

#190
post #38

Earlier quoted context omitted.

AGPL doesn't restrict use: "You are not required to accept this License in order to receive or run a copy of the Program."

I would say that's an unhelpfully misleading statement in the license. There exist obvious circumstances of the program's use with which the license doesn't concern itself, and does not speak to, and so in those circumstances the user is not required to enter into the license. A redistributor must enter into the license because it's a derivative of the GPL, and so it has requirements related to distribution. A user w…

I looked at the context of this.

It's in a section whose purpose it is to make it clear that you don't have to accept the license just have a copy of the program, but that if you convey the program your implicitly accepting with the license, that license being the only basis for your permission to redistribute.

Post reply on HN