Comment by dystnitem4r3 | Hacker News Reader

Comment by dystnitem4r3 | Hacker News Reader

Parent Full thread

Even more critically, dual-license commercial and AGPLv3 to avoid the AWS loophole (hosted services or source modifications without licensing it commercial.)

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.

> 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.

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...

Yep, I think the agplv3 behaves like the gplv3 for programs that are not network services.

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 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.

> I wouldn't risk this

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

My honest opinion is that the prevalence of licenses like GPLv3 and AGPLv3 end up indirectly leading to people recreating the wheel, rather than using the wheel that exists already.

Working as intended. If they don't want to share, then they can't benefit.

It's not so much that as there is the net-negative side effect of having people redo the same work over and over again at their day job or whatever. It horrifies me when I think about the number of hours of people's lives wasted on things like that.

It applies to both sides of the argument, with organizations keeping things to themselves or others avoiding codebases for the inverse reason.

> It's not so much that as there is the net-negative side effect of having people redo the same work over and over again at their day job or whatever. It horrifies me when I think about the number of hours of people's lives wasted on things like that.

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.

I would argue that in many ways (that vary from project to project) the duplicated efforts are a good thing overall. Now, instead of having one single group or person working on a particular topic, there are many and the knowledge, learning, experience, and expertise that comes from that isn't locked up with only a select few. That can be applied in more areas, used for more things, or carried into other endeavors. It also hedges against all that expertise being lost if the few experts of the original project abandon it for whatever reason.

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.

But who cares if someone chooses to redo work they didn't have to? I don't care about that at all. Self inflicted wound.

They presumably can salve that horrible wound with all the money they get (not make or earn, just get) from their chosen modus operundi.

Absolutely. LLVM exists because GCC is GPL; that's a feature not a bug.

LLVM exists because its original developers wanted to do research, not because of GPL and at the time there wasn't even a C compiler for it, not to mention that GCC wasn't designed at all to do what LLVM did.

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.

They could have very well used lots or reusable parts of GCC. It was possible, and were many projects trying to change GCC.

gcc was specifically designed to not have many reusable parts to avoid people ripping them out. modularity only happened after LLVM and clang specifically started eating its lunch.

> LLVM and clang specifically started eating its lunch

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?

Basically most of the embedded folks that used GCC forks are now on clang, and if in the old days they were breaching GPL, nowadays they are fully compilant, so not upstreaming is not even a legal issue any longer.

Fair enough. I guess you're talking about microcontrollers rather than lightweight CPUs, at least in my experience it's still standard to use GCC on the sort of dinky ARM-based devices my company produces.

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.

Sure, but they didn't even do that most of the time, with MIT that isn't even part of the conversation.

Most certainly not. The modularity was not great, but BIG chunks of code could be copied. I did that myself.

I don't even understand how you can point to LLVM as an example of this failing. GCC is still alive and well, and perfectly suited for the task it was always intended to fill. People that wanted a commercial C compiler always had the option to purchase one at-cost, GCC was intended as an alternative to that process, not the alternative. It may be hard to remember, but less than 50 years ago squabbles over compiler licensing was what most developers had to deal with.

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.

Also after LLVM came to be, GCC gained on its official collection Go, D, and Modula-2 frontends.

And, hopefully, Rust soon as well[1][2][3].

[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...

I think wheel-reinvention is the perfect punishment for people that want to be stingy with their wheel development. Copyleft infringement deserves no more empathy than copyright infringement.

Reply on news.ycombinator.com