13 ms·

I don't follow Apple open source, so I have a lot of questions: What parts of MacOS are open source, and which are not? How is it licensed? Why is this on their

I don't follow Apple open source, so I have a lot of questions: What parts of MacOS are open source, and which are not? How is it licensed? Why is this on their website rather than GitHub?

IMcD23 9y ago
Much of the kernel (XNU), forks of BSD utilities, WebKit, LLVM/Clang, and various other projects are hosted there. This site predates GitHub, but folks have mirrors hosted there of most projects. Apple’s newer open source projects (Swift, ResearchKit, etc) are on GitHub.
- objclxt 9y ago
  The WebKit source here is just a snapshot of what when into that version of the OS, the main WebKit repo is hosted separately in WebKit's SVN: https://webkit.org/getting-the-code/ https://webkit.org/getting-the-code/ The same is true for LLVM / Clang: http://llvm.org/docs/GettingStarted.html#checkout http://llvm.org/docs/GettingStarted.html#checkout
sigjuice 9y ago
Any particular reason why it needs to be on GitHub?
- jsjohnst 9y ago
  Having it hosted on some kind of revision control system would be very useful and GitHub is the most prominent public place to do that, but otherwise no real reason.
  - feld 9y ago
    I don't think they've ever released code with version history, so it would provide little benefit other than a famliar UX.
    - jsjohnst 9y ago
      To my knowledge, they haven't either (outside what is on Github already). The point being it would be great if they did.
    - turdnagel 9y ago
      Apple's Swift programming language is on GitHub -- the full history AFAIK. https://github.com/apple/swift https://github.com/apple/swift
    - epipping 9y ago
      That depends. You don’t have any helpful commit logs or even changelogs. But if you arrange e.g. the XNU releases in the form of a reasonable graph and import them into git that way, you can get some telling diffs, on the command line at least. GitHub is not being very helpful here because it does not allow you to diff arbitrary tags and revisions from a repository. But GitHub is still a place where people find and look for code. Those thoughts prompted me to create https://github.com/epipping/xnu-kernel-sources-x86 https://github.com/epipping/xnu-kernel-sources-x86 (and its cousin https://github.com/epipping/xnu-kernel-sources-ppc https://github.com/epipping/xnu-kernel-sources-ppc). Maybe you find it help (please take a look at the wiki)
  - dfox 9y ago
    Over last 10 or so years there were various conflicts between open source projects and Apple that were caused by absence of publicly accessible version history for open source code shipped by Apple as part of OS X. Probably most significant such conflict was around KHTML/WebKit (and I somewhat believe that Chrome was at least partially Google's reaction to that)
    - michel-slm 9y ago
      Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.
      - kitsunesoba 9y ago
        As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium. Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.
        rlanday 9y ago
        A couple clarifications: - My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork. - WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
  - astrodust 9y ago
    Apple is a big fan of GitHub, you can see evidence of that with the Swift project (https://github.com/apple/swift https://github.com/apple/swift), but not everything is suitable for that sort of treatment. It could be workflow related. The OS team has been around for decades and pivoting to a new RCS for a whole OS is not easy.
jsjohnst 9y ago
Some of their stuff is on Github, but must of their stuff is on the linked website. The stuff that is open sourced here is mainly stuff like the Mach kernel, the BSD base system utilities, etc. For the most part, I didn't find the stuff here very useful, with the exception of an issue with 802.11x back in OS X 10.5 days. Was nice being able to reference the exact line in the code in the Radar I filed that was causing the issue.
deleted 9y ago
[deleted]
stuaxo 9y ago
Pretty sure none of the GUI parts are open sourced.
- madeofpalk 9y ago
  Chess.app is open source! https://opensource.apple.com/source/Chess/Chess-318/ https://opensource.apple.com/source/Chess/Chess-318/
  - tbodt 9y ago
    TextEdit, too! You can find it as sample code in the developer documentation.
    - S_A_P 9y ago
      And text edit is the only app I had that would open a 6gb csv file I had. I don't have sublime text but I wonder if it would do it.
      - abritinthebay 9y ago
        Based on my experience with large JS files.... I doubt it
        DonaldPShimoda 9y ago
        ? I've used Sublime to open ~10GB files. It's often the only thing that'll open them. They pride themselves on that ability (among others).
        jeffhuys 9y ago
        Yeah, sublime is astonishingly fast. Obviously much better than electron-based editors.
        abritinthebay 9y ago
0x4a42 9y ago
As long as my memory is still working, the closed parts were mostly the GUI (Aqua), the network stack, and (of course) all the utilities like mail client, iTunes, etc.
- umanwizard 9y ago
  Drivers and many KEXTs (equivalent of linux kernel modules) are closed-source.
raimue 9y ago
As Apple is not developing this software in the public, it would not make sense to put it on GitHub or any other code hosting site. The usual approach is that Apple throws bits over the wall where you can pick them up months after the end-user release. And even these code drops will be thoroughly cleaned before, so that for example kernel sources do not contain any trace of support for ARM or anything else related to the iPhone – all of that is strictly closed source. Software they take in from BSD, other open source projects, or some common Linux tools might also get patched. However, such patches are never actively submitted back to the projects, but only published on this website. The sources published for macOS on this website are mostly licensed any variant of the BSD/MIT licenses, or the Apple Public Source License, or the GPLv2. Apple avoids the GPLv3 for legal reasons due to its patent clause. That is why they often ship only the most recent GPLv2 release and ignore all later updates, for example GNU make 3.81 or bash 3.2. There might also be some other licenses in the mix, such as the Artistic License for Perl and related software.
- eridius 9y ago
  > Apple avoids the GPLv3 for legal reasons due to its patent clause. The patent clause is bad, but the anti-TiVoization clause is actually worse. According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
  - phh 9y ago
    Nope, GPLv3 doesn't break any security model other than security by obscurity. Android could very well use GPLv3 and have no consequence on its security model. As long as the bootloader is open-able, the Tivo-ization rule of GPLv3 is respected. If Apple uses GPLv3, it will piss them off quite a lot, but it won't impact their security at all.
    - eridius 9y ago
      Of course it will. The iOS security model fundamentally depends on everything from the bootloader up being codesigned. Releasing the root signing keys completely destroys this. Nothing on the system can be trusted anymore if that happens. Edit: Well, I guess the secure enclave can be trusted. But nothing else can be.
Osmium 9y ago
> rather than GitHub? Just to note that Swift is on GitHub[0] and has a very inclusive community. The impression I get is that Apple isn't really interested in soliciting outside contributions for their OS/kernel code, which is why they're just code dumps. [0] https://github.com/apple/swift https://github.com/apple/swift
barkingcat 9y ago
You had many questions, but source code doesn't need to be on Github to be open source, especially when it's being maintained and developed purely by people hired on the core os team inside apple. You could ask why it's not on a private github repo, and the answer is that Apple's code predates Github by probably up to a decade, and depending on workflow and privacy reasons being on github is probably useless and/or veto'ed by their legal department. There are so many ways to work on open source. Github is just one tool.
- saagarjha 9y ago
  Only somewhat related, but it appears that Apple has begun to use GitLab internally: https://twitter.com/_inside/status/907299327340675072 https://twitter.com/_inside/status/907299327340675072
koko775 9y ago
launchd, which used to be open-source, is no longer open-source, because it was subsumed into XPC, which has never been open-source.

I don't follow Apple open source, so I have a lot of questions: What parts of MacOS are open source, and which are not? How is it licensed? Why is this on their website rather than GitHub?

IMcD23 9y ago

Much of the kernel (XNU), forks of BSD utilities, WebKit, LLVM/Clang, and various other projects are hosted there. This site predates GitHub, but folks have mirrors hosted there of most projects. Apple’s newer open source projects (Swift, ResearchKit, etc) are on GitHub.

objclxt 9y ago
The WebKit source here is just a snapshot of what when into that version of the OS, the main WebKit repo is hosted separately in WebKit's SVN: https://webkit.org/getting-the-code/ https://webkit.org/getting-the-code/ The same is true for LLVM / Clang: http://llvm.org/docs/GettingStarted.html#checkout http://llvm.org/docs/GettingStarted.html#checkout

sigjuice 9y ago

Any particular reason why it needs to be on GitHub?

jsjohnst 9y ago
Having it hosted on some kind of revision control system would be very useful and GitHub is the most prominent public place to do that, but otherwise no real reason.
- feld 9y ago
  I don't think they've ever released code with version history, so it would provide little benefit other than a famliar UX.
  - jsjohnst 9y ago
    To my knowledge, they haven't either (outside what is on Github already). The point being it would be great if they did.
  - turdnagel 9y ago
    Apple's Swift programming language is on GitHub -- the full history AFAIK. https://github.com/apple/swift https://github.com/apple/swift
  - epipping 9y ago
    That depends. You don’t have any helpful commit logs or even changelogs. But if you arrange e.g. the XNU releases in the form of a reasonable graph and import them into git that way, you can get some telling diffs, on the command line at least. GitHub is not being very helpful here because it does not allow you to diff arbitrary tags and revisions from a repository. But GitHub is still a place where people find and look for code. Those thoughts prompted me to create https://github.com/epipping/xnu-kernel-sources-x86 https://github.com/epipping/xnu-kernel-sources-x86 (and its cousin https://github.com/epipping/xnu-kernel-sources-ppc https://github.com/epipping/xnu-kernel-sources-ppc). Maybe you find it help (please take a look at the wiki)
- dfox 9y ago
  Over last 10 or so years there were various conflicts between open source projects and Apple that were caused by absence of publicly accessible version history for open source code shipped by Apple as part of OS X. Probably most significant such conflict was around KHTML/WebKit (and I somewhat believe that Chrome was at least partially Google's reaction to that)
  - michel-slm 9y ago
    Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.
    - kitsunesoba 9y ago
      As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium. Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.
      - rlanday 9y ago
        A couple clarifications: - My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork. - WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
- astrodust 9y ago
  Apple is a big fan of GitHub, you can see evidence of that with the Swift project (https://github.com/apple/swift https://github.com/apple/swift), but not everything is suitable for that sort of treatment. It could be workflow related. The OS team has been around for decades and pivoting to a new RCS for a whole OS is not easy.

jsjohnst 9y ago

Some of their stuff is on Github, but must of their stuff is on the linked website. The stuff that is open sourced here is mainly stuff like the Mach kernel, the BSD base system utilities, etc. For the most part, I didn't find the stuff here very useful, with the exception of an issue with 802.11x back in OS X 10.5 days. Was nice being able to reference the exact line in the code in the Radar I filed that was causing the issue.

deleted 9y ago

[deleted]

stuaxo 9y ago

Pretty sure none of the GUI parts are open sourced.

madeofpalk 9y ago
Chess.app is open source! https://opensource.apple.com/source/Chess/Chess-318/ https://opensource.apple.com/source/Chess/Chess-318/
- tbodt 9y ago
  TextEdit, too! You can find it as sample code in the developer documentation.
  - S_A_P 9y ago
    And text edit is the only app I had that would open a 6gb csv file I had. I don't have sublime text but I wonder if it would do it.
    - abritinthebay 9y ago
      Based on my experience with large JS files.... I doubt it
      - DonaldPShimoda 9y ago
        ? I've used Sublime to open ~10GB files. It's often the only thing that'll open them. They pride themselves on that ability (among others).
        jeffhuys 9y ago
        Yeah, sublime is astonishingly fast. Obviously much better than electron-based editors.
        abritinthebay 9y ago

0x4a42 9y ago

As long as my memory is still working, the closed parts were mostly the GUI (Aqua), the network stack, and (of course) all the utilities like mail client, iTunes, etc.

umanwizard 9y ago
Drivers and many KEXTs (equivalent of linux kernel modules) are closed-source.

raimue 9y ago

As Apple is not developing this software in the public, it would not make sense to put it on GitHub or any other code hosting site. The usual approach is that Apple throws bits over the wall where you can pick them up months after the end-user release. And even these code drops will be thoroughly cleaned before, so that for example kernel sources do not contain any trace of support for ARM or anything else related to the iPhone – all of that is strictly closed source. Software they take in from BSD, other open source projects, or some common Linux tools might also get patched. However, such patches are never actively submitted back to the projects, but only published on this website. The sources published for macOS on this website are mostly licensed any variant of the BSD/MIT licenses, or the Apple Public Source License, or the GPLv2. Apple avoids the GPLv3 for legal reasons due to its patent clause. That is why they often ship only the most recent GPLv2 release and ignore all later updates, for example GNU make 3.81 or bash 3.2. There might also be some other licenses in the mix, such as the Artistic License for Perl and related software.

eridius 9y ago
> Apple avoids the GPLv3 for legal reasons due to its patent clause. The patent clause is bad, but the anti-TiVoization clause is actually worse. According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
- phh 9y ago
  Nope, GPLv3 doesn't break any security model other than security by obscurity. Android could very well use GPLv3 and have no consequence on its security model. As long as the bootloader is open-able, the Tivo-ization rule of GPLv3 is respected. If Apple uses GPLv3, it will piss them off quite a lot, but it won't impact their security at all.
  - eridius 9y ago
    Of course it will. The iOS security model fundamentally depends on everything from the bootloader up being codesigned. Releasing the root signing keys completely destroys this. Nothing on the system can be trusted anymore if that happens. Edit: Well, I guess the secure enclave can be trusted. But nothing else can be.

Osmium 9y ago

> rather than GitHub? Just to note that Swift is on GitHub[0] and has a very inclusive community. The impression I get is that Apple isn't really interested in soliciting outside contributions for their OS/kernel code, which is why they're just code dumps. [0] https://github.com/apple/swift https://github.com/apple/swift

barkingcat 9y ago

You had many questions, but source code doesn't need to be on Github to be open source, especially when it's being maintained and developed purely by people hired on the core os team inside apple. You could ask why it's not on a private github repo, and the answer is that Apple's code predates Github by probably up to a decade, and depending on workflow and privacy reasons being on github is probably useless and/or veto'ed by their legal department. There are so many ways to work on open source. Github is just one tool.

saagarjha 9y ago
Only somewhat related, but it appears that Apple has begun to use GitLab internally: https://twitter.com/_inside/status/907299327340675072 https://twitter.com/_inside/status/907299327340675072

koko775 9y ago

launchd, which used to be open-source, is no longer open-source, because it was subsumed into XPC, which has never been open-source.