Yes, the sources are open, but based on @nohillside's answer it seems that Apple has not published the sources for 10.14.6. I don't know why this is. I'd be surprised if there were any difference in the source for 10.14.5 and 10.14.6 because it seems Apple has not updated
ping.c since the version that shipped with 10.12 in June 2016. Apple does not publish a History as is done on GitHub, but you can run a
diff (or use BBEdit as I did) to compare the
ping.c sources from different releases.
Wrt your point that
man ping ends with
BSD March 29, 2013 BSD, two points:
The reference to BSD in
man ping is due to the fact that substantial portions of the MacOS code base were adopted from the BSD sources. Apparently
ping is one example of this, based on Apple's declarations and licensing language in the comments of
The date at the bottom of
man ping does not reflect the revision date of the manual, nor of the
ping utility itself. I'll show this below, but to see the source of the date stamp (
BSD March 29, 2013 BSD), refer to the source file
ping.8. Find the line beginning with
.Dd, and note the date matches. I suspect the
BSD references in the date stamp have to do with the
troff markup; i.e.
.Dd is a
troff macro for BSD man pages according to this source. I do not know why Apple doesn't use this macro to set the actual date the man page was last revised.
As further verification, you can download the ping.8 source file and read it as follows:
man ./ping.8 # in the directory where ping.8 is located
The source code for the manual (
ping.8) was revised sometime between the release of MacOS 10.12 and 10.14. This can be verified by doing a
diff on the man source files for those releases. Consequently, the revision occurred sometime after 10.12 was released in June 13, 2016, more than 3 years after the date stamp of
BSD March 29, 2013 BSD.
Your observation that "FreeBSD's version of ping is not the same as the one I use locally" is correct (assuming locally means on your Mac). You can verify that there are numerous
diffs between the FreeBSD's
ping.c on GitHub, and Apple's
ping.c in their source repository.
I think your question is interesting. Like you, I see references to BSD and old-ish dates in the manuals. And I've wondered why an organization with Apple's resources packages older software and manuals with MacOS. I asked a related question recently. The answer I accepted stated that the reason Apple has not updated the Unix tools in MacOS is "GPL licensing".
However, in attempting to answer your question, I now wonder if that answer was entirely correct. I'll try to be specific here as my original answer generated some controversy in the comments:
- According to
diffs in Apple's
ping.c source files, the
ping utility was last updated sometime prior to the release of 10.12. That's been over 3.5 years as of this writing.
ping was covered under the permissive BSD license when Apple adopted it. In fact, the BSD license was so permissive that it allowed Apple to make modifications, and change the terms of the license for the modified software! All of that means only that there are no licensing issues that would discourage Apple from keeping
ping is not cutting edge software, and for that reason I wouldn't expect it would require frequent revisions. However, the History tab on FreeBSD's
ping.c source shows that there were 28 commits between Jan 2017 and Nov 2019. I won't try to analyze them, but something is motivating FreeBSD to expend resources to make frequent updates to this utility that's been around since 1983.
- Based on the above, I believe the situation is this: while "GPL Licensing" may deter Apple from maintaining some of the Unix tools included in MacOS, "BSD licensing" doesn't mean that the code will be updated frequently. That said, I won't argue that the "BSD licensed" utilities aren't generally more current than the "GPL licensed" utilities. It's a matter of "degree", not "absolutes". Also, as of this writing,
ping is the only BSD-licensed Unix utility in MacOS I've tried to analyze.
I feel I should make one other clarification in an effort to quell the controversy my original answer generated. I have not made any judgments on the quality of Apple's software, their processes for maintaining it or their licensing practices. Like most participants here, I've made an investment of time and money because I favor some of Apple's products. But I'm not sycophantic about Apple, and I feel that it's only rational to question practices that raise concern: caveat emptor