I think we're really going to miss having the fundamental parts of the system available under strong copyleft, and it will be very hard to go back.
I will go on record now with the prediction that, if uutils catches on, Red Hat will be one of the last companies to move away from GNU. They are probably the largest contributor to glibc and GCC.
What evidence do you have that they would have "preferred not to provide source at all"? Because their is a mountain of evidence otherwise.
As an individual user, Red Hat will give you a free license to their flagship product. Then they will tell you how to download every line of code for it. I don't have a license. I do not use Red Hat (other than occasionally using the also totally free RHEL9 container).
"Remember when Red Hat tried to lock away the source code to subscribers only?"
I do not remember them changing the policy you are talking about. If you think they did, it highlights how overblown the response was at the time. The biggest impact of the Red Hat change is that Alma Linux is now a better project that can actually innovate and contribute.
https://arstechnica.com/information-technology/2023/06/red-h...
Again, be careful not to attribute past RH actions with IBM. Yes, IBM was very helpful in the 90s and later, but you can't fully trust a corporation past the next financial statement, and certainly not past a leadership change or three.
As he says, it's just business. And IBM isn't near the top on my list of big tech companies to avoid. However they are subject to the same enshittification pressures as the rest. Their history is not all rosy either.
Red hat provided the source to their kernel with the letter but not the spirit of the law, to impeed Oracle Linux. We'd (Ksplice) get the changes from Redhat version to version as one giant patch file, with all the changes mixed together. There's no chance in hell their internal kernel developers worked that way, but the source was there, so the letter of the GPL was satisfied.
The other thing they did was close the source repos. First you had to be a subscriber to get the binaries, and thus by the GPL, you could get the source. However, if you shared that source code with anyone else and they caught you, they wouldn't let you renew your license the next year, so you couldn't get the newer version, binaries OR source. This also isn't technically against the rules of the GPL, but it's hard to see that as being in line with the spirit of it.
It's hard to see Redhat as the benevolent GPL open source hug supplier with real world business practices like that. Not that I fault them for it, it's just business.
Unbreakable Kernel.
Apart from Clang/LLVM and WebKit you mean?
Ok in fairness the LGPL license of KHTML was a huge reason the WebKit source was available (for ages it was just reluctant tarball dumps) but I don't think that's the case for LLVM.
I don't think the GPL has really meant corporation's have given back significantly to Linux. There are still plenty of closed source drivers. The main motivation to give back is the extremely high cost of maintaining out-of-tree modifications (e.g. Android's binder).
The compiler and toolchain really are going the wrong direction with LLVM in terms of open source.
And hey some of the work does get upstreamed, which is probably a good choice for the vendor anyway if the target in question isn't intended to be immediately thrown in the thrash and forgotten.
It was originally supposed to. https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
Them putting the downloads of their enterprise OS behind a login screen (student and solo developer licenses can STILL be got for free) is something I 100% understand and am kind of sympathetic about.
I know that's out of like with how some people define free software, but I've always had ethical issues with the way people would redistribute Red Hats work for free. Just because it's legal doesn't make it ethical.
In particular:
> I think the GPL has led to fairly noticeable increase in the amount of proprietary software in the world as companies that would happily adopt a BSDL component decide to create an in-house proprietary version rather than adopt a GPL’d component.
It also aligns with my experience: my company couldn’t find an LZO compression library that wasn’t GPL’d, so the decision was between implementing one in-house or cutting the feature. We ended up restricting use of the feature to in-house use only, but opening up our core source code was never an option.
If there had been a permissive license option available, we would’ve likely donated (as we do to several other dependencies), and would’ve contributed any fixes back (because that’s easier to explain to customers than “here’s our patched version”).
Sorry, trust has been broken too often in these scenarios, and the benefits of lots more people working on the same library are not entirely clear.
I understand that many companies don't want to be a part of the pool of software licensed under the GPL - that is their right. But don't try to spin this "if only BSDL was the common one, there'd be a much bigger utilization of a different pool of software". That might even be true, but it would come with the caveat that tivoization would always be an option, which for some of us is something more significant.
If I put two choices in front of someone, the binary option of copyleft vs proprietary and they'll always go proprietary, or I give them something permissive and there's at least the chance they contribute back, the second option is strictly better. It's sort of the equivalent of having a wealth tax that raises no revenue, I'd rather have you here contribute something than move abroad and get nothing, even if the benefit is more indirect
We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.
Read LGPL a little more carefully. LGPL requires you to use it in a particular manner that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library. Even if you make no changes to the library!
I had thought that the dynamic linking requirement was the only option according to the licence, but apparently not. According to 6.a. of v2 and 4.d.0. of v3 of the LGPL, it would be enough to give the user access to the source/object code of the main application and the compilation scripts under non-open-source terms, so that they can recompile and statically link it against their own version of the library.
Partly related. Would you have paid if the project had offered a paid non GPL licence?
We probably would’ve for LZO too; not sure why that fell through.
How would the legal argument be any different for MIT/etc. licensed software in that case? Would the lawyers sign off on using MIT-licensed software without a CLA? Wouldn't they make the argument that the provenance of the software and therefore its licensing is not solid? Seems like the only thing that matters is who has the right to offer a license to the software, not what the license is.
I think the reasoning (as it was explained to me) was that when people made their original contributions, they were agreeing to the license at that time (in this case GPL, but for other projects MIT). But the other contributors never agreed that the main maintainer could relicense their contributions for a fee.
The upshot was that we went with an in-house fully-proprietary alternative. More expensive, probably lower quality.
Lots of people express this fear that BSD-licensing of components will lead to a world where all the big proprietary software just locks everything down. But if you actually work with large software, you end up finding out that it's actually a lot of work to maintain your own fork, and so you start pushing to get more things upstreamed. Because, after all, if your code is private, it's your task to fix it if somebody breaks it, but if it's upstreamed, it's their task to do it.
An interesting datapoint is LLVM/Clang, where, yes, lots of companies have their own proprietary forks of Clang. But for the most part, those companies still upstream gobs of stuff: most of the biggest contributors to the project are the people with the proprietary forks. Furthermore, as I understand it, basically everybody relying on EDG has, or is in the process of, worked to move off of it into Clang. Which, if EDG dies, means that the permissively-license Clang has done more to kill off proprietary compilers than copyleft-licensed GCC has.
The best defense against proprietary software is to make it too expensive for proprietary software to compete, and using a permissive license means you can trick the companies making proprietary software into helping you do that.
It's also an example of the GPL not preventing corporations from building (and releasing under a more permissive license) non-GPL software.
Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend. Sure, they published the source of their GCC modifications under the GPL, but that was nothing compared to the entirely novel backend, which was released under a far more permissive license.
Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.
[1]https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...
But they didn't! Dragonegg is a GCC plugin, which didn't exist when work started on Clang--GCC plugins date to GCC 4.5, released in 2010, which is the same year that Clang became self-hosting.
The timeline is rather like this: LLVM originally relied on a hacked-up version of gcc 4.2 called llvm-gcc to create LLVM IR from source code. When GCC added support for plugins, there was the attempt to move that frontend to a more reliable framework, and that was Dragonegg. As far as I'm aware, Apple never contributed to the Dragonegg project itself. Dragonegg didn't last that long; by 2014, the project was completely dead. And for most of its life, the biggest interest in Dragonegg was to have some modicum of support for Fortran.
> Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.
By the time of that message, RMS's worst nightmare had come true with Dragonegg... only for Dragonegg to have already died due to a lack of demand for it.
> the GPL has led to fairly noticeable increase in the amount of proprietary software in the world
What he did:
> opening up our core source code was never an option.
It's companies that decide that open sourcing their software is 'never an option'–even the LZO compression part of it–that lead to a 'noticeable increase in the amount of proprietary software in the world'. They are just using the GPL bogeyman as a thin excuse for their own decisions.
The absolute most that Canonical can do is start making a fork of the software where they don't distribute the source code. But in that case, the original code is still right there. No freedom is lost at any point.