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'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.
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.
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.
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
The main reason we have a fork at all is that upstream libxml2 has broken source and binary compatibility in various ways, and we can't take those changes because libxml2 is public API on our platforms. We do make an effort to upstream all security fixes, though we sometimes get to it only after we ship.