macOS SDK and XCode Software License Agreement for cross-compile on Linux

Developer Tools & Services Xcode
K. High OP
Created
Replies 5
Boosts 0
Views 3.7k
Participants 3

I am doing some research and testing for the GNU LilyPond project. (http://lilypond.org, sheet music engraving software) This is part of an effort to produce a 64-bit macOS version of the software as required by the next macOS version; currently only 32-bit is offered. The installer packages for LilyPond are built using not XCode, but a cross-compiler on Linux (http://lilypond.org/gub/) which produces installers for Linux, macOS, Windows, and FreeBSD. It looks like that build system would need a newer version of the macOS SDK from XCode to produce a 64-bit macOS installer; currently it appears to use Mac OS X SDK 10.4u. And a quick reading of the current XCode Software Licence Agreement finds that Section 2.5 "Copies" does not allow for using any part of XCode on anything but Apple-branded hardware. I am unsure which Apple forum is best for further discussion on that. If this one is suitable, I'll continue here. Otherwise, which one should I use?

Answered by john daniel in 352041022

A requirement to restrict the use of Xcode files to Apple-branded hardware is not a new development. You can check the Wayback Machine for Xcode licenses back to 2011, which have the same wording. You can also download old copies of Xcode and check their licenses. Out of curiosity, I did just that. Unfortunately, the first version of Xcode (2.4) that supports 64-bit code also has the Apple-branded restriction. I also checked Xcode versions 2.2.1 and 2.3 that include the 10.4 SDK. These also have the Apple-branded restriction. There is a stand-alone 10.4 SDK installer available for download that does not have this restriction. Hopefully that is the SDK that you've been using this whole time.


Going forward, I suggest that your project acquire a Mac or someone with a Mac to do builds and testing. A Mac can also do Linux and Windows builds.

Replies  5
Boosts 0
Views  3.7k
Participants  3
john daniel OP

This is a suitable forum. But what is there to discuss? You will have to build on a Mac.

Ken Thomases OP

This is a legal matter and nobody on theses forums is going to be able to give you advice or authoritatively tell you what the license means. Certainly not anybody outside of Apple and, I'd wager, none of the Apple employees that frequent these forums. (Even if they were in a position to speak to the legalities, I'd doubt they'd do so on the forums.)


You're going to have to consult a lawyer and/or open communications with Apple's lawyers to determine if the license indeed prohibits what you want to do (as it seems to to layman's eyes) and if an exception can be negotiated. There are contact links on this page: https://www.apple.com/legal/contact/
K. High OP

Thanks for the reference to Apple's legal team. That might be my best resource to pursue. My main question is regarding the XCode Software License Agreement, and if older versions of XCode have different terms than the current one.


If the LilyPond project's developers had their way, they would like to find a newer version of the macOS SDK and have it publicly available in some form where the project's build system can download it just like it does for any other dependencies. That build system could then be configured to produce the 64-bit macOS installer at the same time it makes all the others. This would be a continuation of LilyPond's current arrangement, which seems to use a tarball extracted from a Mac OS X SDK 10.4u package.


Now, it's plain that the current XCode Software License Agreement will not allow doing that.


But how about older versions? The macOS version of LilyPond is mostly just a command line interface program and a very simple text editor provided for convenience. It's not expected that many (or even any) of the features added to newer SDK versions would be used. All that's needed is an SDK new enough to produce command-line and text editor executables that run on current macOS versions. In research so far, there were indications that maybe just one version newer might be sufficient - SDK 10.5.


If the current build system can't continue being used for macOS, the alternatives considered so far would have a separate build process. This would likely result in a macOS installer being produced less frequently than for other systems. Perhaps it would get dropped entirely and software availability left to MacPorts. It's not a result anyone wants, but neither is a Software License Agreement violation, and it's not certain the project's volunteer build system operators will have the capacity for making special efforts to avoid both of those things.


In conclusion, here's the question I have now: what Software License Agreement would have covered the Mac OS X SDK 10.5 found in (maybe) XCode 3.1? If it's more permissive than the current version, that may be all LilyPond needs.
john daniel OP
Accepted Answer

A requirement to restrict the use of Xcode files to Apple-branded hardware is not a new development. You can check the Wayback Machine for Xcode licenses back to 2011, which have the same wording. You can also download old copies of Xcode and check their licenses. Out of curiosity, I did just that. Unfortunately, the first version of Xcode (2.4) that supports 64-bit code also has the Apple-branded restriction. I also checked Xcode versions 2.2.1 and 2.3 that include the 10.4 SDK. These also have the Apple-branded restriction. There is a stand-alone 10.4 SDK installer available for download that does not have this restriction. Hopefully that is the SDK that you've been using this whole time.


Going forward, I suggest that your project acquire a Mac or someone with a Mac to do builds and testing. A Mac can also do Linux and Windows builds.

K. High OP

Thank you very much! That is EXACTLY the sort of answer I wanted. If there are further questions on this from the LilyPond project, I will post them here.