Re: DragonEgg has been revived

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

fixing distracting typos:
On Thursday, May 24, 2018 at 12:19:06 PM UTC-5, Simon Wright wrote: 
> "Dan'l Miller" writes: 
> > And the logical and reading-comprehension (and lack thereof) 
> > contortions contained in later replies along the branches of this 
> > thread seem to clearly and undeniably demonstrate what Shark8 aptly 
> > called “all the morass of licensing”.  Just read all the later replies 
> > along the branches of this thread to see that different readers of & 
> > commentators on the exact same license text in GPLv3 and/or its 
> > Runtime Library Exception v3.1 reach drastically different conclusions 
> > [mainly by cherry-picking different quotations from the license text 
> > and then ignoring/eliding other passages of the license text]. 
> 
> Now we're getting insulting. 

I keep saying that this is entirely nothing more than a reading-comprehension problem and logical-deduction problem overtly cleverly crafted into (and throughout) the language of the GPLv3 and RLEv3.  I will request reading-comprehension & logical deduction again below (my own included*)

* Please help me out: quote chapter & verse from statutory law or from treaties or from GPLv3 or from RLEv3.1 such that the step-by-step detailed walk-through below gets dismantled.  I will read those seminal references. 

> > I later thought of a third category in answer to my own question that 
> > depends on how much surgery can be deeply & intimately performed on 
> > Target Code before evoking the “notwithstanding” clause in the 
> > RLEv3.1.  At what point of wholesale re-writing of a percentage of the 
> > Target Code become an act of re-compiling, taking the Target Code 
> > written by GCC as mere IR to the re-compiler? 
> 
> This is relevant to target code derived from source subject to the 
> RLE. 

Specifically where in the set {GPLv3, RLEv3.1, copyright law's body of statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence above?  I want to read it with my own eyes.  I want reading comprehension.  (And hearsay commentary on some forum from 2009 where people speculate and parrot what other people say doesn't count; I want original sources and seminal references, such as quotations from members of that set above.) 

> It has nothing to do with target code derived from source under 
> some other license, eg BSD 3-clause. 

Same request again for this sentence above. 

Btw, these 2 sentences are where I strongly believe that you are again factually incorrect. 

Let's walk step by step, but for brevity of writing here, let all readers pause at each capitalized contractual-term below to go read their definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading comprehension is emphasized.  Note that there exist 2 readings of the GPLv3 and its RLEv3.1:
a) once for GCC [henceforce G- prefix on the contractual-terms] and
b) once for my app [henceforce M- prefix on contractual-terms]
so that we can clearly see the G-to-M viral communicability of the licensing virus.  Just to be clear M-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with my app in mind (as reading comprehension) when linking with FSF GCC's runtime.  M-Contractual-Term is for when either the GPLv3 or RLEv3.1 or both are read onto my app.  Just to be clear G-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with FSF GCC itself in mind (as reading comprehension).  G-Contractual-Term is for when either the GPLv3 or RLEv3 or both are read onto GCC or its runtime.

1) The G-Source-Code term in GPLv3 initially-as-bootstrap refers to the source code of FSF GCC as itself licensed under GPLv3.   The G-Object-Code term in GPLv3 initially-as-bootstrap refers to the object code of FSF GCC as itself licensed under GPLv3.  The source code of GCC's runtime is also G-Source-Code.  The object code of GCC's runtime is also G-Object-Code back when GCC was built.

2) But then when my app's source code causes (even indirectly) the invocation of even a single subroutine in GCC's runtime (which is licensed via the RTEv3.1), then my app is linked with GCC's runtime library G-Object-Code). 

3) #2's linkage causes my app's object code to be (dare I say, virally) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3. 

4) #3 causes my app's source code to be (dare I say, virally) transformed for the time being into M-Source-Code as the contractual term defined in GPLv3. 

5) As per the various M-Object-Code clauses in GPLv3, the only right that I have to convey the M-Object-Code is either: 

5.1) to comply with the various demands to provide my app's source code (which just became M-Source-Code as my app reads onto GPLv3-with-RLEv3.1) or 

5.2) to comply with the various requisite expectations of good behavior in RLEv3.1 so that my app's M-Object-Code gets recategorized as M-Target-Code so that my app gets out of the GPLv3's demands on M-Object-Code. 

6) RLEv3.1 is predicated on my app being compiled by an M-Elligible-Compilation-Process. 

7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-Process being an M-Compilation-Process in the first place. 

8) RLEv3.1's M-Compilation-Process is predicated on satisfying the various contractual restrictions on M-Target-Code. 

2 hypothetical cases A versus B: 

A9) RLEv3.1's M-Target-Code is satisfied if my app is, say, compiled to hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed. 

A10) The logical-deduction chain of
“if M-Target-Code satisfied”
begets
“if M-Compilation-Process satisfied”
begets
“if M-Eligible-Compilation-Process satisfied”
begets
“if RLEv3.1 satisfied”
then has successfully recategorized (viral) M-Object-Code into mere (nonviral) M-Target-Code, dispensing with any need to provide source code or provide Installation Information or provide Corresponding Source Code over in GPLv3.  My app's reading of GPLv3 and RLEv3.1 stops at this terminus.  The lifetime of the effective temporary instantiation of M-Object-Code and M-Source-Code as contractual terms that might need to be complied with has effectively ended, as M-Target-Code eclipses M-Object-Code as per the special permissions granted by the RTEv3.1.  Whew!  My app dodged that bullet. 

versus 

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode 

B9) Apple's forthcoming LLVM-bitcode-IR re-compiler for iOS take my app's M-Object-Code and re-compiles it for, say, both the Mac App Store and the iOS App Store (which is where I suspect as a totally wild guess that Apple was heading with this re-compiler), and perhaps for different eras of ARM processors soldered into iDevices. 

B10) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those that have been approved by Apple for conveyance in the App Store. 

B11) At some point Apple could require the availability of LLVM bitcode IR for each app to be approved for the App Store.  This could either by overtly requiring LLVM bitcode IR files at time of submission or via a McSema-esque technology.  The following steps don't really care which option Apple takes, but let's write the wording up for the former. 

B12) Regardless of how the LLVM bitcode IR is actually generated for my app (e.g., my GELI proposal; DragonEgg on a modern GCC release that is licensed via GPLv3-with-RLEv3.1), the “notwithstanding” clause in the 2nd sentence of RLEv3.1's attempt to define M-Target-Code is triggered, overriding any potential definitions of M-Target-Code in the 1st sentence of RLEv3.1's attempt to define M-Target-Code.  That is how “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, the 2nd sentence drops a nuclear bomb on the 1st sentence, no matter what impervious bomb shelter the 1st sentence thought that it was hiding within, literally leaving the attempted definition of M-Target-Code •with• all attempted definitions •not• •standing•**, blown to smithereens by the dropping of the “notwithstanding” nuclear-bomb regarding IR. 

** hence the word: notwithstanding

B13) Oopsies, in B12, M-Target-Code failed to get defined, due to the IR nuclear bomb that got dropped.  Where the absence of M-Target-Code occurs downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent. 

B14) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of B12/B13.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream so it is clear that M-Compilation-Process is absent. 

B15) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process to have been successfully defined.  But instead M-PhthphthphCP is all that came out of B14.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-Compilation-Process is absent. 

B16) RLEv3.1 grants its special magic of M-Target-Code in RLEv3.1 eclipsing M-Object-Code in GPLv3 if and only if M-Eligible-Compilation-Process would have been successfully defined.  But instead M-PhthphthphECP is all that came out of B15.  So the RTEv3.1's house-of-cards that RLEv3.1 tries to carefully build up collapses and no special magic occurs:  M-Object-Code stays M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for my app, over in GPLv3 when reading GPLv3 onto my app. 

B17) Now back over in GPLv3, M-Object-Code must provide its M-Source-Code to all possessors of M-Object-Code in one or more GPLv3-specified ways. 

B18) Because iDevices are not limited to substantially industrial usage (e.g., within jet-fighter cockpits, with telephone-switch central offices, on factory floors), it sure seems like (in any plain-language reading of GPLv3) an iDevice would be a M-User-Product on which M-Object-Code is going be installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided. 

B19) I don't possess M-Installation-Information and M-Corresponding-Source, but Apple does. 

B20) Apple would be wise to side-step the B18's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compiler processes. 

B21) Although it might have been done for historically different reasons, how convenient for Apple to have discontinued usage of GPLv3-with-RLEv3.1-licensed compilation processes, because it seems that LLVM-world permits IR activities that GCC-world does not permit (at least without the FSF-GCC-compiled apps and the walled-garden into which those apps are being installed all being open-source as per the GPLv3 and its RLEv3.1 amendment). 

The outcome of B9 through B21 are one of the counterexamples to the fallacious theorem that GCC imposes no GPL-based restrictions on an app's object code or target code or Object Code or Target Code that were written by GCC as part of compiling that app.  We sought to disprove the fallacious theorem.  It is disproven by finding at least one counterexample.  Q.E.D.

> >                 GCC is licensed as GPLv3-with-RLEv3.1 
> 
> No, it's not. 

  (sigh #1) Okay, to speak less colloquially, how about instead:  GCC-with-its-runtime is a GPLv3-with-RLEv3.1-licensed •compilation process•?  Focus on “compilation process” as a whole enchilada (as RLEv3.1 does) instead of on ‘compiler’ versus ‘runtime’ compartmentally. 

  (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately intertwined with the GPLv3 license under which the compiler proper is conveyed (except in the, say, 0.1% case of people who refrain from utilizing the runtime in any way whatsoever).  As shown in the detailed walk-through above, there is a natural complex interplay (not unlike a ping-pong game or pendulum swinging) between not only GCC's GPLv3 and GCC runtime's RLEv3.1 when read onto GCC from GCC's standpoint, but also between those license documents reading onto GCC's/runtime and the dragged-in reading of those documents onto my app for RLEv3.1 to enact its magic of the eclipse*** of the viral M-Object-Code by the successfully-defined nonviral M-Target-Code instead. 

*** eclipsing in the situation of garden-variety execution of M-Target-Code, but not eclipsing in the situation of App Store's re-compilation of M-Object-Code due to the failure of the attempt to define M-Target-Code due in turn to RLEv3.1's “notwithstanding” clause dropping its nuclear bomb, scorched-earthing all the attempts to define RLEv3.1's downstream contractual-terms 

> GCC is licensed as GPL, its runtimes are licensed with 
> RLE. I can see it might/would be difficult to explain the consequences 
> to a small business, but your continued diatribes do nothing to help. 

I think that my walk-through above is quite lucid at explaining step-by-step what occurs as the crank-handle of the language is mechanically turned, as written, as interpreted in the plain-language meanings of the contractual-terms as defined in GPLv3 and RLEv3.1.  But then again perhaps I am factually incorrect somewhere somehow.  That small business's mileage might vary in various jurisdictions of differing systems of law that somehow cause a different sequence of contractual interpretation than the one that itemized above. 

I am not a lawyer.  I cannot do any of this for that small business; that small business needs to go counsel with an attorney who passed the bar in that small business's jurisdiction.  But as a citizen of the USA and of Texas, I am fully permitted to interpret all this for myself for my own personal usage, based on my amateur understanding of all these topics that I have self-studied. 

> > Note that there does exist at least one way in the language overtly 
> > stated in GPLv3 and its Runtime Library Exception v3.1 that the Object 
> > Code can be forced (dare I say, virally) to be GPLv3-licensed when the 
> > Corresponding Source Code was permissively licensed open-source or 
> > even EULA-licensed closed source. We do all see that, don't we? 
> 
> No. 

Then read the walk-through above, while looking up each G- and M- contractual-term in the GPLv3 and RLEv3.1 to achieve deep reading comprehension step-by-step. 

> >> [sjw] I don't think that it would contravene the GPL to modify GCC so 
> >> that it emitted an intermediate representation, provided that you 
> >> convey the source form of such modification with a compiler binary. 
> > 
> > Hey, you found one of those “GPL[-based] restrictions on the generated 
> > code” that Shark8 and Simon Clubley are yearning to eliminate in some 
> > hypothetical non-GNAT Ada compiler.  Yea!  Good job!  Attaboy!  You 
> > only needed to find one counter-example to the fallacious theorem 
> > regarding GCC having absolutely no such “GPL[-based] restrictions on 
> > the generated code”.  You found one.  Yea! 
> 
> WTF? 

That is what it feels like to have a “Eureka!” moment. 

> >> What could well cause trouble, and violation of the GCC Runtime 
> >> Library Exception, would be to use that modified compiler on source 
> >> of an RTS that was covered by the GCC Runtime Library Exception. 
> > 
> > Hey, you found another one of those “GPL[-based] restrictions on the 
> > generated code” that Shark8 and Simon Clubley are yearning to 
> > eliminate in some hypothetical non-GNAT Ada compiler.  Yea!  Good job! 
> > Attaboy!  You only needed to find one counter-example to the 
> > fallacious theorem regarding GCC having absolutely no such 
> > “GPL[-based] restrictions on the generated code”.  But you have found 
> > two.  Yea! 
> 
> Again I say, WTF? 

And another “Eureka!” moment of the genesis of understanding.