
Behind OS X’s modern face lies an aging collection of Unix tools - ingve
http://robservatory.com/behind-os-xs-modern-face-lies-an-aging-collection-of-unix-tools/
======
snorkel
I've worked at Microsoft and can attest that while it's OK to use open source
tools internally the IP lawyers don't want anyone touching GPL v3 tools to do
anything. If you suspect a project might have been even the slightest contact
with anything GPL 3 you must call for an immediate code scan and legal review.
You cant even use GPL 3 inside of an internal web tool. I imagine Apple and
other proprietary software publishers have the same mandate to their troops.

So yes, GPL 3 is hurting open source more than helping it.

Disclaimer: I don't speak for Microsoft. These are my personal observations.
And I no longer work there.

~~~
AnthonyMouse
> I've worked at Microsoft and can attest that while it's OK to use open
> source tools internally the IP lawyers don't want anyone touching GPL v3
> tools to do anything.

That's because they're _Microsoft_.

> I imagine Apple and other proprietary software publishers have the same
> mandate to their troops.

I have yet to hear any rational justification for this, yet people keep
repeating it.

~~~
lambda
While Apple has not publicly said anything about it, it's pretty clear from
their actions that they consider touching anything under the GPLv3 verboten.

Every single piece of software that has new releases under the GPLv3 they have
stopped updating. A few of the most important ones, like GCC, GDB, and Samba,
they've even gone as far as to pour substantial amounts of money and effort
into funding replacements (clang, lldb, Apple's smbd). Others that they don't
consider very important they've just let languish, like bash, make, and other
GNU utilities that they include on their systems.

~~~
AnthonyMouse
Yes, but why? Is there an _actual reason_ or is it just politics?

If "everybody is doing it" then either somebody knows why or it's a cargo
cult.

~~~
lambda
Sorry, are you asking why Apple and Microsoft do not allow distribution of
GPLv3 licensed packages?

Given that they haven't made any public statements about it, it's hard to say
with certainty; you can only speculate.

But the major things that the GPLv3 changed, which companies like Apple and
Microsoft are likely to object to, are the anti-Tivoization clauses, the
patent license clauses, and the "no effective DRM" clauses. If you check the
information about what changed in GPLv3 ([https://www.gnu.org/licenses/quick-
guide-gplv3.html](https://www.gnu.org/licenses/quick-guide-gplv3.html)), those
were pretty much the only extra restrictions added.

The anti-Tivoization clause says that if you distribute the software along
with hardware, you must also distribute (or provide users with a way to
change) any keys that are necessary for users to run their own modified
version of software on that hardware. Given that both Apple and Microsoft ship
locked down phones that don't allow users to modify their software, and are
increasingly moving towards locked-down App Store models even on desktop and
laptop computers, they may not want to risk every being obliged to follow that
requirement.

The patent grant clause is likely the one that worries them the most. That
says that if you distribute the software, and your distribution of the
software relies on patents that you either hold or license from someone else,
you must either pass along the rights in those licenses (if possible), or give
up the patent license (that is, if you have licensed a patent from someone but
don't have the ability to transfer that license to downstream recipients, than
you may only distribute the software if you give up that patent license,
putting you and your users on equal footing if the holder of the patent
decides to enforce it).

The DRM clause may also bother them, but I doubt that they would avoid using
software due to it, since it only applies to software which is itself used as
part of a DRM system, saying that it can't be considered an effective
technological measure (as the other freedoms provided by the GPL allow users
to replace it), and so none of the legally enforced restrictions on removing
DRM can apply. Since that only applies to code that is used as part of a DRM
system itself, I don't think that would cause them particular problems, as
long as they avoid linking any of their DRM systems to GPLed code, but there
may be cases in which it would come up.

Anyhow, I can't really say which of these is the reason that they don't allow
it, as they have never made any public statements about that. My guess would
be the patent clause, followed by the Tivoization clause, followed by the DRM
cluase, in order of importance.

~~~
AnthonyMouse
You're just describing the changes in the license, and none of those seem
particularly objectionable. You seem to agree that the DRM restriction is
quite harmless. The anti-tivoization clause might reasonably apply to iOS, but
I don't think iOS includes _any_ version of these utilities, and that still
wouldn't explain excluding them from OS X. It's not like they couldn't just
take them back out later on.

And the patent license seems least objectionable of all. The primary change
from GPLv2 seems to be having to include some language accounting for it in
the agreement for any patents they license, which they have every incentive to
do regardless in order to be covered in case an employee puts an Ubuntu ISO
somewhere public, and in the worst case they're still only in the same
situation they would be if the patent in question had been owned by some
patent troll.

Also, the post I responded to is talking about "Apple and other proprietary
software publishers." So Apple is more the exception than the rule in having
any trouble at all with the anti-tivoization clause since most software
vendors don't make their own hardware.

I still don't see anything that should make it so untouchable.

~~~
lambda
Have you watched Apple's patent war with Samsung? They rely heavily on patents
to attack competitors. If they distributed something under the GPLv3, then
there's the chance that Samsung could have looked at that, said "hey, that
GPLed package implements something that your patent license covered, that
means that we now have a license to that patent."

Or there's all of the patents that the license from other parties, like the
H.264 patent portfolio. Those patents they can't relicense; so if any of those
apply to any of the GPLv3 software they tried to distribute, they would be in
violation of one or both of the licenses.

    
    
      Also, the post I responded to is talking about "Apple and
      other proprietary software publishers."
    

Well, this thread is about Apple, and the one you were responding to was
comparing Apple with Microsoft. The part about "other proprietary software
vendors" was in there, but I'm not trying to back that up since that's too
broad a category to discuss as a whole. There are several different kind of
proprietary software vendors, that sell software in many different ways, and
so discussing them as a category is likely not to be useful.

For example, vendors who sell closed-source, proprietary applications could
never use any GPLed code, as linking to it would mean they were required to
release the code of the whole application under the GPL. So there there's
really no different between GPLv2 and v3.

Vendors who sell bundled software hardware combos could ship GPLed software,
and embedded Linux is common there. However, some of them like to lock down
their hardware, not allowing it to be upgraded or modified by end users. The
anti-Tivoization clause specifically forbids that, so they may avoid GPLv3
software in order to avoid the anti-Tivoization clause. One example here is
Android, where they even avoid GPLv2, for software that ships on phones,
almost everywhere except for the kernel.

There are also some proprietary software vendors who do ship GPLv3 software.
For example, Oracle, one of the biggest and most notorious proprietary
software vendors, actually does ship Oracle Linux, a distro which contains an
awful lot of GPLv3 software. So its clear that not every company has made the
same decision; some avoid it like the plague (Microsoft and Apple), some avoid
it in certain products but not others (Google avoids it Android, but ships
GPLv3 code in Chrome OS), and some are fine with shipping it. You can't really
make any blanket statements about all proprietary software companies.

But anyhow, as I said, for cases such as Apple, it's very obvious that they
are fine shipping GPLv2 software, but very clear from their actions that they
won't ship GPLv3. There are three major additional restrictions in the GPLv3,
and we can speculate which one was the tipping point for Apple. My money is on
patents, but I think that the anti-Tivoization may play a role too. However,
unless they publicly say something, or someone leaks some internal
communication about it, we will just be left speculating as to why.

~~~
AnthonyMouse
> If they distributed something under the GPLv3, then there's the chance that
> Samsung could have looked at that, said "hey, that GPLed package implements
> something that your patent license covered, that means that we now have a
> license to that patent."

The patent license only applies to derivative works so Samsung couldn't use it
for its non-GPLv3 products.

> Or there's all of the patents that the license from other parties, like the
> H.264 patent portfolio. Those patents they can't relicense; so if any of
> those apply to any of the GPLv3 software they tried to distribute, they
> would be in violation of one or both of the licenses.

They could just not distribute _that_ GPLv3 program.

Obviously this runs into the problem that you don't know which patents which
programs infringe, but that has nothing to do with the GPL. Some troll could
just as easily jump out from under the bridge and demand a hundred billion
dollars for a patent on Safari.

~~~
lambda

      Some troll could just as easily jump out from under the 
      bridge and demand a hundred billion dollars for a patent 
      on Safari.
    

Sure, and that kind of stuff does happen. And Apple likely makes decisions
based on limiting their liability to that kind of thing. They have publicly
stated that they objected to Ogg Theora because they had a patent license for
H.264, and didn't think it was worth the risk to ship something like Ogg
Theora, which may be covered by unknown patents.

Now, H.264 may be covered by unknown patents as well. But based on the
existence of the MPEG-LA and its patent pool, and the fact that they'd already
invested in and exposed to any potential H.264 risk, they felt like there
would be more risk to them to add Ogg Theora support than just sticking with
H.264. Were they right? Who knows. But that is the decision they made.

Now, we are just speculating about why they hate the GPLv3 so much. But they
obviously do, and they have both done a lot to use their own patents
offensively, as well as being cautious about infringing patents as a defensive
stance, so my best guess is that the patent clause is their concern.

But there's no way for me to be sure; there's not much point in continuing to
discuss it, because it's Apple that has made this decision, not me. I'm
perfectly happy shipping GPLv3 covered software; if you want to know why Apple
isn't, you could try asking them, though are unlikely to get an answer.

------
brymaster
Really not much to see here, as the author originally did not know Apple uses
stone age FOSS tools because of GPLv3.

Sources here: [http://opensource.apple.com](http://opensource.apple.com)

Apple doesn't seem timely in getting sources put up. Wayback Machine shows
that 10.9.5 was posted around October 7th even though that update was
distributed to users on September 17 (~20 day gap), so they're not exactly
adhering to the license as they should.

Also there is no sources for 10.10 and does iOS 7 and 8 really use no GPL'd or
other FOSS'd code?

~~~
sjwright
> they're not exactly adhering to the license as they should

Correct me if I'm wrong, but the licenses don't require Apple to proactively
publish sources, they just need to be able to supply them upon request.

~~~
danieldk
Indeed, that's what the GPL requires. There is absolutely no necessity to put
the sources online like they do.

 _Accompany it with a written offer, valid for at least three years, to give
any third party, for a charge no more than your cost of physically performing
source distribution, a complete machine-readable copy of the corresponding
source code, to be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange; or,_

Source:
[https://www.gnu.org/licenses/gpl-2.0.html](https://www.gnu.org/licenses/gpl-2.0.html)

~~~
brymaster
Actually, it's in Apple's best interests to simply post the sources online and
not play fast and loose with licensing as you're suggesting.

[http://www.gnu.org/licenses/old-
licenses/gpl-2.0-faq.html#Wh...](http://www.gnu.org/licenses/old-
licenses/gpl-2.0-faq.html#WhatDoesWrittenOfferValid)

Source is not distributed along with their binaries nor is a written offer to
receive source code that I've seen.
[http://support.apple.com/kb/DL1761](http://support.apple.com/kb/DL1761) &
[http://www.gnu.org/licenses/gpl-
violation.html](http://www.gnu.org/licenses/gpl-violation.html)

------
cal2
I find it very mildly ironic that the author is comparing these "ancient"
versions to MacPorts. Am I naïve, or do the overwhelming majority of OS X
developers use Homebrew nowadays? I've always thought Homebrew to be much more
robust than MacPorts. However, I've never actually _used_ MacPorts heavily
(and probably never will).

~~~
msluyter
There is a tool we use at work (rpmbuild, I believe) that's not available via
homebrew and only through macports. It's a nightmare, because if you install
macports, it interferes with brew (or at least, brew will complain a lot).
I've taken to running a VM in lieu of macports.

~~~
weaksauce
Why not just make your own formula?

The format is really simple and powerful.

[https://github.com/Homebrew/homebrew/blob/master/Library/For...](https://github.com/Homebrew/homebrew/blob/master/Library/Formula/avro-c.rb)

More complex example:

[https://github.com/Homebrew/homebrew/blob/6a72fa26aa49ee5c2b...](https://github.com/Homebrew/homebrew/blob/6a72fa26aa49ee5c2bd256daca21351510f33616/Library/Formula/rpm.rb)

Edit:

If that's the only reason you can't use homebrew just, you can just tap
another cask with it in there(or whatever they are calling that process).

[https://github.com/avalanche123/homebrew-
rpmbuild](https://github.com/avalanche123/homebrew-rpmbuild)

------
rst
Not mentioned and highly significant: Apple hasn't shipped anything which is
licensed under GPL v3. That cuts them off from a lot of upstream development,
including particularly upstream versions of bash.

I'm not sure they've ever published a reason for this, but outside speculation
centers around the v3 patent grant and anti-tivoization clauses.

~~~
AnthonyMouse
> I'm not sure they've ever published a reason for this, but outside
> speculation centers around the v3 patent grant and anti-tivoization clauses.

I've heard this more than once but it doesn't make any sense. GPL _v2_ says
this: "Each time you redistribute the Program ( _or any work based on the
Program_ ), the recipient automatically receives a license _from the original
licensor_ to copy, distribute or modify the Program subject to these terms and
conditions."

Ask your lawyer what happens if you license a piece of software to someone and
then try to sue them for patent infringement for using that software.

And OS X doesn't stop you from compiling your own bash (or whatever else) and
replacing the one Apple shipped, so I don't see how the anti-tivoization
clause would affect them either. It just doesn't make any sense.

I half suspect that there are a few IP lawyers (and/or Microsoft) who don't
like the GPL for ideological reasons and go around spreading FUD about it to
discourage people from using it.

------
davexunit
>Basically, the cause of the aging Unix tools in OS X is GPL v3.

That makes it sound like it's the GPL's fault that OS X users don't get up-to-
date utilities. Blame Apple's bad policy, not the GPL.

~~~
Sanddancer
It is the GPL's fault. There was enough change in the social implications of
v3 that Apple, and a lot of other stakeholders, don't want to mess with it
anymore. The FreeBSD team, for example, has very similar reasons for not
including GPL3-infected software, and are actively replacing all GPL software
with BSD-licensed software in the base install.

~~~
davexunit
>GPL3-infected software

I don't think we can have a rational discussion about this.

~~~
akerl_
The GPL is a viral license; it's an intentional choice on their part, and
"viral" and "infected" are pretty accurate ways to describe it. Whether you
believe that this nature is a good thing for development or a bad thing,
disagreeing about the fundamental nature of how the GPL works isn't
productive.

~~~
belorn
The language shows a lack of knowledge around what a copyright license is, and
how it works.

Copyright prevent every distribution of copies and derivative works. A license
is thus a permission, which permits distribution which otherwise is not
permitted.

Any license is viral in that you must follow the license in order to
distribute the copyrighted work. I can't just take a BSD licensed work,
replace it with my own license, and ignore the BSD requirements. The license
is _my_ permission to distribute the work and if I ignore it, I am liable
under copyright law.

Describing the permission as infective, restrictive, preventive and so on only
show how completely fundamentalist the person is. You are given permission to
use, copy and modify the program. If you feel infected by that choice, then I
call that ungrateful and childish behavior.

~~~
cls59
I can't take 100,000 lines of my own code, link it against 10 lines of GPLed
code, and re-distribute the result under a license of my choice. I have to use
a variant of the GPL.

This is the viral aspect that your argument does not address.

~~~
belorn
I can't take 100,000 lines of my own code, link it against 10 lines of BSDed
code, and re-distribute the result without respecting the BSD license.

This is the viral aspect that _your_ argument does not address.

~~~
akerl_
Yes, you can. You can release your code however you want. The BSD license
applies to the code provided by the project that chose to license their code
under it. You can choose to also license your code as BSD, but you are not
required to.

~~~
belorn
If I ignore or remove the BSD license from the 10 lines, I am removing the
permission I had to use them.

Its like if I buy a train ticket. If I throw away the ticket and write my own,
I no longer have permission to enter. The permission is in the ticket.

The 10 lines will must always be under the BSD, and every time I distribute I
must follow the conditions set down by the license. It infects the
distribution of the work, regardless of I license the other 100,000 lines.

------
tptacek
OS X wasn't vulnerable because it shipped an _old_ version of bash. It was
vulnerable because it relied on bash at all.

~~~
wyager
I was curious why OpenBSD didn't ship Bash by default. Perhaps they weren't
happy with the code quality.

~~~
imanaccount247
Not happy with the shell quality, code quality, or license. Bash is massive
compared to pdksh (what openbsd uses), has frightening code, and openbsd
rejects GPL code as much as possible (gcc/binutils is the only GPL software in
the tree, and no new GPL software is considered).

------
hotweels
The way the article is framed, you'd think that it's somehow the GPL's fault
that these applications aren't being updated. Seriously? Why doesnt Apple
write their own implementations of those applications? Why shift blame to the
license? What a crock of shit

~~~
serf
that's how Apple works. They don't make mistakes, they remedy mistakes that
others have caused--loudly--while hinting at someone else owning
responsibility for the issue.

Sort of like the 'You're holding it wrong" response to iPhone reception back a
few years ago.

[http://www.cnn.com/2010/TECH/mobile/06/25/iphone.problems.re...](http://www.cnn.com/2010/TECH/mobile/06/25/iphone.problems.response/)

------
X-Istence
I kind of want Apple to steal most of the userland tools from FreeBSD like
they have done in the past...

~~~
cpach
Seconded. If FreeBSD can replace GPL software, so can Apple.

------
dwpdwpdwpdwpdwp
As someone in the comments section of the original post put it, "newer doesn't
mean better". Obviously software with security, stability, or performance
issues should be re-written, but software doesn't "age" in the usual sense of
the word; the source code can be re-compiled for brand-new
machines/processors. A 2004 version of grep will always do everything I need
grep to do.

------
D4AHNGM
Am I misunderstanding what the author means by 'real release' in terms of
OpenSSL? OpenSSL themselves pushed 0.9.8za and Apple later adopted it after a
significant amount of nagging in the developer's forums on the issue.

------
cgrubb
also make, which is stuck at 3.81 (2006)

sort appears to be (2005), and doesn't have the -R flag for shuffling

also missing: head -n -NUM (all but last NUM lines) and tail -n +NUM (all but
the first NUM lines)

------
based2
[http://en.wikipedia.org/wiki/MkLinux](http://en.wikipedia.org/wiki/MkLinux)

------
kevinqualters
Is it a meta joke with the internal server error response?

~~~
runeks
No. Here's the cached page:
[https://webcache.googleusercontent.com/search?q=cache:gK9O2m...](https://webcache.googleusercontent.com/search?q=cache:gK9O2mS2Q30J:robservatory.com/behind-
os-xs-modern-face-lies-an-aging-collection-of-unix-
tools/+&cd=1&hl=da&ct=clnk&gl=dk)

------
Animats
It's amusing that Apple products ship with emacs inside.

~~~
jimmahoney
I don't think it's amusing - I think it's great. I use emacs every day, and
have for many decades.

