Re: macOS 64-bit

[David Kastrup]

Marnen Laibow-Koser <address@hidden> writes:

> On Thu, May 16, 2019 at 6:22 PM David Kastrup <address@hidden> wrote:
>
>> Marnen Laibow-Koser <address@hidden> writes:
>>
>> > On Thu, May 16, 2019 at 5:01 PM David Kastrup <address@hidden> wrote:
>> >
>> >> marnen <address@hidden> writes:
>> >>
>> >> > My understanding from other posts here (correct me if I'm wrong) is
>> >> > that a major (legal, not technical) roadblock for doing this with GUB
>> >> > is the licensing requirement that seems to require that Xcode be run
>> >> > on Apple hardware, and the lack of consistent availability of Apple
>> >> > hardware for builds.
>> >>
>> >> The GPL 3.0 does not allow additional restrictions such as requiring
>> >> certain hardware.  Availability is not an issue, the restrictions are.
>> >>
>> > [...]
>> >
>> > Xcode is not governed by GPL3, and AFAIK it's the only component at issue
>> > here whose license stipulates particular hardware.
>>
>> GUB is governed by the GPLv3.  Nobody claims that people may not
>> independently create ports of LilyPond for MacOSX but creating them as
>> part of GUB in the general release process is not an option with the
>> current Xcode license.
>
> Perhaps I don’t understand.  If GUB merely calls out to Xcode, how is this
> a GPL3 issue?

You would not be allowed to execute GUB on non-MacOSX hardware if using
Xcode were an integral part of its operation, and this kind of
restriction is not allowed by the GPLv3.

How do you even imagine we could use Xcode on non-Mac hardware in the
course of the release process?  Apple demands native compilation when
using Xcode, and our release process does not run on Apple hardware.
It's not like Jan as the author of GUB is out of the world and could be
asked to license GUB in a manner where restraining its use to Apple
hardware would be possible.

But I will not do so as LilyPond maintainer, and pressing for that kind
of proprietary release process is outside of the resources the GNU
project lends to LilyPond as GNU software.

If Apple does not want software to be crosscompiled to MacOSX, that is
their privilege.

If you want to find a way around it, the way would likely be using some
Darwin-only SDK.  We won't likely be able to include a GUI editor or GUI
based install and it might impact some font inclusion details, but for
the MacOSX GUI Apple clearly barrs us from using their current Xcode SDK
in the release process using crosscompilation on GUB.

-- 
David Kastrup