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.
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.
I feel out of touch
Why?>
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.
It is "dual licensed". AGPL and proprietary license according to Wikipedia
I am unsure how that works...
Oracle
From the FSF’s licensing FAQ:
> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
Eben Moglen wrote a little about the intent here [0], I'll excerpt a little:
"This form of explanation was unfortunately unhelpful. It led to years of fruitless discussion about the role of “derivative works” doctrine (a US concept) in software (where US courts have largely failed to provide any guidance). So in GPLv3, we and our clients at the Free Software Foundation decided to drop all illustrative reference to US “derivative works,” returning to the base concept only: GPL covers the licensed work and all works based on the work, where “based on the work” is defined as any modification or combination with the licensed work that requires copyright permission to make."
I don't know if that broadens or narrows, but I think that's the point: case law on "derivative works" was pretty vague (I'm unfamiliar but I'll take Moglen's word). But, to me it sounds like an effort to be more concrete rather than an effort to broaden the conditions under which you have release obligations.
> From the FSF’s licensing FAQ: ...
A couple things.
First, this FAQ entry is about aggregation; the paragraph above what you quoted is this:
"An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them."
This isn't some kind of "I run a Kubernetes cluster" situation, it's a "I ship a Linux distribution on ISOs" situation.
Second, I was in a different GPL thread [1] discussing some similar things, but all contracts, licenses, statutes, and founding documents have ambiguity in them. I listed a couple reasons (authors can't/don't want to exhaustively enumerate every scenario, human language is imprecise) but I realized I omitted a third reason: times change. You generally want whatever you're authoring to last a little while, not only because legal fees are expensive, but also because relicensing isn't always easy (GPLs have clauses in them letting you additionally license them under any later version, I would assume this is why).
And finally, there's a real double standard--or at least cargo culting--when it comes to the GPLs here. Here's some ways other licenses are ambiguous or potentially unbounded in their coverage:
- Apache License version 2: refers to "derivative works", also: "'Object' form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types." (i.e. does minification count?)
- BSL: also refers to notoriously vague "derivative works"
- SSPL: defines propagation partially with the phrase "in some countries other activities as well."
It's true the GPLs are more complex and ambitious than something like the ISC license (the favorite comparison around here, I think) but that license is something like 100 words. It's not comparable.
[0]: https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL...