Re: DragonEgg has been revived

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

On Thursday, May 24, 2018 at 10:38:10 AM UTC-5, Dan'l Miller wrote:
> Here is where the fallacious theorem was postulated.  Shark8 years for “generat[ing] code for … targets
> without ••••••••••any•••••••••• GPL restrictions on the generated code”.  

Btw, I meant:
Shark8 yearns for, not years for (although I am pretty sure that he has been yearning for that for years).

> Btw, while we are on the topic of re-compiling Target Code, it seems that another act on the Target Code
> written by FSF GCC as licensed by GPLv3-with-RLEv3.1 might be dodgy/sketchy/perhaps-not-permitted
> without-providing-original-source-code-as-per-GPLv3's-terms: 
>
> 4) Imagine a (closed-source EULA-licensed paid-software) machine-code-to-machine-code
> translator/re-compiler that coverts from one ISA-and-ABI to another drastically-different ISA-and-ABI.
> The input Target Code written by FSF GCC could be considered IR to this re-compiler.  The resulting
> output machine-code on the drastically-different ISA and ABI could* revert under the RLEv3.1 to
> full-fledged GPLv3. 
>
> * if someone were to consider the input Target Code as IR, much the same as the McSema line of
> reasoning. 
>
> And then the Installation Information portion of the GPLv3 could come into play, unless the re-compiled
> drastically-different-ISA-&-ABI machine-code was installed on something “industrial” sufficiently
> resembling a fighter-jet cockpit or telephone switch in a central office or metal-stamping machine on a
> factory floor.  So that close-source re-compiler that someone paid money to EULA-license its usage
> must now be provided along with the source code for free to any possessor on any hardware whose
> “significant mode of use” is at least partially non-“industrial”. 

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.

Dang it.  The possibility of sketchiness/dodginess in this vicinity of FSF GCC licensing (regarding IR tools outside of my control, downstream from me complicating my life upstream) erodes part of my motivation for GELI as proposed earlier in a branch of this thread

GELI project:
(i.e., the GPLv3-with-RLEv3.1-licensed GNAT-with-LLVM-&-Polly-backend), where GELI would be an LSP peer of the GIGI tree-transducer in FSF GNAT.  When an “llvm-”-prefixed target name is on the GNAT command line, GELI would shunt* off to LLVM-world from the point of the Ada iterator/cursor walking GNAT's fully-semantically-adorned Ada-IR tree.  (Non-“llvm-”-prefixed targets on the GNAT command line would utilize the traditional GIGI-GENERIC-highGIMPLE-lowGIMPLE-RTL backend.)

* all within one GCC executable without writing out any IR to files, so as to comply with my stricter interpretation of the terms of RLEv3.1 intertwined with the terms of GPLv3.

One of my prime motivators for GELI and its GPLv3-with-RLEv3.1-licensed LLVM-backended FSF GNAT was to utilize Ada2012 to write iDevice apps for submission to the App Store (since on-nonjailbroken-iDevice debugging by gdb is disallowed nowadays due to gdb's lack of codesigning after Apple's switchover to LLVM-world toolchain).

Dang it.   Hmmmmm.   Must rethink how to help Byron's generation of LLVM bitcode IR arrive sooner.