I'm only half-joking when I say that one of the premier selling points of GPL over MIT in this day and age is that it explicitly deters these freeloading multibillion-dollar companies from depending on your software and making demands of your time.
I don’t think many projects see acquiring unpaying corporate customers as a goal.
On some of our projects this has been a great success. We have some strong outside contributors doing work on our project without us needing to pay them. In some cases, those contributors are from companies that are in direct competition with us.
On other projects we've open sourced, we've had people (including competitors) use, without anyone contributing back.
Guess which projects stay open source.
I'm interested in people (not companies, or at least I don't care about companies) being able to read, reference, learn from, or improve the open source software that I write. It's there if folks want it. I basically never promote it, and as such, it has little uptake. It's still useful though, and I use it, and some friends use it. Hooray. But that's all.
Security issues like this are a prime example of why all FOSS software should be at least LGPLed. If a security bug is found in FOSS library, who's the more motivated to fix it? The dude who hacked the thing together and gave it away, or the actual users? Requesting that those users share their fixes is farrr from unreasonable, given that they have clearly found great utility in the software.
This isn't a popularity contest and I'm sick of gamification of literally everything.
I have mentioned this in the past, but there was this weird shift in culture just after 2000 where increasingly open source projects were made to please their users, whether they were corporate or not, and "your project is your CV" became how their maintainers would view their projects. It does not have to be this way and we should (like it seems to be the case with libxml2) maybe try to fix this culture?
Not true. Many companies uses Linux for example.
They will just avoid using GPL software in ways that would impact their own intellectual property (linking a GPL library to their proprietary software). Sometimes they will even use it with dubious "workaround" such as saying "we use a deamon with IPC so that's ok"
Anyway, the GPL is there to protect final users and not the maintainer of the project. And if a software is running on someone else server, you are not the user of that software. (Although you use the service and give the data, but that's another problem)
In short, Apple maintain a 448 kB diff which they 'throw across the wall' in the form of an opaque tarball, shorn of all context. Many of the changes contained within look potentially security-related, but it's been released in a way which would require a huge amount of work to unpick.
That level of effort is unfeasible for a volunteer upstream developer, but is a nice juicy resource for a motivated attacker. Apple's behaviour, therefore, is going to be a net negative from a security point of view for all other users of this library.
There isn't much difference between MIT and GPL unless you are selling a product that runs locally or on premisses and with the latter some companies try to work around GPL by renting servers with software on it - either as physical boxes or something provided on cloud provider marketplace.
Look at what you actually have installed on your computer - odds are that unless your job requires something like CAD, photo/video editing or other highly specialized software you have nothing made by large enterprise with exception of OS and Slack/Teams/Zoom.
That's fine for feature requests, but the issue in the present case is bug reports.
> Not true. Many companies uses Linux for example.
I thought it was clear, given that this is a discussion about an open source library, that they were talking about GPL libraries. The way that standalone GPL software is used in companies is qualitatively quite different.
Maybe they are doing their own security fixes, but at this point they are so far diverged from upstream that it isn’t clear that those security bugs exist in upstream.
But that is my guess, I don’t really have enough information to say much for sure.
They never trigger the distribution clauses, and they own the copyrights of all the work being done. So if you NEVER distribute binaries outside your company's walls. The GPL is a giant nothing, for most practical cases.
That's why we're starting to see the AGPL more now. But even then, for INTERNAL applications. It's still a nothing.
The GPL doesn't cure people being greedy. It just changes how they are allowed to be greedy.
Some of it almost certainly would be useful upstream (eg. the clang warnings, and any unfixed security issues), and some might warrant being reimplemented in a different way (those Apple-specific ifdefs in the middle of platform-independent code blocks). But that's not ever going to happen, because of the way Apple jumbles it all together.
$ cd gnome-libxml2.git
$ git log --oneline --author=@apple.com | wc -l
43
A feature request is for something new. A bug report is reporting an error in the already released and distributed software. Here is why that is relevant.
> Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness".
When there is a bug in that released software the 'as is' is not the 'as is' that the developer intended. Probably 99% of free software developers would like to be informed about this, especially if it is software that they are continuing to develop and distribute.
> Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free
Huh? If I report a bug on a Saturday night (to a free software project or a proprietary project) I expect that someone will look at the report during the normal hours when they look at bug reports and if they decide it is something that needs fixing the work will be scheduled the same way they schedule work to fix bugs that their own testing reveals.