Re: DragonEgg has been revived

["Dan'l Miller" <optikos@verizon.net>]

On Thursday, May 24, 2018 at 1:07:02 PM UTC-5, Lucretia wrote:
> On Thursday, 24 May 2018 17:44:22 UTC+1, Dan'l Miller  wrote:
> 
> > Oh great.  Now I have convinced myself that there is enough sketchiness/dodginess in this vicinity to question whether Apple's forthcoming App-Store LLVM-bitcode-IR recompiler wouldn't satisfy any one or more required terms of any GPLv3-with-RLEv3.1-licensed compiler (FSF or otherwise) in such as way as to cause both:
> > 1) the app to need to provide its Source Code;
> > and
> > 2) Apple to need to provide the Installation Information and Corresponding Source Code on a “consumer” device that is not-“sufficiently” “industrial”, where that consumer device (e.g., an Apple iDevice) might be a User Product in the terms of GPLv3.
> > and thus
> > 3) merely compiling the app with GPLv3-with-RLEv3.1-licensed compiler (and the app invoking at least one subroutine in the RLEv3.1-licensed runtime) could conceivably be enough for Apple to reject such apps from the App Store, so that Apple need not satisfy #2 above.
> > 
> > https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode
> > 
> > Apparently Apple is either working on a McSema-esque technology or would require the app to be
> > (also?) provided in the form of LLVM-bitcode-IR (in addition? to ARM-processor machine-code) at the
> > time of submission to the App Store for approval.
> 
> They're not doing anything of the sort. They used to use fat binaries containing both m68k and powerpc,
> then both 32/64 bit x86. For this they'll use LLVM bitcode, which is IR compiled to LLVM's bitcode,
> something that's been in LLVM since it started. One of the major pros about that bitcode is that you can
> then do aggressive linking and stripping before installation.

Fat binaries was an option within the 2nd conceivable option that I listed there.

If truly fat (i.e., where in the future Apple would permit or require MacOS Intel Target Code along with iOS ARM Target Code along with optionally LLVM bitcode IR) when/if Apple ever unifies iOS & MacOS apps, then it seems FSF GNAT on MacOS could still be utilized for building apps for submission to the Mac App Store.

But if Apple in the future were to unify MacOS & iOS apps via requiring LLVM bitcode IR as the sole format when submitting an app for App-Store approval, then is seems that compiling an app with FSF GNAT on MacOS would preclude closed-source apps from being submitted to the Mac App Store.

My point of listing conceivable potential futures was that no one can definitively predict what Apple will do.  We can merely list all the conceivable or likely foreseeable possibilities and then we might have a, say, 75% chance of Apple's future decision actually being on that list.

Uncertainty and “all the morass of licensing surrounding” GCC galore.

> We talked about a similar mechanism for a platform neutral binary for AmigaOS NG BITD, but that never
> happened, well it did sort of with Tao, but it never got anywhere and Tao went out of business.

Likewise:
Had it been GPLv3 during the 1990s instead of GPLv2, it seems from my analysis of GPLv3 and RLEv3.1 that OSF/1's ANDF (architecture-neutral distribution format) would have also trigged the “notwithstanding” clause of Target Code in RLEv3.1 back in the first half of the 1990s during the era of the so-called ‘UNIX wars’ (which in turn triggers the provide-the-Source-Code demands in the Object Code clauses of GPLv3).