I can see it has some disadvantages for companies incorporating GPL software in their products, but none for companies merely using GPL 3 software.
If I had to guess - The patent rights clause weirds out a lot of lawyers. Obviously anyone who works with hardware doesn't like the anti-tivoization clause. Another possibility is the AGPL (which IS lethal for obvious reasons) is often conflated with GPLv3.
All I know is GPLv2 is fine, GPLv3 is usually not, and AGPL is never possible in corporations that I've worked for.
> I can't say for certain why they can't use GPLv3 - just that no company I've ever worked for (n=4 since GPLv3 came out) - will allow it on premise
So they do not allow the use of things like Bash or GNU coreutils? That seems quite restrictive and difficult.
Apple is different as they produce their own OS. I am asking about non-software companies avoiding GPL3 which would be necessary for (as the comment I responded to earlier in the tread claims) the use of GPL3 providing a motive to pay for licenses for dual licensed software in a way GPL2 does not.
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...
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.
My limited experience with IP lawyers at big software companies is that they have zero understanding of software licensing and patent law. They just seem to parrot some line they learned in college 10 years ago, even when the plain text of the license or law sitting in front of them proves them wrong. It's honestly baffling how they get these jobs.
Otherwise it works great for end-user adoption.