Hacker News new | ask | show | jobs
by trws 665 days ago
A small refinement here, your statements are largely my experience dealing with people linking against gpl3 software because of the vitality and the patent exemptions. Most places run gpl3 stuff just fine. The one organizations won’t touch with a ten foot pole, even to run it, is AGPL.
3 comments

I remember that Neo4j Enterprise used to be available under AGPL. They pulled it and now it's available only under a commercial license.

AGPL is not a problem for server-side software if you don't need to modify it. Your application (talking to the server) doesn't become infected by AGPL.

> A small refinement here, your statements are largely my experience dealing with people linking against gpl3 software because of the vitality and the patent exemptions

In the context of the thread (the claim GPL 3 provides more of a motive for people to by paid licences for dual licensed software) I think that "small refinement" covers most of what we are talking about though.

> won’t touch with a ten foot pole, even to run it, is AGPL.

I feel out of touch

Why?>

The AGPL has a significantly stronger viral clause than the plain GPL. You must offer the source code to anyone who connects to the AGPL-covered code via a network connection (i.e. must open source the entire server if it is using any AGPL code)
Releasing the whole server sounds more like the Commons Clause or the SSPL. AGPL requires you only to provide the source code of your fork to its users.
> AGPL requires you only to provide the source code of your fork to its users

The AGPLv3 is exactly the same as the GPLv3, except with the added clause that connecting to a server counts as distribution for the purposes of triggering the right to obtain source code.

That means all the usual GPL copyleft rules apply: if you include an AGPL library in your server binary, the entire binary becomes subject to the AGPL. And being subject to the AGPL, you are obligated to provide access to the source code for your entire server binary to anyone who connects to and interacts with your service across a network.

Quoting from https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... :

> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program...

> These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient...

> The AGPLv3 does not adjust or expand the definition of conveying. Instead, it includes an additional right that if the program is expressly designed to accept user requests and send responses over a network, the user is entitled to receive the source code of the version being used.

Yes, but are there any AGPL-licensed libraries? I've only seen runnable binaries licensed under AGPL. I can theoretically imagine one, "if you want to build a server application using my binary, I don't want you hiding my source code from your users", but even GPL-licensed libraries are rare, LGPL is more common.
Not a whole lot, at any rate. The poster child was probably BerkleyDB, but the current version is vended from a fork which still uses the pre-AGPL license terms
Ah but what if you bundle both your application binary and some (unmodified) AGPL software into a single Docker container? Do you then need to provide source code for your entire application?
That's the kind of question that only really gets answered when a judge rules on it. The pertinent question here is roughly whether the combined docker image constitutes a "derived work" of the AGPL software