lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LilyPond 64-bit version for a Mac


From: Carl Sorensen
Subject: Re: LilyPond 64-bit version for a Mac
Date: Tue, 5 Mar 2019 16:28:24 +0000
User-agent: Microsoft-MacOutlook/10.10.7.190210

On 3/4/19, 10:20 PM, "Mason Hock" <address@hidden> wrote:

    On 03/02, Carl Sorensen wrote:
    > We cannot use our regular build system to create LilyPond binaries due to 
Apple’s restrictive licensing on the OSX SDK.
    
    Could you explain briefly or link to why this is? I understand that the
    App Store's restrictions would violate the GPL, and that Apple avoids
    distributing anything under GPLv3, presumably to avoid the tivoization
    clause, but I was not aware of any restrictions on what developers could
    independently build for macOS and distribute.

We build LilyPond on a Linux system, where all binaries are created by a 
cross-compiler as part of GUB.  The system that hosts the build is not an Apple 
system, and in fact, with our current hosting system, we don't even know what 
kind of hardware is in use at any given moment.

The Apple Xcode license is available at 
https://www.apple.com/legal/sla/docs/xcode.pdf.

Paragraph 2.2.A gives the right to

"A. Install a reasonable number of copies of the Apple Software on 
Apple-branded computers that
are owned or controlled by You to be used internally by You or Your Authorized 
Developers only as
follows:
(i) You may use the Xcode Developer Tools to test and develop application and 
other software;
(ii) You may use the macOS SDKs to test and develop application and other 
software;"

Paragraph 2.2.B. gives the right to 

"B. Use Provisioning Profiles to install Your Applications onto a reasonable, 
limited number of
Authorized Test Units solely for use by You and/or Your Authorized Developers 
and only for internal
testing and development of Your Applications, or for Your own personal, 
non-commercial use."

Paragraph 2.7 limits the use.

"2.7 Restrictions; No Other Permitted Uses
The grants set forth in this Agreement do not permit You to, and You agree not 
to, install, use or run the
Apple Software or Apple Services on any non-Apple-branded computer or device, 
or to enable others to
do so. This Agreement does not allow the Apple Software or Services to be made 
available over a
network where they could be run or used by multiple computers at the same time, 
unless otherwise
expressly permitted in writing by Apple. Further, unless otherwise expressly 
permitted by Apple in
writing, You agree not to rent, lease, lend, upload to or host on any website 
or server, sell, redistribute, or
sublicense the Apple Software and Apple Services, in whole or in part, or to 
enable others to do so."

Our current build system doesn't use the Apple SDK; instead it uses a Darwin 
SDK which was created for use with open-source software.  Darwin is not 
currently under development; the replacement for Darwin does not yet have an 
SDK (and may not be able to get one, because of Apple's prohibition on 
reverse-engineering the SDK.

I don't know if anybody has tried building 64-bit executables in GUB using the 
current Darwin SDK.  If that works, we'd have a regular build.  But I don't 
think that's a feasible path forward long-term.

The Homebrew/MacPorts build instructions have the user download Xcode, thereby 
providing a copy of the SDK to the user that wants to build a copy of lilypond. 
 This is consistent with the Apple license.

It seems we have four choices for providing Mac OSX executables going forward, 
if the current SDK won't build 64-bit binaries:

1) Provide users the ability to build their own executable.
2) Have somebody who owns a Mac build the lilypond executable and upload it to 
the website.
3) Develop GUB to run on OSX and have someone who owns a Mac take 
responsibility for running the GUB builds on OSX
4) Develop GUB to run in a VM on OSX, with links to the downloaded SDK on the 
Mac host, and have someone who owns a Mac take responsibility for running the 
GUB builds on the VM

I wish we had a better possibility, but I think that's all there is.

Carl


    


reply via email to

[Prev in Thread] Current Thread [Next in Thread]