Re: DragonEgg has been revived

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

Let us review, where Simon Wright and Chris Moore got off-track in this thread:

First, Simon Clubley yearns for a splendid & laudable goal:

On Tuesday, May 22, 2018 at 7:29:10 AM UTC-5, Simon Clubley wrote:
> On 2018-05-21, Dan'l Miller wrote:
> >
> > Simon, how fervently do you seek an LLVM-backended GNAT?  Over on other
> > threads in recent days, I have been commenting on a proposed alternative to
> > DragonEgg.
> 
> What I would like to see is an Ada compiler that can generate code
> for a wide range of targets without any GPL restrictions on the
> generated code.

Then, Shark8 yearns for much the same splendid & laudable goal:

On Tuesday, May 22, 2018 at 5:33:29 PM UTC-5, Shark8 wrote:
> On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote:
> > What is so bad about GPLv3 with Runtime Exception …
> 
> In itself, not so much -- the biggest problem with anything GCC [meaning GNAT in the context of Ada] is
> that there's all the morass of licensing surrounding it: FSF GNAT vs PGL GNAT vs AdaCore Pro GNAT
> -- all have different restrictions and capabilities and it's just a big mess -- especially for any small to
> medium business to sort out.
> 
> I want a clean break from ALL of that.

Note that implied in the context of the subtext of their implied communication, Shark8 and Simon Clubley both consider FSF GCC as licensed by GPLv3 with Runtime Library Exception v3.1 (RLEv3.1) as either certainly or perhaps ••not providing•• the splendid & laudable goal for which they both yearn.

Btw, the hair-splitting between whether it is “certainly … not providing” versus “perhaps not providing” is caught up in what Shark8 aptly calls:  “all the morass of licensing” regarding the interplay of variants of the GPLv3 stand-alone, GPLv3 with RLEv3.1, GMGPLv3, any possessor can ‘upgrade’ to later GPL editions or GPL-compatible amendments for all downstream copies, and so forth.

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].

Earlier in this thread, I proposed a harsh-rebuke of DragonEgg as a drastically-different replacement for DragonEgg.  To facilitate herding cats that such a GPLv3-with-RLEv3.1-licensed LLVM-backended compiler would actually be good enough, I posed the question:

On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote:
> ••••What is so bad about GPLv3 with Runtime Exception•••• …
>
> 1) … unless a person really really wants to re-work GCC-emitted machine code as lifted to LLVM bitcode
> IR via, say, McSema as not-GPLv3ed derivative works, needing disclosure of all source code?** 
> or 
>
> 2) … unless a person really really wants to write LLVM bitcode IR out to a file to execute it on
> Sulong/GraalVM as not-GPLv3ed derivative works, needing disclosure of all source code?** 
> 
> 3) Can anyone think of any other precise downsides of GPLv3 •with• Runtime Exception? 
>
> I think all the downsides other than those 2 listed above are with GPL •without• Runtime Exception,
> correct? 

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?

3) #1 & #2 above are just the first 2 examples of emerging technology in the IR domain and in the rework-the-machine-code domain. 
3.1) For example, imagine an anti-malware add-on (that, for the sake of discussion here, violates the Target Code or Eligible Compilation Process clauses of a modern-GCC-written executable or DLL) to operating systems that reworks the machine-code at link-load time to eliminate: 
3.1.1) buffer-overrun injection of worms; and/or 
3.1.2) removes viruses/etc-malware that have attached themselves to the executable or DLL and/or 
3.1.3) randomizes the layout of the machine code each link-loader-time so that malware cannot easily recognize that executable or DLL. 

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”.

A “morass of licensing” indeed!  Gee, the more we look into all these portions of the GPLv3 and/or its deeply-intertwined RLEv3.1, the more & more “all the morass of licensing” that is revealed.  (Thank you, Simon Wright.  Your diligence motivated me to find evermore morass.)

On Thursday, May 24, 2018 at 2:19:12 AM UTC-5, Simon Wright wrote:
> "Dan'l Miller" writes:
> 
> > On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote: 
> >> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: 
> >> 
> >> > What I would like to see is an Ada compiler that can generate code
> >> > for a wide range of targets without any GPL restrictions on the
> >> > generated code.
> >> 
> >> Pretty sure that's called GCC. 

Here is where the fallacious theorem was postulated.  Shark8 years for “generat[ing] code for … targets without ••••••••••any•••••••••• GPL restrictions on the generated code”.   Because RLEv3.1 is nothing more than an amendment to GPLv3, and because GCC is licensed as GPLv3-with-RLEv3.1, here Shark8's “GPL” of course refers to GPLv3 with RLEv3.1 except in the above-mentioned “morass-of-licensing” ways that RLEv3.1 degenerates back down to full-fledged GPLv3 as RLEv3.1 terms are violated.  It is both GPLv3 ••and its amendments intimately intertwined with GPLv3•• that Simon Clubley and Shark8 here are yearning to have absolutely none of:  zero, zilch, empty set, naught, null, nada.  

(And yes, someone could arrive at an FSF GCC that is licensed by full-fledged GPLv3 by fully eliminating the RLEv3.1-licensed code, but, say, 99.9% of the users of FSF GCC don't do that.  Let's not contort ourselves into discussing the, say, 0.1% corner case.  Therefore, these “GPL restrictions” that Shark8 and Simon Clubley yearn to eliminate is some future non-GNAT compiler can originate in either GPLv3 proper or its intimately-intertwined-with-GPLv3 amendment:  RLEv3.1.  Both GPLv3 proper and RLE3.1.  Period.)

Hence, the fallacious theorem can be •disproven• by finding even a single counter-example “GPL[-based] restriction[] on the generated code” written by GCC.  Find more than one?  Then an even-better set of counter-examples for even stronger disproving.

Note that “generated code” there conforms to GPLv3's Object Code, which is anything not Source Code derived from the Source Code.  Note that “generated code” need not satisfy the terms of Target Code, because that is precisely what Simon Clubley and Shark8 are focusing their attention on:  all the ways that would-be Target Code isn't Target Code such that would-have-been Target Code in the RLEv3.1 degenerates down to GPLv3-licensed Object Code, whose only right to convey is granted by also providing the Source Code (and Installation Information if not installed complicatedly/obfuscatedly/cryptically on a device insufficiently “industrial”).

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?

> > Pretty sure that you haven't read the Object Code clauses in GPLv3 and
> > the Target Code clauses and Eligible Compilation Process clauses in
> > the Runtime Exception v3.1.  GPL restrictions galore on the generated
> > code there in Target Code & Eligible Compilation Process (in Runtime
> > Exception v3.1) interacting with Object Code, where Object Code is
> > •everything• not Source Code (in GPLv3).  IR would therefore be Object
> > Code due to being not Target Code and not Source Code.
> 
> You are confusing GPLv3 with the GCC Runtime Library Exception.

  No, you are confusing GPLv3-with-Runtime-License-Exception-v3.1-licensed GCC in the fallacious theorem with some other compiler (e.g., GNAT Pro GPL Community Edition) that is licensed by full-fledged GPLv3.  Don't change the subject to some other full-fledged-GPLv3-licensed compiler.  No muddying the waters; stay on the topic of the fallacious theorem that is focused entirely on FSF GCC.  (Other than the, say, 0.1% who forego all utilization of the GCC runtime and can thus avoid the RLEv3.1,) the only (remaining) way that FSF GCC is licensed by full-fledged GPLv3 is •degenerately• by not satisfying one or more logical-deduction paths through the RLEv3.1.  Such a lack of satisfaction of one or more logical-deduction paths through the RLEv3.1 causes RLEv3.1 to become a big NO-OP as an amendment to GPLv3, leaving only full-fledged GPLv3 standing unamended.

It is precisely these subtle self-eliding & self-spreading logical-deduction paths of intertwined contract-terms (such as cleverly encoded in the RLEv3.1, but also elsewhere in the not-sufficiently-industrial Installation Information and Corresponding Source Code clauses of the GPLv3-proper) that Simon Clubley and most especially Shark8 are yearning to have none of:  zero, zilch, empty set, naught, null, nada.

Hence, to disprove the fallacious theorem, all we need to do is find one real-world activity that someone can unimpededly actually do with executables or DLLs produced by, say, a closed-source EULA-licensed compiler:
1) that would have caused a lack of satisfying one or more logical-deduction paths through the RLEv3 had the executable or DLL been compiled by FSF GCC;
or
2) that would have caused some evocation of Installation Information and Corresponding Source Code clauses of GPLv3-proper had the executable or DLL been compiled by FSF GCC and linked with its runtime;
or
3) that would have evoked any other category of subtle clauses in GPLv3-proper or in any amendment to GPLv3 to force doing something with Source Code or Installation Information or Corresponding Source Code that is (or was intended to have been) licensed by either a permissive open-source license or a close-source license or lack thereof.

> GPLv3 section 1 para 4 says
> 
>    The “Corresponding Source” for a work in object code form means all
>    the source code needed to generate, install, and (for an executable
>    work) run the object code and to modify the work, including scripts
>    to control those activities. However, it does not include the work's
>    System Libraries, or general-purpose tools or generally available
>    free programs which are used unmodified in performing those
>    activities but which are not part of the work. [...]
> 
> and it's clear that the GCC compiler itself is a 'generally available
> free program'.
> 
> See also the FAQ[1]:
> 
>    [Q] Can I use GPL-covered editors such as GNU Emacs to develop
>    nonfree programs? Can I use GPL-covered tools such as GCC to compile
>    them?
>  
>    Yes, because the copyright on the editors and tools does not cover
>    the code you write. Using them does not place any restrictions,
>    legally, on the license you use for your code.
>    
> 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!

> 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!

Simon Wright, keep looking and digging on ways that new tech causes people to accidentally ‘step in a pile of dung’ that they didn't intend to step into via the terms of the GPLv3 and RLEv3.1.  You'll eventually find more than the 2 ways that you have already found to not satisfy
1) the logical-deduction paths through the RLEv3.1 so that, without RLEv3.1, •all• not-Source-Code* written by FSF GCC is forced to be considered Object Code under GPLv3, where that Object Code is linked with GPLv3-licensed runtime code to make (dare I say, virally) the entire resulting executable or DLL licensed under the GPLv3-proper (i.e., without RLEv3.1 because the RLEv3.1 went poof due to its chain of logical deductions eliding themselves as they are overtly constructed to do under certain conditions)
or
2) the not-sufficiently-industrial terms of the Installation Information and Corresponding Source Code clauses of the GPLv3-proper, as some new tech moves from industrial usage into the residence.

* which for the sake of argument here is (or was intended to have been!) licensed either as permissively open-source, such as via MIT/X11 license or BSD license or as closed-source