It applies to both sides of the argument, with organizations keeping things to themselves or others avoiding codebases for the inverse reason.
Given that this issue applies to all proprietary/non-opensource software, which is the overwhelming majority of software out there, you can hardly blame GPL3 for this fact of life.
They presumably can salve that horrible wound with all the money they get (not make or earn, just get) from their chosen modus operundi.
I don't see all the efforts that go into *BSD, Windows, macOS, etc... as being wasted just because Linux is available, nor would I consider the effort to try something completely new in os/kernel design that starts from a clean slate a waste, even if it doesn't end up becoming wildly popular. Not everyone who has the capacity to work on a duplicate effort would be able to contribute to the original, and the original will never be able to perfectly meet the goals/needs of everyone.
The license angle with Apple did happen because of GCC's switch to GPLv3 but that came years later - and GCC still wasn't (and AFAIK still isn't) designed to be used like LLVM or (later) Clang, like using it as a backend for IDEs, analyzers, language servers, etc. The two projects aren't interchangeable with only the license being the thing that differentiates them.
I don't know how you can eat GCC's lunch. I feel like in this analogy GCC eats from a communal trough and is very happy to share. A company that sells licenses can lose customers, the GNU project just wants the world to benefit. GCC is still ubiquitous and has plenty of developers and mindshare, what more could they want?
I'll note that GPL never says anything about upstreaming. It can certainly make life easier if you want to keep your patches up to date and hand off maintenance responsibility, but it suffices to make a written offer of source code under the same license (on a conventional medium) to your customers to comply with any GPL version. You're never obliged to upstream or even publish your code.
Respectively, LLVM fills it's own gap nicely. It has the classical BSD-like issue where hundreds of unique and disperate forks exist with no roadmap to bring them together, but that's also technically a "feature" of each license and not a bug. If GCC developers felt their job was obsoleted by Lattner, there wouldn't be a reason to update and maintain it. The end result has been healthy competition, accountability for either team, and better optimizations for everyone using either compiler.
[1] https://rust-gcc.github.io/
[2] https://github.com/Rust-GCC/gccrs
[3] https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...
This is actually fairly ambiguous in the text. It says "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version". This is fairly straightforward when applied to a database—if you modify an AGPL database and offer it as a hosted version then your users are obviously interacting with it over the network—but much less straightforward when talking about an AGPL program that doesn't intentionally build in network connectivity.
The GPL FAQ addresses this provision [0] and it seems to support a more conservative reading. My understanding from the FAQ is that a Program that is not "expressly designed to accept user requests and send responses over a network" derives no benefit from being AGPL vs GPL, even if a web app interacts with that AGPL code over IPC or similar.
[0] https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
With the twist that if your non networked, agplv3 program happens to contain code that's interesting to build a network service, this code can only be used under the agplv3 :-)
This code can only be used to make a derived work under the AGPLv3. What constitutes a derived work is still... complicated.
I wouldn't risk this in a production setting for a real business just out of caution, but my reading of the license would suggest that you'd be perfectly fine to wrap AGPLv3 code in a web service and then have your own code interact with that web service. Release the wrapper service as AGPL, but then the rest can be proprietary.
The main protection that AGPL gives isn't legal, it's that you scare most legal departments away just because it's such a weird license with no established precedent.
AGPLv3 is perfect for kernel and userspace tools because, while it doesn't guarantee licensing revenues, as soon as they do anything to modify it they have to release those changes to ANY users of the system, whether downstream distributors or simply users of the network services they provide. Since they have to provide any IP/patents they used to do it under copyleft terms, QNX would get publicly visible benefits, albeit with changes that might not be useful under the commercial license without negotiating a CLA with the modifying party, but under the commercial license you could negotiate terms/a discount to trade their new code for a reduction in their cost of licensing. It's a win/win from either an open source PR or a behind the scenes commercial negotiation point. Obviously your lawyers, bean counters, and C-suite have to get onboard, but if you are serious about growing QNX's marketshare now that Linux is gaining real-time kernel support in mainline, you had better point out to your bosses they need to make the decision quick and stick to it, or there won't be a next time.
Edit: Adjustments made to clarify my position and suggestion.