There’s nothing more annoying than GPL absolutists. Who really cares if someone makes a closed-source fork of the code? On the other hand, given that closed-source code is going to exist, isn’t it better if it’s able to use the best code available rather than forcing developers to either ignore the existence of something because it’s GPL’d or just ignore the license in the first place?
There’s a reason I choose MIT over GPL. It’s a freer license.
GPL protects the software itself against becoming proprietary. Developers are forced to ignore GPL'd code only if they are unwilling to distribute their code under GPL, because the company is unwilling to make a pledge to respect the freedom of the users. Writing more GPL'd code gives advantage to those who are willing to respect the user's freedom.
> Developers are forced to ignore GPL'd code only if they are unwilling to distribute their code under GPL
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.
"More" or "less" free is a word definition game that is mostly a chimera. It depends on what the purpose of the software is and which business model is the most fit.
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.
That is why FreeBSD is everywhere, with nice contributions from all its commercial users, and clang is ISO C++20 compliant thanks to all those nice compiler vendors thinking of upstream.
Linux owes its ubiquity over the BSDs more due to the fact that it didn't have to fend off lawsuits at a critical point rather than due to license choice.
Minix is BSD licensed and is present in Intel CPUs[0]. So I think it would be a toss-up as to whether BSD or GPL-licenses OSes are more widely used overall. To be clear, I'm making no comment on whether Intel using Minix is a good thing for their customers, but it's likely that the BSD license was what Intel wanted and caused it to become the most widely used OS few people know about.
I know that was not your main point at all, but fascinating to see that MSVC is the only compiler to be fully 100% standards compliant (with only GCC being really really close).
Yes, LLVM has achieved the same contribution level as the Linux kernel[0], yet where are the contributions from ARM, Intel, IBM, Apple, Google, Green Hills, Codeplay (now Intel), NVidia, Nintendo, Sony, TI.... into clang?
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.
And which of these proprietary Clang forks have greater C++20 compatibility than free software Clang?
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.
Who knows certainly? We would need to buy them them all.
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.
Consider the Linux kernel. First it would probably have never been successful with a liberal license in the first place, but let's ignore that for a second and assume it got successful anyway.
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.
> 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.
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.
I would rather have transparency and portability (from having access to the source code) than quality code (you would be surprised how many project are written in extremely bad quality).
The thing is, we already have transparency and portability, and yet it is effectively useless because the code is in such crap quality that it is completely infeasible to do any serious work with it, and because bootloader security makes third party development very difficult to outright impossible (not to mention fourth parties like banks, games or DRM punishing you for exercising your rights by cutting off your service).
My understanding is that Amazon was not even making a closed source fork of ES, they were merely offering managed hosting of the open source version of ES. 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. And actually now, AWS is maintaining an open source fork of ES...
> Amazon was not even making a closed source fork of ES, they were merely offering managed hosting of the open source version of ES.
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.
Elastic has never been doing open source for generosity - they have customers. They're admittedly much smaller than AWS, but they're venture backed and have money. They're not a small open source project, even though they sometimes portrayed themselves as such.
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.
Right. Elastic didn't do it for generosity, either. But your point that ES got benefited from the business friendly license and then made it closed source just supports my point that businesses will just maintain their forked-version rather than putting it out there in the open. I'm all in for open-source software, but I'm just making a point that business-friendly open source licenses don't necessarily beget more open source code. Sometimes a restrictive open source license like (GPL) is far better than a business-friendly license for open source community.
GPL would not have had any effect in Elastics case, private forks are legal under the GPL. AGPL might have. But then again, AGPL would have been a major hindrance for corporate adoption since no one wants to open source their whole tech stack just to add search.
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.
AGPL or GPL doesn't matter here - AWS were fully compliant with the AGPL in their use of ElasticSearch (they were already releasing all the code, even though they were providing it as a managed service).
AGPL would probably matter here - it's viral and would potentially require open sourcing all software in the stack that interacts with it, for example the systems that AWS uses to manage the Elasticsearch instances. In any case, AGPL is on the "do not use" list for many enterprises, regardless whether it would have any effect or not in the specific case. Engineers that want to use AGPL software often would have to go through legal, so it does stifle corporate adoption.
The only difference between the AGPL and the GPL is whether offering access to the software over a network is considered distribution or not by the license itself (AGPL says yes, GPL says no). Otherwise, they are both exactly as viral.
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.
> And they did flip those folks a finger and went and made it closed source because they ended up having a spat between businesses.
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).
It is no longer open source, there’s no doubt about it. You may have a free beer license to it as long as elastic grants you one, but you have no right to modify, patch, redistribute as you see fit.
Open source projects that relied on ES are cut off.
You are still free to modify the code, patch or redistribute it under the terms of the SSPL. If you prefer the ESL, you may only modify the code, but not redistribute it.
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.
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".
I don't remember which license ElasticSearch used to be under back when it was open source, but there are others who faced the same problem even with the most copy left of licenses. MongoDB wen through the exact same problems and changes, even though it started under the AGPL. So exactly what kind of OSS license Elastic had been using is irrelevant - you can't compete with AWS on hosting open source code.
This went in the opposite direction you'd expect. The original ElasticSearch is proprietary now, and Amazon's fork of the last FOSS version is itself FOSS.
The ideological position is the whole point of the GPL, after all. If you're using someone else's labor, it's only fair they're allowed to dictate the terms of how you're allowed to use it.
> If you're using someone else's labor, it's only fair they're allowed to dictate the terms of how you're allowed to use it.
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.
Except many of them then come out complaining how Amazon (just to pick an example) is leeching their work, while they are perfectly in line with the chosen license.
And that's why whenever I want to contribute to a MIT/ISC/BSD/WTFPL licensed project, instead I just fork it and make my own changes GPLv3 only.
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.
When you fix a bug in X11, you keep it in your one‐star‐on‐Gitlab personal fork under GPLv3 to prevent it from ever making it into HP‐UX, rather than contribute it to the upstream project, where tens or hundreds of thousands of individuals using X11 under free and open source licensing in free software distributions (not proprietary forks) could have experienced the benefit of your fix?
I mean, you’re free to do that, but taking pride in it sure feels odd to me.
I don't use X11, but I've had a very negative experience trying to contribute back to MIT/BSD/etc licensed projects anyway, as they're usually just one close team of developers publishing something and rejecting any outside PRs or requests.
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.
Plenty of GPL fans try to convince others to choose the same license, almost always implying that the GPL is the only moral/ethical choice (Stallman himself being the most ardent believer of this stance). They often even insist that the GPLv2 is not actually a moral choice anymore, given the evils of TiVoization.
This whole thread is about complaining/supporting this attitude - not about criticizing those who simply chose the GPL as their license.
What you’re implying is a fault exclusive to “non‐copyleft fans” happens in copyleft‐licensed projects too, like MongoDB, which was AGPL before it decided to switch to an even more restrictive license to counter hosting service companies.
A: "This is why I don't use GPL"
B: "Yes, you shouldn't have to take an ideological position just to publish some code"
C: "But the ideological position is the whole point of GPL"
D: "but the ideological position is not the whole point of writing code."
C: "Then don't use GPL code?"
D: ".... exactly?"
> How about the freedom to ship something without having an ideological position on when/how it links against other code.
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.
Firstly, closed source would likely be the antithetical counterpoint to GPL. I refuse to even call it copyleft, because that term is a purity test. I’m a leftist and I BSD/MIT my work so that others may benefit from it. If it’s valuable, they may contribute back. If they don’t, I still haven’t restricted their freedom or choice. An ideological position is usually one that is rigid and uncompromising. GPL/‘copyleft’ is a way of poisoning the commons.
If you release something and expect to retain copyright — that is, you wish to prevent me from decompiling it, redistributing it etc — then you are also taking an ideological position.
There’s a reason I choose MIT over GPL. It’s a freer license.