←back to thread

278 points jwilk | 4 comments | | HN request time: 1.046s | source
Show context
kibwen ◴[] No.44382195[source]
> Ariadne Conill, a long-time open-source contributor, observed that corporations using open source had responded with ""regulatory capture of the commons"" instead of contributing to the software they depend on.

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.

replies(4): >>44382211 #>>44383593 #>>44385565 #>>44385638 #
spott ◴[] No.44383593[source]
This makes an assumption that a bunch of companies are maintaining their own forks of MIT software with bug fixes and features and not giving it back.

I find that hard to believe.

replies(5): >>44383803 #>>44384019 #>>44385553 #>>44386007 #>>44386138 #
1. roryirvine ◴[] No.44385553[source]
One of the comments on the LWN article is an analysis of exactly that happening with this very library - https://lwn.net/Articles/1026956/

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.

replies(1): >>44388460 #
2. spott ◴[] No.44388460[source]
My reading of this wasn’t that Apple has a bunch of security bug fixes they aren’t upstreaming, it is that they are maintaining their own forks of an old version and back porting security bug fixes from upstream into their fork.

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.

replies(1): >>44388699 #
3. roryirvine ◴[] No.44388699[source]
Digging into it further, it looks like there's a mix - backported bugfixes, Apple-specific fixes, and security issues which may or may not have been fixed by upstream long ago.

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.

replies(1): >>44389315 #
4. om2 ◴[] No.44389315{3}[source]
We have contributed a number of upstream fixes

  $ 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.