I just wish it was copyleft like the real coreutils instead of being pushover-licensed. Now the corporations are all going to start making proprietary forks of this.
But now you've got a private fork to maintain. The guy who figured out the optimization was promoted and switched orgs, so the other guy on that team is in charge. There's not quite enough work for him to work on merging stuff in full time yet, so he'll do other stuff, but within a few years, keeping your private fork up to date with security patches is a full time job, then more than a full time job, and nobody wants to join that guy's effort because there's no glory and no promotions in it. But there's no getting off this ride anymore, and nobody's doing expensive performance testing anymore because the guy who knew how to do it is long gone, so I hope it's still making a difference. Ugh. Just share the fix.
The fixes/extensions are shared, but don't expect them to be looked at. On some projects some PR will take years. And some, like OpenSSL or coreutils outright refuse to add new features, or fix code quality.
These are still OSI endorsed licenses of course. So, bona-fide free and open source software as defined by the Open Source Initiative.
Referring to them as push over licenses is not really that constructive. All sorts of respectable OSS software is licensed with these licenses. I'd go even further and state that if you remove all the OSS software that doesn't have a copyleft license, the whole landscape would get a lot less interesting. That gets rid of most popular libraries, lots of popular software packages, all kinds of critical could infrastructure components, development tooling, etc.
The vast majority of OSS software I depend on is actually Apache 2.0 and MIT licensed. There's a fair bit of GPL v2 and MPL in my life as well. GPLv3 and AGPL are just much more of a fringe thing. I tend to actively avoid depending on any such software. Just too much hassle in terms of endless debates of what is and isn't allowed with such licenses and people getting upset if you actually try to use the software for something not endorsed by them. Mostly the venn diagram of such people and people producing useful things to me is pretty narrow anyway. I know legal departments in big corporations tend to have similar policies.
Ever heard of Android, cloud or SaaS? For example our phones and the cloud services they use are choke-full of FOSS, but we plenty of surveillance and very little freedom. Same for modern cars, TVs and many other things.
There are plenty of user-hostile services that use FOSS internally. Weak licenses are huge enablers for this behavior.
To copyleft people that's a bug, for most Linux users, that's a key feature of the license. Without that, we'd all be using BSD (like most mac users are) or something else.
None of that software would have happened if it weren't for big corporations putting their resources behind those things AND pooling their resources by sharing code under an OSI approved license with each other. This is open source working as intended. Millions of developers are creating value and are relying on each other. And yes, some money gets made in the process. That's the whole point of committing that much resources. Most software development simply is not charity. And the willingness of companies to spend resources on software is typically motivated by their ability to use the resulting software.
And people can and of course do fork Android. E.g. Amazon and Huawei, etc. have nice products based on Android that don't include any Google proprietary bits. And there are many other android based and derived things out there. Likewise the various cloud providers have a lot of shared components that they depend on and they also are contributing a lot of code. Many of the smaller ones pretty much just use things like openstack. And they all rely on the same big open source things: Linux, Mysql, Redis, Docker, etc.
This would simply not happen with licenses such as AGPL. Easy to say, because it hasn't happened and shows zero signs of actually starting to happen.
Good!
And that's why its extremely imaginary in this context, these are "core utilities", not a distributed database. Their value is in being the same everywhere and installed on every system, not in a SaaS interface. The very basis of uutils itself is that it is the same as the GNU equivalents.
One irony is -- look at the linked article's comments -- I have to imagine some of the people saying "Rust is not ready for X because it doesn't have multiple implementations" are the same people saying "Don't create an alternatively licensed implementation of coreutils". Just completely unprincipled, untethered reasoning.
And don't forget the king of ironies -- GNU coreutils themselves are a reimplementation of proprietary code.
> There are plenty of user-hostile services that use FOSS internally. Weak licenses are huge enablers for this behavior.
This is obviously a red herring. Any bad behavior would be the same re: the GPL and the MIT license in this particular instance.
The answer is always -- do better than your competitor. If the GPL is better, fork the MIT code, and build a better alternative. The problem is -- the people actually contributing chose the MIT license. And that should be the end of the matter. You don't get to have an opinion on someone else's choice of license if you contribute nothing.
This combination of bullying and whining by GNU/FSF advocates is extremely off-putting. I'm a contributor to uutils (but I don't speak for it!) and watching the apoplectic whinging by Redditors and HN commenters just re: this project has completely turned me off the GPL for my other projects. When will people realize that being a completely insane socialist/MAGA/atheist/Christian/FOSS advocate at a dinner party is a turn off?
Interesting to hear given how much whining I heard in your and other replies...
> completely insane socialist/MAGA/atheist/Christian/FOSS advocate at a dinner party is a turn off?
Plus you are resorting to insults and yet you claim I'm the unreasonable one.
> Plus you are resorting to insults and yet you claim I'm the unreasonable one.
I don't think I characterized anyone as unreasonable. Your examples are not analogous to the present situation, but I think your real problem is you're telling other people, very well aware of the Good News of GNU/FSF, something they already know.
I, and others, have taken a very clear eyed looked at the GPL/FSF and said "No, not for me," and I wish you'd understand one of the reasons why is yours and others rampant religiosity. I don't comment under GPL licensed project, "Hey I wish you'd change your license to MIT because [red herring, and bad faith argument...]" because I know it's in incredibly poor taste as a non-contributor. MIT/GPL/AGPL/etc isn't always my cup of tea either but its simply not my choice.
That said -- sure, if you/anyone has a merits based case to make as to why something makes more sense as GPL licensed, I'm all ears. But, as it stands, your arguments are in poor taste.
So the argument "use a copyleft license or get your work stolen like android" doesn't really work. You'd need to argue that you need a strong copyleft license. Which is a tougher argument to make, because people dislike those more.
MIT is a good choice for maximizing adoption, which possibly is their intent.
>Now the corporations are all going to start making proprietary forks of this.
I have a hard time coming up with a scenario where a company would do this. There's literally nothing to gain from doing so.
And yet KHTML was forked into WebKit which was forked into Blink, just to name one.
OSX has forked BSD code, as did windows.
This things happen all the time. MIT is a fine license, so is GPL, but we can't just say "oh nobody is going to fork this, it's dumb!" because it happens all the time.
Bad example. KHTML was LGPL-licensed when Apple forked it (looking at https://invent.kde.org/frameworks/khtml, it may be dual LPGPLv2/GPLv3 or later licensed now). That probably is _the_ reason WebKit always was open source.
The license matters less than you might think.
What could you possibly add to coreutils that would make a proprietary fork sustainable?
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.
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.
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.
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-...
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.
For example, we have Rocky and Alma Linux because so much of RedHat is based on GPL-licensed GNU/Linux. They technically don't have to release any of the MIT components, they do it because they are nice stewards of open source. Same with Ubuntu. And SUSE. Other companies could be not so nice. For instance, note that Google Chrome is not technically open source. Only Chromium is, which Chrome is built from.
In reality, MIT binaries without the source code are rare.
Yes, the GPL is very important. The BSD license _is_ a problem. Those of you that were around when FreeBSD was maybe going to 'win' remember why Linux(GPL) ended up capturing everyone's attention.
You can not count on your code staying free if it's under a BSD license. If there is a way to make money on it, someone will fork it privately and force you to pay for it. If they don't succeed, you will still be under continual threats that you will have to pay for it.
Jesus, you think s/he ever wondered how AT&T felt about Linux and the BSDs literally reimplementing all of Unix?
Oh, that's right. This is the FSF/GPL conundrum -- you're likely to end up on both sides of every issue. You will literally be both a copyright maximalist re Linux and a copyright minimalist re proprietary code, music and film.
Huh, never heard the polite form of that term.
I've worked in the community and it's annoying that it's so against GPL in some corners, but most people are just pragmatic. They use whatever license is the norm for sharing with their community.
Now that Rust is becoming less tight knit it might open up, hopefully, to more diversity in licenses.
AFAIK there definitely is a preference for Apache/MIT dual licence but this is probably because of the influence of the Rust compiler itself. Most of the initial Rust code was written by people involved with and in service of the Rust compiler. Since that’s licensed MIT/Apache, their code had to be as well if it wanted to be used in the compiler.
There were people who used funky licenses like WTFPL (whatever the fuck you want to) and Unlicense (public domain) but they came around and licensed to MIT/Apache for uniformity with the rest of the ecosystem.
Maybe if the compiler had been GPL the ecosystem might have been as well, but that’s a what if. We’ll never know if a hypothetical GPL Rust would have had the same path to success as the existing Rust.
If we want a software commons we have to say that upfront, not try to imply it via legalese, and then get offended when fractions emerge.