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.

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.

This seems like a technical workaround for a legal requirement. Indeed, that seems risky xD

Yes. And it is even more than that.

Blackberry could have a general QNX verison under AGPLv3 and keep the "safety certified" version proprietary and they would not loose a single customer.

What the automotive world, robotic world and others are paying for... is not the Operating System, it is the safety critical certification of the Operating System.

Making an RTOS is easy. Making an RTOS plus a compiler ISO26262 ASIL-D certified is a freaking nightmare. This is precisely what companies are willing to pay for.

Opening the QNX source code under GPL would widen significantly the number of software ported on QNX and the adoption.

Unfortunately, Blackberry is way too stupid to do it and it is unlikely to happen.

GPLv3's protection against locked systems isn't as strong as people often think it is.

In the case of cars at some point the makers are going to realize that instead of including firmware with all the features the car can support they can switch to shipping the car with a more basic firmware that just has built in support for basic car features and has an app store.

They can then put all the other features in apps that you have to buy (or subscribe to).

If that basic firmware is locked down so it can't be replaced by the user then they do indeed after avoid using GPLv3 for any code in that firmware.

The GPLv3 provisions about locking thing down do not apply to apps downloaded from an app store. They designed those previsions to stop what Tivo was doing, which was ship with a locked down operating system, and they wrote fairly narrow terms that don't cover much outside that case.

In particular, they apply when you convey object code of a GPLv3 work in, with, or specifically for use in a "User Product" and that conveyance is part of a transaction "in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term".

I.e., sell (or rent or lease etc) hardware that includes GPLv3 code and you have to provide a way to replace that code with modified versions. Sell (or rent etc) GPLv3 programs separately from hardware and then GPLv3 is neutral on locking it down.