There’s a reason I choose MIT over GPL. It’s a freer license.
If the choice is "you only have one choice", that's not really a choice at all?
I have complete freedom to choose the licenses for my personal projects and I stay away from GPL and its variants (still love copyleft and the MPL2!), because devs are users too, and I (and they) see the GPL as very dev unfriendly.
The GPL treats "users" and "devs" as abstractions, when in a very real sense, the devs are the ones most likely to use the code, and they are more likely to use it when it's more permissively licensed. And many are very pleased/want to use copyleft, if it isn't the GPL, and the FSF's ridiculous interpretations thereof.
Copyleft software has several vendors compete around the same product. Every economic actor has to compete to add business value and consulting, with the knowledge that any extension to the software is made available to everyone else.
Free and non-copyleft software leaves vendors free to compete with different products built from a common base. Extensions to the software has commercial value and every vendor seeks their local maxima.
So the situations are different. GPL and BSD software do not often compete in the same space, with a few exceptions. There used to be a commercial variants of BSD, but they are all gone, outcompeted by a common Linux platform. FreeBSD was technically superior for a long time but couldn't compete with a multi vendor product in the long run.
Products that represent a common platform shared by several products however are more successful non-copylefted. Formats such as gzip and jpeg are completely dominant due to their multi product usage, and any GPLd codecs that competed with them are mostly forgotten.
Also regarding GPL versus MIT compilers, guess whose column wins out in red squares,
[0] https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...
While Apple and Google have switched focus to their own efforts (Swift, Objective-C, Carbon, C++17 being good enough), there are plenty of compiler vendors on that list with forked clang for their proprietary compilers.
The only proprietary fork of LLVM in the compatibility table you linked is less C++20 compliant than free software Clang.
So unless you have some causative explanation, I think the more sensible possibility is simply that the Clang developers have prioritized working on some of the plentiful other features of a compiler toolchain than perfecting their C++20 standards compliance.
Blindly asserting (or implying) that if LLVM were GPLv3 then it would be more standards‐compliant, with nothing to back it up, doesn’t add much to the discussion, IMO.
Even if not, they are clearly waiting for others to do the needful for free, and then gladly recoup the fruits of others labour while selling their compilers for profit.
It's very possible that the core maintainers personality played a bigger role than the license.
If you look at the current situation where each SoC supports only one (generally very old and very vulnerable) kernel, I think we have an the reasons to be happy that they at least have to release the sources so hopefully someone can extract the patch and have it work on recent kernel. It's not very hard to imagine the situation where we'd only have the binary kernels if we did not have the GPL.
The problem is, many vendors don't release their kernel sources at all - particularly Chinese pseudo-brands based on some knock-off of Mediatek reference designs come to my mind - and those that do release their code often show horrible code quality that would take many man-months of work to clean up enough to be included into the kernel, not to mention the lack of documentation and the tendency for these forks to fix undocumented hardware quirks for specific SoC revisions in kernel code.
And Google, the only entity in town that could push for better behaviour at least in mobile, doesn't do anything to help out on that front as well - there is not a single mention in the CDD [1] (the requirements if you wish to call a device Android compatible and use the Google ecosystem) mentioning licenses outside of a warning that implementers have to take care about software patents for multimedia codecs.
Non-phone/tablet embedded applications are even worse. I admit my knowledge is dated, but I came across a lot of devices over the years where their source code dump had u-boot versions that were half a decade outdated and so many changes done compared to even the version of u-boot that it claimed to be that it was completely infeasible to even attempt and migrate the changes to a modern u-boot version.
And to make it even worse: Modern "device integrity" crap makes the situation completely impossible to resolve - even if you had a decent-quality code dumps not deviating too much from upstream, you can't deploy your code to the actual device in question to test if the device still works because the device doesn't allow flashing unsigned/self-signed images, test points (e.g. JTAG) are fused-off in hardware, and even if memory chips can be flashed with a programmer (which isn't a given, since if you power the flash chip using a clip probe, often you power the rest of the board with it!) the flash chip content itself is signature validated. Oh, and it still can get worse than that given the rise of "secure element" co-processors that can be used to decrypt flash chip content on the fly - you don't even have a chance to read the firmware content without first having a code execution exploit on the device and then achieving code execution in the "secure element". The people able to do this are short in supply and most of them work in jailbreaking gaming consoles, not a 30 dollar Chromecast or similar appliance.
We need laws and regulations against that crap, but politicians don't even have that on their radar - how would they, given that a lot of politicians are fucking gerontocrats and of those that aren't, no one outside the various European Pirate Parties and affiliates has a tech background to even push for such regulation.
[1] https://source.android.com/docs/compatibility/12/android-12-...
Weren't Amazon and ElasticSearch on news a few years back about some license changes?
That sounds even worse. Whatever happened, ES didn't gain anything by having an open business friendly license (as it appears from the events).
> As Elastic is making money by selling hosting, they did not like the (admittedly unfair) competition from AWS, they decided to stop doing Open Source.
That's sad. ES went from "business friendly opensource license" to "closed source". Now there's no open-source code at all (from ES). Some restrictive open-source code is better than closed source. Always.
> And actually now, AWS is maintaining an open source fork of ES...
I think, it's not out of generosity. It has customers.
They did profit from being open source, being based on apache lucene. They profited from the work that the community did for them - I used to be part of the folks running one of the user groups. I was on their IRC channel, helping other folks adopt ES, for free, because it was open source. And they did flip those folks a finger and went and made it closed source because they ended up having a spat between businesses. It's their code, I get it and they get to do whatever they decide. But Elastic is very much not a paragon of open source virtue in shining armor. They, too, have placed business interest before community interest.
Edit: grammar, spellings
The interesting thing is that Elasticsearch has an open source competitor, Apache Solr. The community around Solr is organized more like the community around postgres - multiple actors that work on a shared project that not a single one controls. Anyone of them could make a proprietary fork, but the others could quickly band together and punish that.
So the lesson to draw here is maybe that the license itself matters less, but what matters is whether there's a single actor in control of the project. Because in the end, the reason why Elastic could pull this stunt is less about the license, but about the copyright ownership and control over the project. They owned the code, had a CLA in place for any contribution and thus could do whatever, license be damned.
You are quite right to some extent about corporate policy differences. I think the status quo might be trending away from this extreme caution, but it's still there in many corps.
I don't think it's fair to say ES is now closed source. It's no longer FOSS nor GPL-compatible, but the source is very much still open, and nothing much has changed for many users of the self-hosted versions (source: shipping a proprietary appliance-like product with ES as a component, with full legal checking that we are in compliance of the license).
Open source projects that relied on ES are cut off.
Now, if you were distributing a GPL product that included ES, you will have significant problems, since the GPL and SSPL are not compatible - so you may in fact be unable to distribute the whole product anymore, which probably caused huge disruptions to some projects - so I'm not in any way saying that what they did is nice. But it was definitely not making it closed source, not in spirit and not in effect.
You're mixing up open-source with visible-source or source-available.
I explicitly noted that they are no longer FOSS, but I beleive its wrong to call them "closed-source".
If parent had said "they are no longer open source", I wouldn't have commented this at all, since "open source" and FOSS are essentially synonyms. But the antonym of FOSS/open source is not "closed source".
This whole thread is about complaining/supporting this attitude - not about criticizing those who simply chose the GPL as their license.
And they are, that's what choosing a licence is all about. In case of MIT/ISC/BSD/WTFPL licensed software, this someone else just decided to dictate a lot less than he could have.
If companies can make proprietary forks, I can make a GPLv3 fork. Best of all, no company can take my changes and make them proprietary. And if the maintainers want to merge my changes, they've got to relicense to GPL.
I mean, you’re free to do that, but taking pride in it sure feels odd to me.
License choice is a political choice, and it's not a coincidence that corporate-friendly licenses are usually on projects that have a strict vision and reject outside changes.
I've got the features I want, in the way that I want them. If you want to use them, you're free to switch — for some of my projects, tenthousands of people have done so.
Is that possible? Choosing to publish something to... oh, let's say to release it into the public domain (that seems like the farthest you can get from copyleft) is still an ideological position.