The GPLs don't concern themselves with commercial use. You can use GPL-licensed software for any application you wish, that is what software freedom means. It's just that if you do use copylefted free software, you must provide, free of charge, the source code of the software using it and any modifications made.
If this weren't the case, then every web server running linux would have to offer their users the source code to linux. Seems pretty silly, probably most software shouldn't be AGPL.
AGPL is best used by projects that want to offer dual licensing for a fee, so they can get corporations to fund their development.
Most software probably should be AGPL licensed and its use is best for projects who want to protect what ought to be basic human rights which unfortunately aren't enshrined in law.
Oh give me a break. What basic human rights are being violated by Linux being licensed with the GPL? GPLv3 would be a nice improvement, but human rights violations for it not being AGPL??
I'm not a huge fan of AGPL but I think being "silly" is the least of my worries. A few redundant github links on the about page is a small cost for getting open source to stay actually open in the era of cloud services.
I do agree that it's "best" used in that kind of dual licensing, but I wish companies were less allergic to it so it could be used in general purpose ways. (It or a lawyer-friendly alternative.)
The FSF has a whole article on why you'd choose GPL or LGPL [0]. In general they agree with you that LGPL is overused, but they do identify a few reasons why you might choose LGPL.
That said, if the other option is something like MPL then I can think of a number of reasons why LGPL is better. At least LGPL ensures that modifications to your library itself remain free, whereas a more permissive license allows changes to be locked up entirely in a proprietary fork.
It's still more permissive than LGPL in that it isn't 'infectious' even when statically linked, the license only applies to the source file, not to any derived work. That makes the requirements more straightforward but does limit the freedom of the user to dynamically swap the library out for one that they'd prefer.
You're confusing "commercial" and "proprietary".
Also LGPL doesn't block static linking with proprietary software, it just want that you allow the end user to replace the library with a modified version, and there are several ways to allow it.
LGPL is pretty much the license for "if you use my code, you must also provide your customers a source copy of the same license, but if you ship a binary just let people know so they can ask me for the source".
Users get the benefit of not having to keep a source code archive for compiled libraries every release, but still apply GPL restrictions and rights if you decide to copy code from within the library.
If your customer is internal, that's not a problem. But realistically, internal tooling may as well be based on pirated and stolen code. How would anyone even find out?
I think it has its charms. You can use the library as-is and everyone who cares can find the source code elsewhere (it's probably on github somewhere anyway), but you can't take it as a basis and alter it to make your own project out of it without keeping the product open.
In the modern "everything requires HTTP calls to the network" era of software, AGPL may be a better solution for making sure the source code remains open, but for old-fashioned on-device apps there's a nice balance between freedom and obligations.
The freedom it was intended to preserve was the ability to modify the library and replace it, having your changes reflected in the application. Static linking breaks that freedom.
A bit off topic, but is there any data or estimates of how often big companies use modified versions GPL software/libraries for their web services without releasing their modifications?
No. This is normal native compilation mode. As you reference more features from either the standard library or the dependencies, the size of the binary will grow (sometimes marginally, sometimes substantially if you are heavily using struct generics with virtual members), but on average it should be more scalable than Go’s compilation model. Even JIT-based single-file binaries, with trimming, take about ~13-40 MB depending on the task. The runtime itself AFAIK, if installed separately, is below 100MB (installing full SDK takes more space, which is a given).
Spending ages slamming your head on your keyboard because you get a dll error or similar running a .NET app and just can't find the correct runtime version / download is a great past time.
then when you find the correct version but you then have to install both the x86 and x64 version because the first one you installed doesn't work
yeh, great ecosystem
at least a Go binary runs 99.99999% of the time when you start it.
Sure, but this team's focus is on Typescript, not C# / cross-platform AOT; there's only so much time in a day. Others can pick it up I'm sure.
But I think it's also an indication that Typescript may be bigger and more important for Microsoft than C#/.NET is at this time. It's definitely much more used than C# is according to this non-representative survey of Stack Overflow (https://survey.stackoverflow.co/2024/technology).
Absolutely. Go is where it is because of the parent org's commitment to dogfooding it; strange that Microsoft is wasting this opportunity AND sending a negative message to .NET devs.
I worry that because of things like [0] we we will start seeing guilt tripping old people into ending it sooner in order to not be a burden and to help their family.
Also, if you think that being a full blown adult guarantees being able to make smart decisions, just look for who adults are voting for in many countries around the world.
For latency sensitive use cases this is great news!
reply