Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version.
/bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.
macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Like IE for downloading Chrome.
It's just GPLv3 software though. In contract, SSH is currently reporting OpenSSH_7.9p1, and that is fairly up to date.
I do think that if Apple can't ship a current version (for whatever reason), they probably shouldn't have it pre-installed at all, much like the BSD's don't come with bash by default either. Maybe they could ship with ksh/pdksh/mksh or something instead.
The problem is that GPL3 has more restrictions than just "publish the code". That's why projects such as FreeBSD, OpenBSD, etc. also won't include GPL3 code, as including GPL3 code would restrict what you can and can't do with the entire system.
Can you name them? It's not exactly snark. My experience is that almost everyone with strong GPLv3 opinions turns out not to actually object to the terms themselves when discussed in isolation.
To head off: it's not the patent grant. Apache 2 has a very similar patent grant and everyone is fine with it.
Apple doesn’t support it because GPLv3 requires that you are actually able to run the modified source code (not just see, change and distribute). While they probably could do that on macOS, macos and iOS share the same kernel and many common source trees. So by providing macOS software with GPLv3 code, some of that code could potentially be shipped with iOS which would land them in hot water because you are not able to just execute code on iOS. Even with a developer license, you couldn’t just recompile the kernel (or even Library) and replace it with the default one.
Edit:
Here is more information about that:
> Protecting Your Right to Tinker
> Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.
Sure. But iOS doesn't have Bash (I don't think, even if it does: Then just ship GPLv2 Bash on iOS, and modern Bash on macOS where users might actually care). The GPLv3 of Bash doesn't infect the shared kernel or libraries between iOS and macOS, it's just the `/bin/sh` program. It's easy enough to check if it's being included in iOS.
"The reason we can't ship modern Bash on macOS is that we're concerned we might accidentally include Bash on iOS."?
(and /bin/sh on macOS is already sufficiently user-modifiable to satisfy GPLv3)
Apple is pretty firm on no GPLv3 because accidentally shipping it on iOS can be pretty dangerous for them. Whether you agree with the decision to just not ship GPLv3 software (I don’t), I can understand apples concerns regarding GPLv3.
Furthermore, it wouldn’t surprise me if iOS had bash support even for just debug builds and Apple either had to worry about testing, building and maintaining two version of bash and still risk getting them mixed up and accidentally shipping some parts of the bash source code. This much easier to just never use GPLV3
Accidental shipping of IP which a company do not own is a constant risk. Companies sometimes accidental ship proprietary software, copyrighted images, copyrighted text, patented techniques, trademarked names, trademarked images, and more.
A Swedish copyright lobby organization committed copyright infringement on their own website. Bethesda game company had a trademark dispute with the developers of Minecraft. Apple and Samsung are constantly in patent war with each other. There is an almost unlimited number of cases where one company sue an other for contract and license disputes.
Shipping software is pretty dangerous, and there is no data to show that shipping GPLv3 licensed software is more likely to cause accidental infringement of someones IP than other licensed software.
> accidentally shipping it on iOS can be pretty dangerous
I read the same argument about GPLv2 in like 1994. To date, there remains no case law I'm aware of where a copyright holder "lost" anything by "accidentally" shipping GPL software. How many decades does it take for us to put this myth to rest?
A lot, because it's hard to derive meaningful conclusions from something that's used so relatively little precisely because of licensing concerns.
Anyway, with v2, the concerns were more vague - you'd have to accidentally link something GPLv2. With v3, even just shipping the binary signed with a private key on a platform that requires said key to load it, is enough to potentially force disclosure of that key (and that is by design of GPLv3 - it wants to kill the TiVo model).
The outcome of violating the GPL is license termination: you cannot distribute it any more. I don't think there has ever been a case of enforced further distribution or disclosure.
My main point was that to my knowledge there has never been a case of forced further distribution.
About termination, what you mention is kind of stopping further violation of the terms and maybe compensation for the past violations. What I wanted to mention (but wasn't at all clear about) is that after termination, you cannot even distribute if you intend to abide by the terms unless you are forgiven by the copyright holder. (In the case of the GPL version 3 there is some grace period during which for the first violation, if you abide within that period, you are explicitly permitted to resume distribution under the license terms.)
Right, so the risk can't be quantified and the whole thing is just isomorphic "because I don't like it". Which was as true then as it is now. It's not about license terms, it's about what amounts to politics.
Experimenting is not the only way to quantify risk. You can also e.g. have several highly paid lawyers look over the text of the license, and see what each of them had to say.
The big players in the industry did just that, and there appears to be a remarkable consensus on it.
The GPLv3 was intentionally designed to create the risk that Apple and others are trying to avoid. IBM doesn't have that risk because they don't sell hardware or software packages, they sell expensive service contracts.
Red Hat, a division of IBM, literally does almost $3B of revenue selling a Linux distribution that includes almost the entirety of the GNU corpus, all GPLv3. IBM bought them because they already resell packages and contracts based on the same stuff and wanted the vertical integration. So yeah, you buy an expensive service contract from IBM and it comes with (gasp) a giant license for GPLv3 stuff in RHEL.
That point is silly. If what you say were true, then the purchase would have been poison. It's not true. It's FUD. And it's hilariously the same FUD that people were flinging around in years before most of the existing FUD-flingers were even born.
> Apache 2 has a very similar patent grant and everyone is fine with it.
OpenBSD apparently isn't fine with it, fwiw.
> The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD.
Eh, is it 2007 again? Hasn't this been discussed to death already? I have little interest to repeat it again; this discussion has been on-going for ten years already (longer if we count GPL vs. BSD discussions, which are roughly similar). Everyone should be familiar with the arguments by now; I trust you're already familiar with mine.
I understand that you're well-intentioned, but I find the suggestion that I'm somehow not informed to be rather patronizing to be honest.
On FreeBSD, as I recall, they don't want any GPL'd code in the base system, simply because the ideological goal is to have everything under BSDL. It's not that it affects other bits of the system though.
Yeh, GPL2 is also considered less than ideal, and replacing GPl2 code has been a low-key long-term goal. GPL2 is still considered acceptable though, whereas GPL3 is outright barred.
I think gcc is still in base, right? They just added clang and set that as the default, AFAIK. I haven't kept up with FreeBSD much in the last few years, so not sure what the plans are to remove gcc.
So yeah, looks like there's still plenty of GPL code in FreeBSD that's not trivially replaceable. The same applies to OpenBSD, although in general the OpenBSD people tend to be a bit more proactive in replacing GPL code.
How's that? The quality and amount of GUI tools are far more complete in macOS than Linux desktop and you can just run a Linux VM to mimic the deployment server.
I don't care about the GUI tools, I just need an editor, a terminal and a web browser. And maybe Sequel Pro once in a blue moon. The MacOS GUI is quite annoying when you want to do stuff fast like for instance move windows between virtual desktops or switch the desktop with the mouse wheel.
The tooling is just not there (old Python, old Perl, old Ruby and of course different versions from your deployment environment), you have to resort to third party tools such as homebrew or macports, you have to install Xcode to get gcc, you need an Apple ID to do that, the system level API is incompatibile with Linux, the filesystem is or at least was case insensitive. New MacOS versions after El Capitan are also getting worse at compatiiblity with other Unix-like platfroms. It's a pain to set up a development environment really, especially if you use any dynlibs. Instead of a VM we have a staging server where we deploy and there are almost always surprises.
In Linux the tooling is just there, a few seconds and one package manager command away. If your package is not there then there are PPAs or OBS repos. You can reproduce the platform you're deploying as closely as possible and there are less surprises.
WireGuard doesn't require bash. The main configuration utility, wg(8), is written in vanilla C. However, the tools ship with a little convenience script, called wg-quick(8), which is indeed written in bash. It started out as the thing I was using to configure my laptop on the go, but then others found it helpful. It's by no means essential or central to WireGuard, and lots of people use different things to wrap wg(8) and the various networking tools.
Based on your documents[1] of Mac OS, it looks very like wireguard requires bash version 4 or newer because wireguard-tools will install bash as dependency. Maybe you should edit the docs or shouldn't deliver wireguard-tools?
Sorry if I didn't make it clear before: wg-quick(8) is part of wireguard-tools, because people find it useful sometimes. But it's in no way essential and WireGuard functions entirely without it. That's what I mean when I say WireGuard doesn't require bash. That little helper script is just a small convenience thing some people like.
Totally aside: is there a tool that can parse a programs code, then consume a folder of (headers for?) versions of a dependency and say the versions that are [a priori] compatible?
I assume you can install newer versions of Bash on macOS though?
(But it certainly suggests to me that macOS isn't actually the easiest out-of-the-box solution if your workflow includes anything more than web browsing.)
On macOS almost everyone uses the homebrew package manager https://brew.sh. Installing bash is harder because you have to add the filepath of the new bash binary to /etc/shells and then set that filepath as your default shell, but
brew install bash
echo /usr/local/bin/bash | sudo tee -a /etc/shells
chsh -s /usr/local/bin/bash
and if you're on macOS and still haven't heard of homebrew, you first need to install it with
That command makes my eyes twitch. This sort of "download random stuff from internet, then pipe them to ruby/perl/python" madness should end, like right now. I'm assuming you're a reasonable person who knows what that commands does. Can you really not see how people can misuse commands like this to execute arbitrary code on people's computers, even experienced engineers if they carelessly copy-paste code like this. As a rule of thumb, to whoever reading this, please don't trust random strangers online and run their code. You never know. Always download code from trusted sources and check sha hashes. Piping anything else to ruby/perl/python is playing with fire.
That command curls a ruby file from the Homebrew repository on Github. If that Github repo (or Github) is compromised, then no matter how you installed homebrew, you are going to get hacked the next time you run `brew update`, which by default is run on every `brew install`.
For me, the odds of that repo being compromised for long enough are outweighed by the convenience. This has been brought up on HN before and I'm not convinced.
You probably don't need to update /etc/shells unless you really want to. chsh just won't let you switch to a shell that's not listed there without using sudo, which isn't a problem for most (generally single-user) Mac systems. You can also change your shell from the Users & Groups system preferences (in the advanced settings).
